The officially official Devuan Forum!

You are not logged in.

#1 2020-10-08 21:19:18

hoopdriver
Member
Registered: 2020-10-08
Posts: 8  

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]^C

it 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: Clifton Hill, Victoria, AUS
Registered: 2016-11-30
Posts: 468  

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: 2,076  

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: 8  

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

A 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-free

It 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 1970

No 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 2020

I 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 ntp

I created a stub /etc/ntp.conf :-

root@rhubarb:~# cat /etc/ntp.conf 
server ntp1.npl.co.uk
server ntp2.npl.co.uk

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

picks 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

#5 2020-10-09 15:05:05

tuxd3v
Member
Registered: 2019-11-14
Posts: 135  

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?


Best Regards,
tux

Offline

#6 2020-10-09 16:37:35

hoopdriver
Member
Registered: 2020-10-08
Posts: 8  

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

tuxd3v wrote:

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 kB

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

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: 8  

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 noinitrd

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

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: 23  

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


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: 8  

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

Offline

#12 2020-10-12 01:13:03

c0rnelius
Member
Registered: 2020-06-13
Posts: 4  

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: 135  

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

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 smile

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		: 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 smile

Its the v1.0, 256MB Ram. Later they released the v1.1, with 512MB Ram..
But hey, I have Zram up and running smile

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: 8  

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

Offline

#15 2020-10-12 16:52:47

tuxd3v
Member
Registered: 2019-11-14
Posts: 135  

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

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  sad


Best Regards,
tux

Offline

#16 2020-10-12 21:07:45

emojifreak
Member
Registered: 2020-10-06
Posts: 11  

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: 8  

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

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  sad

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: 90  

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: 135  

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 smile


Best Regards,
tux

Offline

#20 2020-10-14 00:01:44

emojifreak
Member
Registered: 2020-10-06
Posts: 11  

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: 4  

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: 8  

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: 135  

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


Best Regards,
tux

Offline

Board footer