You are not logged in.
- Topics: Active | Unanswered
#1 2020-10-08 21:19:18
- hoopdriver
- Member
- Registered: 2020-10-08
- Posts: 10
beowulf Raspberry Pi build, packages.roundr.devuan.org not responding
I've just built beowulf on a Raspberry Pi - it was a bit fiddly, why was the decision made to use the mac address for the network name ?
Anyway, the main reason I'm mailing is that an apt-get update is failing :-
root@rhubarb:/etc/network# apt-get update
Err:1 http://packages.roundr.devuan.org/devuan beowulf InRelease
Connection failed [IP: 5.196.38.18 80]
0% [Waiting for headers]^Cit would appear that packages.roundr.devuan.org/ is down - it doesn't respond to pings or curl.
Is there another repository or is this just a transient issue ?
Cheers,
hoopdriver
Offline
#2 2020-10-08 21:41:37
- ralph.ronnquist
- Administrator
- From: Battery Point, Tasmania, AUS
- Registered: 2016-11-30
- Posts: 1,251
Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding
Online
#3 2020-10-08 21:44:11
- golinux
- Administrator
- Registered: 2016-11-25
- Posts: 3,316
Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding
Offline
#4 2020-10-09 08:33:10
- hoopdriver
- Member
- Registered: 2020-10-08
- Posts: 10
Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding
Thanks guys.
I changed packages.devuan.org to deb.devuan.org in /etc/apt/sources.list and it solved the problem.
sed -i "s/packages.devuan.org/deb.devuan.org/" /etc/apt/sources.listA later edit - I changed /devuan to /merged so my /etc/apt/sources.list now looks like this :-
root@rhubarb:~# cat /etc/apt/sources.list
## package repositories
deb http://deb.devuan.org/merged beowulf main contrib non-free
deb http://deb.devuan.org/merged beowulf-updates main contrib non-free
deb http://deb.devuan.org/merged beowulf-security main contrib non-free
#deb http://deb.devuan.org/merged beowulf-backports main contrib non-free
## source repositories
#deb-src http://packages.devuan.org/devuan beowulf main contrib non-free
#deb-src http://packages.devuan.org/devuan beowulf-updates main contrib non-free
#deb-src http://packages.devuan.org/devuan beowulf-security main contrib non-free
#deb-src http://packages.devuan.org/devuan beowulf-backports main contrib non-freeIt still failed :-)
root@rhubarb:~# apt-get update
Hit:1 http://deb.devuan.org/devuan beowulf InRelease
Hit:2 http://deb.devuan.org/devuan beowulf-updates InRelease
Hit:3 http://deb.devuan.org/devuan beowulf-security InRelease
Reading package lists... Done
E: Release file for http://deb.devuan.org/devuan/dists/beowulf/InRelease is not valid yet (invalid for another 18544d 3h 25min 47s). Updates for this repository will not be applied.
E: Release file for http://deb.devuan.org/devuan/dists/beowulf-updates/InRelease is not valid yet (invalid for another 18544d 3h 25min 44s). Updates for this repository will not be applied.
E: Release file for http://deb.devuan.org/devuan/dists/beowulf-security/InRelease is not valid yet (invalid for another 18544d 3h 25min 42s). Updates for this repository will not be applied.because the clock is wrong :-
root@rhubarb:~# date
Thu 1 Jan 00:02:27 UTC 1970No ntp configuration.
sorted with :
root@rhubarb:~# ntpdate ntp1.npl.co.uk ntp2.npl.co.uk
9 Oct 08:13:03 ntpdate[1441]: step time server 139.143.5.30 offset 1602230943.101516 sec
root@rhubarb:~# date
Fri 9 Oct 08:13:06 UTC 2020I also had to do a dpkg-reconfigure locales to get the machine to somewhere near working.
and there's no ntp package available (Sigh) :-
root@rhubarb:~# apt-get install ntp
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package ntpI created a stub /etc/ntp.conf :-
root@rhubarb:~# cat /etc/ntp.conf
server ntp1.npl.co.uk
server ntp2.npl.co.ukand rebooted, it wasn't honoured however manually after reboot :-
root@rhubarb:~# date
Thu 1 Jan 00:00:33 UTC 1970
root@rhubarb:~# ntpdate-debian
9 Oct 08:25:53 ntpdate[1159]: step time server 139.143.5.30 offset 1602231895.721279 sec
root@rhubarb:~# date
Fri 9 Oct 08:25:59 UTC 2020picks them up.
I think beowulf on raspberry pi is definitely a "work in progress" release but I've now got something I can build on. :-)
Last edited by hoopdriver (2020-10-09 09:23:00)
Offline
#6 2020-10-09 16:37:35
- hoopdriver
- Member
- Registered: 2020-10-08
- Posts: 10
Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding
hello hoopdriver,
For Raspberry Pi1 there is a image availlable here
What is your Raspberry PI version?
Hi tux3dv,
that's the one I built from :-)
I'm running a very early Raspberry Pi Model B :-
oot@rhubarb:~# cat /proc/cpuinfo
processor : 0
model name : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS : 697.95
Features : half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7
[Hardware : BCM2835
Revision : 0000
Serial : 00000000ba27b441
root@rhubarb:~# cat /proc/meminfo
MemTotal: 492324 kB
MemFree: 434284 kB
MemAvailable: 464412 kB
Buffers: 7656 kB
Cached: 27928 kB
SwapCached: 0 kB
Active: 26504 kB
Inactive: 14448 kB
Active(anon): 5392 kB
Inactive(anon): 108 kB
Active(file): 21112 kB
Inactive(file): 14340 kB
Unevictable: 16 kB
Mlocked: 16 kB
SwapTotal: 102396 kB
SwapFree: 102396 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 5396 kB
Mapped: 11032 kB
Shmem: 136 kB
KReclaimable: 4624 kB
Slab: 9264 kB
SReclaimable: 4624 kB
SUnreclaim: 4640 kB
KernelStack: 488 kB
PageTables: 508 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 348556 kB
Committed_AS: 52416 kB
VmallocTotal: 524288 kB
VmallocUsed: 2912 kB
VmallocChunk: 0 kB
Percpu: 64 kB
CmaTotal: 8192 kB
CmaFree: 7028 kBI think that devuan is a more rounded package than the official Raspbian image and it fits better with my target of a bare minimal system. Too many distros add a lot of superfluous packages at build time, I'm definitely in the KISS (S being SMALL in this case) group of sysadmins.
The major problem I had with the beowulf build was the network interface. The target machine is remote and dead and I don't know what the MAC address is so I have had to fiddle with /etc/udev to name the interfaces to something sensible rather than base the name on the mac address. I'll be building another one shortly to see if the changes all work then shipping the SD card to the hosting company.
Offline
#7 2020-10-10 00:41:48
- emojifreak
- Member
- Registered: 2020-10-06
- Posts: 15
Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding
The major problem I had with the beowulf build was the network interface. The target machine is remote and dead and I don't know what the MAC address is so I have had to fiddle with /etc/udev to name the interfaces to something sensible rather than base the name on the mac address.
Adding net.ifnames=0 to cmdline.txt should solve the problem, as written at
https://wiki.debian.org/NetworkInterfac … et_it_back
Raspberry Pi OS and Debian SD card images have net.ifnames=0 in cmdline.txt.
I am wondering why Devuan dropped it...
Devuan SD card images built by my script https://github.com/emojifreak/debian-rpi-image-script
also have net.ifnames=0, as the Devuan raspi-firmware package adds net.ifnames=0 to cmdline.txt.
Last edited by emojifreak (2020-10-10 00:47:12)
Offline
#8 2020-10-10 14:31:33
- hoopdriver
- Member
- Registered: 2020-10-08
- Posts: 10
Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding
Hi emojifreak,
This was my preferred option :-) but it doesn't seem to be passing the arguments to the kernel (yes I have rebooted and what you see below is after the reboot) :-)
root@rhubarb:~# cat /boot/cmdline.txt
console=serial0,115200 console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait net.ifnames=0 init=/usr/lib/raspi-config/init_resize.sh
root@rhubarb:~# cat /proc/cmdline
earlyprintk=serial,ttyAMA0,115200n8 console=ttyAMA0,115200n8 console=tty0 root=/dev/mmcblk0p2 rw rootfstype=ext4 elevator=noop fsck.repair=yes rootwait smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=ttyAMA0,115200 selinux=0 noinitrdI ended up copying /lib/udev/rules.d/73-usb-net-by-mac.rules to /etc/udev/rules.d and changed the NAME value to "eth0".
My worry with all of these changes is that at some point in the future an apt-get update will clobber them and I will lose network connectivity.
I'll cross that bridge if/when I come to it.
Offline
#9 2020-10-11 00:55:59
- emojifreak
- Member
- Registered: 2020-10-06
- Posts: 15
Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding
Hi hoopdriver, thank you for your reply and sorry for my comment being of no help.
It is beyond my understanding how cmdline.txt has no effect...
A possibility is that /boot/cmdline.txt and cmdline.txt in the first FAT partition of your SD card are different.
What is the output of "df"?? Where the first FAT partition is mounted?
If you don't mind Devuan Chimaera, you can try another image
http://153.240.174.134:64193/devuan-chi … mal.img.xz
with the minimal set of packages, empty /etc/network/interfaces
and root password=root. cmdline does have an effect and exists in /boot/firmware/cmdline.txt
Last edited by emojifreak (2020-10-11 02:04:32)
Offline
#10 2020-10-11 09:03:19
- FM81
- Member
- Registered: 2017-09-16
- Posts: 30
Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding
There seems something wrong with the image linked in posts #5 and #6 ...
If I open the cmdline.txt from the first (FAT) partition of this image I see:
console=serial0,115200 console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet init=/usr/lib/raspi-config/init_resize.shIt points to the script /usr/lib/raspi-config/init_resize.sh - but only on first boot (the script itself changes that for future). This is correct for the normal Raspbian-OS! The problem in the devuan-image is: if you look inside the second partition: there ist no directory /usr/lib/raspi-config/ at all ...
So it points to a not existing INIT, it looks like it would not matter very much; but for my opinion such a thing should not happen?
Best regards, FM_81
The most brilliant role in comedy is that of a fool, he must not be in order to make it seem. (Miguel de Cervantes)
Offline
#11 2020-10-11 20:06:21
- hoopdriver
- Member
- Registered: 2020-10-08
- Posts: 10
Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding
In the interests of science ...
I thought I'd go through download, copy to sdcard and boot process just in case I have corrupted something, Here's the log :-
root@pibuild ~ $ cd /tmp
root@pibuild /tmp $ mkdir raspberry
root@pibuild /tmp $ cd raspberry/
root@pibuild /tmp/raspberry $ wget https://arm-files.devuan.org/SHA256SUMS
--2020-10-11 19:34:48-- https://arm-files.devuan.org/SHA256SUMS
Resolving arm-files.devuan.org (arm-files.devuan.org)... 5.135.82.177
Connecting to arm-files.devuan.org (arm-files.devuan.org)|5.135.82.177|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 697 [application/octet-stream]
Saving to: ‘SHA256SUMS’
100%[============================================================================>] 697 --.-K/s in 0s
2020-10-11 19:34:48 (64.3 MB/s) - ‘SHA256SUMS’ saved [697/697]
root@pibuild /tmp/raspberry $ wget https://arm-files.devuan.org/devuan_beowulf_3.0.0_armel_rpi1_0.3.img.xz
--2020-10-11 19:34:58-- https://arm-files.devuan.org/devuan_beowulf_3.0.0_armel_rpi1_0.3.img.xz
Resolving arm-files.devuan.org (arm-files.devuan.org)... 5.135.82.177
Connecting to arm-files.devuan.org (arm-files.devuan.org)|5.135.82.177|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 496416376 (473M) [application/octet-stream]
Saving to: ‘devuan_beowulf_3.0.0_armel_rpi1_0.3.img.xz’
100%[============================================================================>] 496,416,376 671KB/s in 9m 10s
2020-10-11 19:44:08 (882 KB/s) - ‘devuan_beowulf_3.0.0_armel_rpi1_0.3.img.xz’ saved [496416376/496416376]
root@pibuild /tmp/raspberry $ grep devuan_beowulf_3.0.0_armel_rpi1_0.3.img.xz SHA256SUMS
eadf5b2e94e9953c80467ea3f2e8c1b962e6459a7f712d8bf817e4bb56c3ea64 devuan_beowulf_3.0.0_armel_rpi1_0.3.img.xz
root@pibuild /tmp/raspberry $ sha256sum devuan_beowulf_3.0.0_armel_rpi1_0.3.img.xz
eadf5b2e94e9953c80467ea3f2e8c1b962e6459a7f712d8bf817e4bb56c3ea64 devuan_beowulf_3.0.0_armel_rpi1_0.3.img.xzDownload goes OK and verifies fine.
root@pibuild /tmp/raspberry $ xzcat devuan_beowulf_3.0.0_armel_rpi1_0.3.img.xz | dd of=/dev/sdc
3399680+0 records in
3399680+0 records out
1740636160 bytes (1.7 GB) copied, 250.951 s, 6.9 MB/sWrite to the SD card goes fine, then I unplug the SD card reader, count to 11, then plug it back in. This avoids any confusion with the host caching data or not scanning the card properly.
root@pibuild ~ # fdisk -l /dev/sdc
Disk /dev/sdc: 32.1 GB, 32127320064 bytes
64 heads, 32 sectors/track, 30639 cylinders, total 62748672 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x6c586e13
Device Boot Start End Blocks Id System
/dev/sdc1 8192 532479 262144 c W95 FAT32 (LBA)
/dev/sdc2 532480 3399679 1433600 83 LinuxLet's see what's on the card :-
pibuild ~ # mount /dev/sdc1 /mnt
pibuild ~ # cd /mnt
pibuild mnt # ls -alrt
total 31373
drwxr-xr-x 2 root root 3584 Jan 1 1970 .
drwxr-xr-x 25 root root 4096 Aug 17 2019 ..
-rwxr-xr-x 1 root root 3792232 Sep 25 2019 start_x.elf
-rwxr-xr-x 1 root root 2877988 Sep 25 2019 start.elf
-rwxr-xr-x 1 root root 4854728 Sep 25 2019 start_db.elf
-rwxr-xr-x 1 root root 685668 Sep 25 2019 start_cd.elf
-rwxr-xr-x 1 root root 3683816 Sep 25 2019 start4x.elf
-rwxr-xr-x 1 root root 2769540 Sep 25 2019 start4.elf
-rwxr-xr-x 1 root root 4733128 Sep 25 2019 start4db.elf
-rwxr-xr-x 1 root root 770816 Sep 25 2019 start4cd.elf
-rwxr-xr-x 1 root root 9810 Sep 25 2019 fixup_x.dat
-rwxr-xr-x 1 root root 9808 Sep 25 2019 fixup_db.dat
-rwxr-xr-x 1 root root 6736 Sep 25 2019 fixup.dat
-rwxr-xr-x 1 root root 2657 Sep 25 2019 fixup_cd.dat
-rwxr-xr-x 1 root root 9249 Sep 25 2019 fixup4x.dat
-rwxr-xr-x 1 root root 9247 Sep 25 2019 fixup4db.dat
-rwxr-xr-x 1 root root 6167 Sep 25 2019 fixup4.dat
-rwxr-xr-x 1 root root 3073 Sep 25 2019 fixup4cd.dat
-rwxr-xr-x 1 root root 52296 Sep 25 2019 bootcode.bin
-rwxr-xr-x 1 root root 169 Sep 26 2019 cmdline.txt
-rwxr-xr-x 1 root root 471692 Nov 24 2019 u-boot.bin
-rwxr-xr-x 1 root root 1837 Nov 24 2019 config.txt
-rwxr-xr-x 1 root root 4921296 Nov 24 2019 vmlinuz-5.3.13
-rwxr-xr-x 1 root root 2267409 Nov 24 2019 System.map-5.3.13
-rwxr-xr-x 1 root root 168112 Nov 24 2019 config-5.3.13
-rwxr-xr-x 1 root root 1014 Nov 26 2019 boot.cmd
-rwxr-xr-x 1 root root 1086 Nov 26 2019 boot.scr
pibuild mnt # touch hoopdrive
pibuild mnt # ls -alrt
total 31373
drwxr-xr-x 25 root root 4096 Aug 17 2019 ..
-rwxr-xr-x 1 root root 3792232 Sep 25 2019 start_x.elf
-rwxr-xr-x 1 root root 2877988 Sep 25 2019 start.elf
-rwxr-xr-x 1 root root 4854728 Sep 25 2019 start_db.elf
-rwxr-xr-x 1 root root 685668 Sep 25 2019 start_cd.elf
-rwxr-xr-x 1 root root 3683816 Sep 25 2019 start4x.elf
-rwxr-xr-x 1 root root 2769540 Sep 25 2019 start4.elf
-rwxr-xr-x 1 root root 4733128 Sep 25 2019 start4db.elf
-rwxr-xr-x 1 root root 770816 Sep 25 2019 start4cd.elf
-rwxr-xr-x 1 root root 9810 Sep 25 2019 fixup_x.dat
-rwxr-xr-x 1 root root 9808 Sep 25 2019 fixup_db.dat
-rwxr-xr-x 1 root root 6736 Sep 25 2019 fixup.dat
-rwxr-xr-x 1 root root 2657 Sep 25 2019 fixup_cd.dat
-rwxr-xr-x 1 root root 9249 Sep 25 2019 fixup4x.dat
-rwxr-xr-x 1 root root 9247 Sep 25 2019 fixup4db.dat
-rwxr-xr-x 1 root root 6167 Sep 25 2019 fixup4.dat
-rwxr-xr-x 1 root root 3073 Sep 25 2019 fixup4cd.dat
-rwxr-xr-x 1 root root 52296 Sep 25 2019 bootcode.bin
-rwxr-xr-x 1 root root 169 Sep 26 2019 cmdline.txt
-rwxr-xr-x 1 root root 471692 Nov 24 2019 u-boot.bin
-rwxr-xr-x 1 root root 1837 Nov 24 2019 config.txt
-rwxr-xr-x 1 root root 4921296 Nov 24 2019 vmlinuz-5.3.13
-rwxr-xr-x 1 root root 2267409 Nov 24 2019 System.map-5.3.13
-rwxr-xr-x 1 root root 168112 Nov 24 2019 config-5.3.13
-rwxr-xr-x 1 root root 1014 Nov 26 2019 boot.cmd
-rwxr-xr-x 1 root root 1086 Nov 26 2019 boot.scr
-rwxr-xr-x 1 root root 0 Oct 11 19:58 hoopdrive
drwxr-xr-x 2 root root 3584 Oct 11 19:58 .
pibuild mnt # cat cmdline.txt
console=serial0,115200 console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet init=/usr/lib/raspi-config/init_resize.sh
pibuild mnt # cd -
/root
pibuild ~ # umount /mntThat looks fine, note that I touched a file 'hoopdrive' and you can see that it appears in the second listing.
cmdline.txt does indeed try to run a script to resize the partition at boot so having a look at the second partion :-
pibuild ~ # mount /dev/sdc2 /mnt
pibuild ~ # ls -al /mnt/usr/lib/ras*
ls: cannot access /mnt/usr/lib/ras*: No such file or directory
pibuild ~ # umount /mntIt doesn't exist so we know that won't cause problems.
At this point I ejected the card from the card reader and plugged it into a raspberry pi. There is no networking set up or anything as yet so on the pi, I booted it up and logged in as root at the console then did a
script /var/tmp/hoopdrive1.log. This is what I saw :-
Script started on 1970-01-01 00:01:53+00:00 [TERM="linux" TTY="/dev/tty1" COLUMNS="160" LINES="64"]
root@RPi1:~# ls -lart /boot
total 31373
drwxr-xr-x 2 root root 3584 Jan 1 00:00 .
-rwxr-xr-x 1 root root 3792232 Sep 25 2019 start_x.elf
-rwxr-xr-x 1 root root 4854728 Sep 25 2019 start_db.elf
-rwxr-xr-x 1 root root 685668 Sep 25 2019 start_cd.elf
-rwxr-xr-x 1 root root 3683816 Sep 25 2019 start4x.elf
-rwxr-xr-x 1 root root 4733128 Sep 25 2019 start4db.elf
-rwxr-xr-x 1 root root 770816 Sep 25 2019 start4cd.elf
-rwxr-xr-x 1 root root 2769540 Sep 25 2019 start4.elf
-rwxr-xr-x 1 root root 2877988 Sep 25 2019 start.elf
-rwxr-xr-x 1 root root 9810 Sep 25 2019 fixup_x.dat
-rwxr-xr-x 1 root root 9808 Sep 25 2019 fixup_db.dat
-rwxr-xr-x 1 root root 2657 Sep 25 2019 fixup_cd.dat
-rwxr-xr-x 1 root root 9249 Sep 25 2019 fixup4x.dat
-rwxr-xr-x 1 root root 9247 Sep 25 2019 fixup4db.dat
-rwxr-xr-x 1 root root 3073 Sep 25 2019 fixup4cd.dat
-rwxr-xr-x 1 root root 6167 Sep 25 2019 fixup4.dat
-rwxr-xr-x 1 root root 6736 Sep 25 2019 fixup.dat
-rwxr-xr-x 1 root root 52296 Sep 25 2019 bootcode.bin
-rwxr-xr-x 1 root root 169 Sep 26 2019 cmdline.txt
-rwxr-xr-x 1 root root 471692 Nov 24 2019 u-boot.bin
-rwxr-xr-x 1 root root 1837 Nov 24 2019 config.txt
drwxr-xr-x 21 root root 4096 Nov 24 2019 ..
-rwxr-xr-x 1 root root 4921296 Nov 24 2019 vmlinuz-5.3.13
-rwxr-xr-x 1 root root 168112 Nov 24 2019 config-5.3.13
-rwxr-xr-x 1 root root 2267409 Nov 24 2019 System.map-5.3.13
-rwxr-xr-x 1 root root 1014 Nov 26 2019 boot.cmd
-rwxr-xr-x 1 root root 1086 Nov 26 2019 boot.scr
-rwxr-xr-x 1 root root 0 Oct 11 2020 hoopdrive
root@RPi1:~# ifconfig -a
enxb827ebb9e313: flags=4098<BROADCAST,MULTICAST> mtu 1500
ether b8:27:eb:b9:e3:13 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root@RPi1:~# cat /proc/cmdline
earlyprintk=serial,ttyAMA0,115200n8 console=ttyAMA0,115200n8 console=tty0 root=/dev/mmcblk0p2 rw rootfstype=ext4 elevator=noop fsck.repair=yes rootwait smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=ttyAMA0,115200 selinux=0 noinitrd
root@RPi1:~# cat /boot/cmdline.txt
console=serial0,115200 console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet init=/usr/lib/raspi-config/init_resize.shThis all looks good - note that 'hoopdrive' is there so we are definitely picking up the correct partition and mounting it.
I then made a change to /boot/cmdline.txt :-
root@RPi1:~# sed -i "s/rootwait/net.ifnames=0 rootwait/" /boot/cmdline.txt
root@RPi1:~# cat /boot/cmdline.txt
console=serial0,115200 console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4 elevator=deadline fsck.repair=yes net.ifnames=0 rootwait quiet init=/usr/lib/raspi-config/init_resize.sh
root@RPi1:~# exitAnd rebooted the pi and got :-
root@RPi1:~# ifconfig -a
enxb827ebb9e313: flags=4098<BROADCAST,MULTICAST> mtu 1500
ether b8:27:eb:b9:e3:13 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root@RPi1:~# cat /proc/cmdline
earlyprintk=serial,ttyAMA0,115200n8 console=ttyAMA0,115200n8 console=tty0 root=/dev/mmcblk0p2 rw rootfstype=ext4 elevator=noop fsck.repair=yes rootwait smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=ttyAMA0,115200 selinux=0 noinitrd
root@RPi1:~# cat /boot/cmdline.txt
console=serial0,115200 console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4 elevator=deadline fsck.repair=yes net.ifnames=0 rootwait quiet init=/usr/lib/raspi-config/init_resize.sh
root@RPi1:~# ls -lart /boot | tail
-rwxr-xr-x 1 root root 52296 Sep 25 2019 bootcode.bin
-rwxr-xr-x 1 root root 471692 Nov 24 2019 u-boot.bin
-rwxr-xr-x 1 root root 1837 Nov 24 2019 config.txt
drwxr-xr-x 21 root root 4096 Nov 24 2019 ..
-rwxr-xr-x 1 root root 4921296 Nov 24 2019 vmlinuz-5.3.13
-rwxr-xr-x 1 root root 168112 Nov 24 2019 config-5.3.13
-rwxr-xr-x 1 root root 2267409 Nov 24 2019 System.map-5.3.13
-rwxr-xr-x 1 root root 1014 Nov 26 2019 boot.cmd
-rwxr-xr-x 1 root root 1086 Nov 26 2019 boot.scr
-rwxr-xr-x 1 root root 0 Oct 11 2020 hoopdriveAs you can see, the reboot has not honoured the changes I made to /boot/cmdline,txt and the network interface name is unchanged.
I don't know what is going on and why this is the case. All I can think of is that the release of devuan for the Raspberry Pi is using a different boot loader than expected or is following some other path into the system.
Anybody any other ideas - I've never dug this far into the pi boot process before, I've always been quite happy with how it works out of the box and never needed to bother about the exact boot loader or boot mechanism.
Offline
#12 2020-10-12 01:13:03
- c0rnelius
- Member
- Registered: 2020-06-13
- Posts: 51
Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding
I don't own an early rpi, but if ur using u-boot, you don't need the cmdline.txt file, this is what the boot.cmd/boot.src is replacing. Personally I would avoid boot.src if you can and instead use /boot/extlinux/extlinux.conf. You also don't need most of those *.elf and *dat files. You should only need: bootcode.bin, start.elf and fixup.dat
As for the interface name changing, I was under the impression Devuan didn't need a udev rule on the pi? But if so this is the rule I use in my images. Simply change wlan0 to the eth0.
Offline
#13 2020-10-12 02:11:19
- tuxd3v
- Member
- Registered: 2019-11-14
- Posts: 183
Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding
There seems something wrong with the image linked in posts #5 and #6 ...
Hello FM81,
In post #6, I don't know,
But in post #5 everything is ok 
bootargs earlyprintk=serial,ttyAMA0,115200 console=ttyAMA0,115200n8 console=tty0 root=/dev/mmcblk0p2 rw rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait noinitrd
~# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.10.255
inet6 fe80::ba26:ebff:fea8:a296 prefixlen 64 scopeid 0x20<link>
ether f8:27:eb:a7:a3:96 txqueuelen 1000 (Ethernet)
RX packets 1382943 bytes 106525951 (101.5 MiB)
RX errors 0 dropped 132 overruns 0 frame 0
TX packets 1322685 bytes 289342986 (275.9 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 197 bytes 17372 (16.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 197 bytes 17372 (16.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
~# cat /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="f8:27:eb:a7:a3:96", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
~# cat /proc/cmdline
console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait
~# cat /proc/cpuinfo
processor : 0
model name : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS : 697.95
Features : half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7
Hardware : BCM2835
Revision : 0000
Serial : 00000000b5a8d596I am using that Image with a udev rule,
Because without the udev rule, you got a crazy name for the interface, and no iptables .-.
Hi tux3dv,
that's the one I built from :-)
I'm running a very early Raspberry Pi Model B :-[Hardware : BCM2835 Revision : 0000 Serial : 00000000ba27b441
I am running a even earlier version,
Just look to the serial number
Its the v1.0, 256MB Ram. Later they released the v1.1, with 512MB Ram..
But hey, I have Zram up and running
Last edited by tuxd3v (2020-10-12 02:35:19)
Best Regards,
tux
Offline
#14 2020-10-12 11:21:17
- hoopdriver
- Member
- Registered: 2020-10-08
- Posts: 10
Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding
This is all getting a bit strange. Where I am now is not where I want to be - it's getting further into the low level boot process than I wanted to. All I want is to have the boot label my network interfaces to be eth0. I have 'fixed' the problem using udev rules. I don't think udev rules is the optimal solution though I think it may be the most likely to not be clobbered by a future apt-get update.
I have made changes to /boot/cmdline.txt and they have not been passed to the booting kernel, from this I can conclude that we beowulf is not using the classic raspberry pi process.
The files in /boot seem to indicate that beowulf is using u-boot as the boot loader. I copied /boot/boot.cmd to /boot/hoopdriver-boot.cmd and added noquiet nosplash net.ifnames=0 to the bootargs variable :-
setenv bootargs earlyprintk=serial,ttyAMA0,115200n8 console=ttyAMA0,115200n8 console=tty0 root=/dev/mmcblk0p2 rw rootfstype=ext4 elevator=noop fsck.repair=yes rootwait smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=ttyAMA0,115200 selinux=0 net.ifnames=0 noquiet nosplash noinitrdand then made a new boot.scr from this :-
mv boot.scr boot.scr.original
mkimage -A arm -O linux -T script -C none -n boot.scr -d hoopdriver-boot.cmd boot.scrand then rebooted. I get tux splash screen, no messages and after a few seconds the root login prompt. I can say that I have changed the boot process :-) It's still not honouring the command line arguments :
Before : /boot# cat /proc/cmdline
earlyprintk=serial,ttyAMA0,115200n8 console=ttyAMA0,115200n8 console=tty0 root=/dev/mmcblk0p2 rw rootfstype=ext4 elevator=noop fsck.repair=yes rootwait smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=ttyAMA0,115200 selinux=0 noinitrd
And
After : cat /proc/cmdline
console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwaitI need to do some more dgging to find out what's going on. At the moment, I'm a bit frustrated that beowulf has been put out and there are some significant changes that have been made to the boot process that haven't really been documented. This is schoolboy errors by veteran sysadmins :-(
Offline
#15 2020-10-12 16:52:47
- tuxd3v
- Member
- Registered: 2019-11-14
- Posts: 183
Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding
This is all getting a bit strange.
(...)
I can say that I have changed the boot process :-) It's still not honouring the command line arguments :Before : /boot# cat /proc/cmdline earlyprintk=serial,ttyAMA0,115200n8 console=ttyAMA0,115200n8 console=tty0 root=/dev/mmcblk0p2 rw rootfstype=ext4 elevator=noop fsck.repair=yes rootwait smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=ttyAMA0,115200 selinux=0 noinitrd And After : cat /proc/cmdline console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait
I and C0rnelious,
told you about it not being honouring the bootargs..
Tha's why we went with a udev rule..
Now,
My udev rule has a side effect( I can't predict in advance what mac address you will have in another sbc board, so it needs editing ).
But I haven't found a better way 
Best Regards,
tux
Offline
#16 2020-10-12 21:07:45
- emojifreak
- Member
- Registered: 2020-10-06
- Posts: 15
Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding
I and C0rnelious,
told you about it not being honouring the bootargs..
Tha's why we went with a udev rule..
...
But I haven't found a better way
FYI, Devuan Chimaera linux-image-rpi, linux-image-armmp, linux-image-armmp-lpae,
and linux-image-arm64 packages allows almost the same boot process with Rasibian OS,
by the help of raspi3-firmware package (in Devuan).
Thus they use cmdline.txt.
Devuan Beowulf should be the same except Raspberry Pi 4, which needs
very recent kernels (e.g. 5.8).
To make a bootable filesystem, qemu-debootstrapping the following packages is enough:
linux-image-rpi,
sysvinit-core,
eudev,
kmod,
e2fsprogs,
raspi3-firmware,
firmware-brcm80211
Offline
#17 2020-10-12 21:10:39
- hoopdriver
- Member
- Registered: 2020-10-08
- Posts: 10
Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding
[
I and C0rnelious,
told you about it not being honouring the bootargs..
Tha's why we went with a udev rule..Now,
My udev rule has a side effect( I can't predict in advance what mac address you will have in another sbc board, so it needs editing ).
But I haven't found a better way
This goes to the crux of the problem. There's nothing wrong with a udev rule, there's nothing wrong changing the boot loader config, either way _should_ get you the desied result. What I want is an official way of doing it, e.g. the image as released should do it, as end users we shouldn't be having to kludge and hack about like this.
Look at it from a complete and utter novices perspective, it's confusing and looks nothing like the docs (there's no grub involved for instance). Is a new user going to go on and evangelise about the wonderful devuan on a pi or are they going to remember the pain of seemingly random network interfaces and having to muck about ?
You only have one opportunity to make a first impression and this doesn't give a good impression.
At worst, devuan could take take a leaf from raspbian and run a script at first boot that creates the udev rules etc, anything is better than having to spend a load of time scratching your head and googling to get a network interface name.
It's coming up to 6 months since it was released, maybe the next release will be different :-)
Offline
#18 2020-10-12 22:25:48
- Marjorie
- Member
- From: Teignmouth, UK
- Registered: 2019-06-09
- Posts: 221
Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding
The renaming of ethX and wlanX was something that was introduced in Debian 10 Buster and there was a warning about it in the Release Notes. Devuan Beowulf however retained the traditional names and when I've installed it (on AMD64 systems) it's worked out of the box.
I'm unclear how this was done. However I don't think the Devuan linux-images are patched (there aren't even any +deb10u1 markers on the more recent 4.19 linux-images).
My desktop PC which used wlan0 has a udev rule (/etc/udev/rules.d/70-persistent-net-rules)
# PCI device 0x168c:0x0030 (ath9k)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="c0:4a:00:1e:b5:03", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"My mail server, which uses eth0 doesn't.
Neither have the GRUB_CMDLINE_LINUX parameter set either.
Last edited by Marjorie (2020-10-12 22:34:41)
Offline
#19 2020-10-13 09:22:50
- tuxd3v
- Member
- Registered: 2019-11-14
- Posts: 183
Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding
hello,
This image is for Pi1, and so it tries to use less as possible, like C0rnelious told above, there are only some files needed for rpi1.
The idea was to boot a kernel 'u-boot.bin', and then use 'boot.scr', as a script to bring up the board..
afaik, its the most streamlined way of doing things in arm images..
Now this process may turn not to be ideal for rpi3 for example,
Which can have a role of a desktop image, and will need to use the graphics card..
This rpi1 image has a role of server, and is works very well, I have been using it since it was released, with no problems at all
Best Regards,
tux
Offline
#20 2020-10-14 00:01:44
- emojifreak
- Member
- Registered: 2020-10-06
- Posts: 15
Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding
By the help of raspi3-firmware Devuan package, building an SD card image
has become much easier than before, for example
https://raspi.debian.net/daily-images/
https://github.com/emojifreak/debian-rpi-image-script (can build Devuan image)
https://evolvis.org/plugins/scmgit/cgi- … sh;hb=HEAD
Building one's own image may be a good alternative to download an image and write it to an SD card.
By the way, as far as I know, u-boot.bin can be bypassed with recent versions of mainline Devuan/Debian kernels.
Offline
#21 2020-10-14 03:08:56
- c0rnelius
- Member
- Registered: 2020-06-13
- Posts: 51
Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding
Although I don't own the early rpi, I do include the dtbs for the boards in my builds.
You are more than welcome to give it/them a try and see if it better fits your needs.
https://github.com/pyavitz/rpi-img-builder
https://github.com/pyavitz/rpi-img-buil … tag/images
Offline
#22 2020-10-18 14:36:09
- hoopdriver
- Member
- Registered: 2020-10-08
- Posts: 10
Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding
Hi,
Apologies for the late reply and many thanks for the help above.
I've built the SD image from stock beowulf, added /etc/udev/rules.d/73-usb-net-by-mac.rules and got the system working. It's stable and survives reboots etc. and I'll be shipping the SD card next week to be installed in the remote Pi so hopefully it will run happily for another five years :-)
I think the next one I build will be wholly custom using raspi3-firmware.
I'm looking at netbsd as another alternative but TBH, none of the alternatives really suit my requirements. Being a bit old, I can remember building early linux on 386 hardware and getting by comfortably with 512MB hard drives etc. Nowadays, most stock distros come in at 1GB or over.
Offline
#23 2020-10-20 03:40:21
- tuxd3v
- Member
- Registered: 2019-11-14
- Posts: 183
Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding
hello hoopdriver,
Nice you succeded..
Yes the image is pretty solid, it will last..
Just ensure to use a good SDCard, like a new one, without any type of usage..in that way, you will ensure system will run for a longer period of time.
Best Regards,
tux
Offline
