Download | Devuan.org | Git | Bugs | Packages

The officially official Devuan Forum!

You are not logged in.

Pages: 1

#1 Re: Devuan » Devuan, udev, eudev, systemd.udev where are we now ? » 2021-10-28 18:19:40

hoopdriver

Wow - thanks for that.  It would have been nice to find the project myself but there seems to be a bit of a black hole for it.  I spent a few hours looking around on various search engines and the Gentoo forums but couldn't find any reference to eudev continuation - it seemed as if Gentoo had decided that eudev was dead and there was no need for anything other than systemd.udev.

Reading round it seems that systemd.udev wasn't just appropriated by the systemd team, they also re-worked it and improved it so it performs better and isn't as tightly coupled with systemd as expected so can be used without systemd.

It may be that LP, KS & GKH are there to help :-)

#2 Devuan » Devuan, udev, eudev, systemd.udev where are we now ? » 2021-10-28 08:18:58

hoopdriver
Replies: 4

I stupidly upgraded my Mint desktop a few weeks ago and have regretted it since.

I started looking round for alternatives and in the process stumbled on the problem with udev.  It was absorbed into systemd a few years ago and this caused a bit of froth so those nice people at Gentoo decided to do eudev... and the world was rosy.

Earlier this year, Gentoo announced eudev was being dropped and they were going to use systemd.udev and I understand the reasoning behind this.

What I'm trying to work out is how eudev being dropped by Gentoo is going to affect all the other distributions that have been using it.  There are other *dev options out there but systemd.udev does seem to be gaining traction.

I can't find anything on this forum regarding the situation, can somebody enlighten me ?

#3 Re: ARM Builds » beowulf Raspberry Pi build, packages.roundr.devuan.org not responding » 2020-10-18 14:36:09

hoopdriver

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.

#4 Re: ARM Builds » beowulf Raspberry Pi build, packages.roundr.devuan.org not responding » 2020-10-12 21:10:39

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

#5 Re: ARM Builds » beowulf Raspberry Pi build, packages.roundr.devuan.org not responding » 2020-10-12 11:21:17

hoopdriver

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

#6 Re: ARM Builds » beowulf Raspberry Pi build, packages.roundr.devuan.org not responding » 2020-10-11 20:06:21

hoopdriver

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.

#7 Re: ARM Builds » beowulf Raspberry Pi build, packages.roundr.devuan.org not responding » 2020-10-10 14:31:33

hoopdriver

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.

#8 Re: ARM Builds » beowulf Raspberry Pi build, packages.roundr.devuan.org not responding » 2020-10-09 16:37:35

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

#9 Re: ARM Builds » beowulf Raspberry Pi build, packages.roundr.devuan.org not responding » 2020-10-09 08:33:10

hoopdriver

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

#10 ARM Builds » beowulf Raspberry Pi build, packages.roundr.devuan.org not responding » 2020-10-08 21:19:18

hoopdriver
Replies: 22

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

Pages: 1

Board footer

Forum Software