Dev1 Galaxy Forum / beowulf Raspberry Pi build, packages.roundr.devuan.org not responding

Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding

dummy@example.com (tuxd3v) — Tue, 20 Oct 2020 03:40:21 +0000

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.

Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding

dummy@example.com (hoopdriver) — Sun, 18 Oct 2020 14:36:09 +0000

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.

Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding

dummy@example.com (c0rnelius) — Wed, 14 Oct 2020 03:08:56 +0000

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

Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding

dummy@example.com (emojifreak) — Wed, 14 Oct 2020 00:01:44 +0000

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.

Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding

dummy@example.com (tuxd3v) — Tue, 13 Oct 2020 09:22:50 +0000

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

Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding

dummy@example.com (Marjorie) — Mon, 12 Oct 2020 22:25:48 +0000

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.

Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding

dummy@example.com (hoopdriver) — Mon, 12 Oct 2020 21:10:39 +0000

tuxd3v wrote:

[
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 :-)

Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding

dummy@example.com (emojifreak) — Mon, 12 Oct 2020 21:07:45 +0000

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

Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding

dummy@example.com (tuxd3v) — Mon, 12 Oct 2020 16:52:47 +0000

hoopdriver wrote:

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

Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding

dummy@example.com (hoopdriver) — Mon, 12 Oct 2020 11:21:17 +0000

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  noinitrd

and 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.scr

and 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 rootwait

I 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 :-(

Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding

dummy@example.com (tuxd3v) — Mon, 12 Oct 2020 02:11:19 +0000

FM81 wrote:

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  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
        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  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10
        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		: 00000000b5a8d596

I am using that Image with a udev rule,
Because without the udev rule, you got a crazy name for the interface, and no iptables .-.

hoopdriver wrote:

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

Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding

dummy@example.com (c0rnelius) — Mon, 12 Oct 2020 01:13:03 +0000

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.

Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding

dummy@example.com (hoopdriver) — Sun, 11 Oct 2020 20:06:21 +0000

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.xz

Download 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/s

Write 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  Linux

Let'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 /mnt

That 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 /mnt

It 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  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  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10
        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.sh

This 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:~# exit

And rebooted the pi and got :-

root@RPi1:~# ifconfig -a
enxb827ebb9e313: flags=4098  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  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10
        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 hoopdrive

As 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.

Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding

dummy@example.com (FM81) — Sun, 11 Oct 2020 09:03:19 +0000

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.sh

It 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

Re: beowulf Raspberry Pi build, packages.roundr.devuan.org not responding

dummy@example.com (emojifreak) — Sun, 11 Oct 2020 00:55:59 +0000

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