The officially official Devuan Forum!

Johnnie390

Member

From: EU

Registered: 2018-12-09

Posts: 16  

Website

Re: Is any work planned for devuan on the raspberry pi 4?

c0rnelius,

thanks for the information. I was going to use chroot on another machine to change the root password. It seems there is an easier way.

Will report back.

Regards,

J.

Johnnie390

Member

From: EU

Registered: 2018-12-09

Posts: 16  

Website

Re: Is any work planned for devuan on the raspberry pi 4?

Thanks to all for the assistance. Everything (LXDE & Co.) is working as it should.

Regards,

J.

vladomiro

Member

Registered: 2021-04-02

Posts: 7  

Re: Is any work planned for devuan on the raspberry pi 4?

I can't speak for LXDE, but Xfce appears to be working just fine: screenshot
Only thing that really needed adjusting was adding pulseaudio -D to Session and Startup

XFCE is working fine, but only have a small problem: pulse audio doesn't detect stereo sound, only plays mono analogic. Do you know a way to tell pulse audio there is a stereo option?

Everything else works great, I use it as a desktop PC and even have used it to broadcast audio to an icescast server (of course, without using the audio card).

c0rnelius

Member

Registered: 2020-06-13

Posts: 51  

Re: Is any work planned for devuan on the raspberry pi 4?

I can't speak for LXDE, but Xfce appears to be working just fine: screenshot
Only thing that really needed adjusting was adding pulseaudio -D to Session and Startup

XFCE is working fine, but only have a small problem: pulse audio doesn't detect stereo sound, only plays mono analogic. Do you know a way to tell pulse audio there is a stereo option?

Everything else works great, I use it as a desktop PC and even have used it to broadcast audio to an icescast server (of course, without using the audio card).

Edit the following file: /usr/share/pulseaudio/alsa-mixer/profile-sets/default.conf
Example: https://github.com/pyavitz/rpi-img-buil … .conf#L104 to L109

Then reboot. After which it should default to stereo.

vladomiro

Member

Registered: 2021-04-02

Posts: 7  

Re: Is any work planned for devuan on the raspberry pi 4?

I can't speak for LXDE, but Xfce appears to be working just fine: screenshot
Only thing that really needed adjusting was adding pulseaudio -D to Session and Startup

XFCE is working fine, but only have a small problem: pulse audio doesn't detect stereo sound, only plays mono analogic. Do you know a way to tell pulse audio there is a stereo option?

Everything else works great, I use it as a desktop PC and even have used it to broadcast audio to an icescast server (of course, without using the audio card).

Edit the following file: /usr/share/pulseaudio/alsa-mixer/profile-sets/default.conf
Example: https://github.com/pyavitz/rpi-img-buil … .conf#L104 to L109

Then reboot. After which it should default to stereo.

It works. Thank you very much.

Camtaf

Member

Registered: 2019-11-19

Posts: 436  

Re: Is any work planned for devuan on the raspberry pi 4?

Installed & started out using just CLI, including Links2, with mc & mpg123, but just had to add Fluxbox & Firefox-esr......

Great little starter distro/version, likely I'll be dumping RaspiOS from my Pis soon, (as it seems to be somewhat bloated - & of course, has that systemd mess).

Many thanks for your work, (I got my download from Devuan.org this time).

Last edited by Camtaf (2021-05-30 10:56:09)

Aconcagua

Member

Registered: 2021-06-07

Posts: 3  

Re: Is any work planned for devuan on the raspberry pi 4?

Tried out, required yet a bit of extra work, but finally without systemd. Solely the WiFi adapter is not recognised. Anyone suffering from the same problem? Any hints?

c0rnelius

Member

Registered: 2020-06-13

Posts: 51  

Re: Is any work planned for devuan on the raspberry pi 4?

Tried out, required yet a bit of extra work, but finally without systemd. Solely the WiFi adapter is not recognised. Anyone suffering from the same problem? Any hints?

Did it ever work or did you install something and it stopped working? If it wasn't setup upon firstboot, it can than be done manually using the following script.

vortex

Member

Registered: 2020-11-12

Posts: 14  

Re: Is any work planned for devuan on the raspberry pi 4?

Tried out, required yet a bit of extra work, but finally without systemd. Solely the WiFi adapter is not recognised. Anyone suffering from the same problem? Any hints?

Thanks to c0rnelius' builder work, Devuan Pi RPi4 images are located at arm-files.devuan.org.

At least for these images, the onboard WiFi interface is recognised, but you will need to configure

/etc/wpa_supplicant/wpa_supplicant.conf

for your WiFi network, or use the script mentioned in previous post.

Aconcagua

Member

Registered: 2021-06-07

Posts: 3  

Re: Is any work planned for devuan on the raspberry pi 4?

Need to admit, didn't pay attention if WiFi was available right from the start or not, was concentrated on other stuff. Cleared the SD card again and tried the image at arm-files.devuan.org, but failed it to complete boot process, was trying to run some script again and again (suppose the init script).

Restarted with the image at https://github.com/pyavitz/rpi-img-buil … tag/images, booted so far, `ip addr` seems to reveal two adapters, not fully sure, though, as console prints several characters at the left out of the screen (how to fix?). Once network is set up correctly that won't disturb me too much any more as I'll be accessing the RPi via ssh anyway...

Didn't find the first image in the forum history any more (the one with root + toor login), so cannot tell if that would had recognised the wlan card right from the beginning.

c0rnelius

Member

Registered: 2020-06-13

Posts: 51  

Re: Is any work planned for devuan on the raspberry pi 4?

Need to admit, didn't pay attention if WiFi was available right from the start or not, was concentrated on other stuff. Cleared the SD card again and tried the image at arm-files.devuan.org, but failed it to complete boot process, was trying to run some script again and again (suppose the init script).

Restarted with the image at https://github.com/pyavitz/rpi-img-buil … tag/images, booted so far, `ip addr` seems to reveal two adapters, not fully sure, though, as console prints several characters at the left out of the screen (how to fix?). Once network is set up correctly that won't disturb me too much any more as I'll be accessing the RPi via ssh anyway...

Didn't find the first image in the forum history any more (the one with root + toor login), so cannot tell if that would had recognised the wlan card right from the beginning.

I just flashed the img from the github and this is what I get.

patrick@devuan-test:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether dc:a6:32:52:16:57 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether dc:a6:32:52:16:58 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.164/24 brd 10.0.0.255 scope global dynamic wlan0
       valid_lft 172791sec preferred_lft 172791sec
    inet6 2601:586:4d80:3830:dea6:32ff:fe52:1658/64 scope global dynamic mngtmpaddr 
       valid_lft 598sec preferred_lft 298sec
    inet6 fe80::dea6:32ff:fe52:1658/64 scope link 
       valid_lft forever preferred_lft forever
patrick@devuan-test:~$ sudo iwconfig
lo        no wireless extensions.

eth0      no wireless extensions.

wlan0     IEEE 802.11  ESSID:"*REMOVED*"  
          Mode:Managed  Frequency:5.785 GHz  Access Point: A2:3D:CF:FF:C5:EB   
          Bit Rate=433.3 Mb/s   Tx-Power=31 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=66/70  Signal level=-44 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

As for hostapd which was mentioned, but now gone??? I know nothing of the subject and as far as that's concerned, someone else would need to help you out on that front.

Last edited by c0rnelius (2021-06-09 03:11:00)

Camtaf

Member

Registered: 2019-11-19

Posts: 436  

Re: Is any work planned for devuan on the raspberry pi 4?

The images that I downloaded from the Devuan site worked OK, just had to enter my wifi details into supplicant.conf - rebooted & wifi came up OK.

(Both on the RPi4 & RPi3 images.)

Last edited by Camtaf (2021-06-09 08:31:49)

ehem

Member

Registered: 2021-07-24

Posts: 10  

Re: Is any work planned for devuan on the raspberry pi 4?

Is there any hope Raspberry PI 4B images with U-Boot => GRUB will show up?

I like being able to easily boot previous kernels when the latest fails (modified kernels do fail and sometimes security update kernels have introduced severe reversions).  Also the Raspberry PI 4B has hardware suitable for running Xen and recent versions of GRUB (2.02 has the module, but only >=2.04 has an appropriate /etc/grub.d/20_linux_xen) will load Xen/ARM64 out of the box.

c0rnelius

Member

Registered: 2020-06-13

Posts: 51  

Re: Is any work planned for devuan on the raspberry pi 4?

Is there any hope Raspberry PI 4B images with U-Boot => GRUB will show up?

I like being able to easily boot previous kernels when the latest fails (modified kernels do fail and sometimes security update kernels have introduced severe reversions).  Also the Raspberry PI 4B has hardware suitable for running Xen and recent versions of GRUB (2.02 has the module, but only >=2.04 has an appropriate /etc/grub.d/20_linux_xen) will load Xen/ARM64 out of the box.

This would be easier to accomplish using u-boot and extlinux, with extlinux you can add an optional menu. One problem though, would be the current kernel packaging, as currently it purges the old kernel, dtbs, initrd, overlays and headers during install.

As for Grub, I've played around with it on other SBCs, but am not 100% sure how to set that up correctly on a Pi.

ehem

Member

Registered: 2021-07-24

Posts: 10  

Re: Is any work planned for devuan on the raspberry pi 4?

Is there any hope Raspberry PI 4B images with U-Boot => GRUB will show up?

I like being able to easily boot previous kernels when the latest fails (modified kernels do fail and sometimes security update kernels have introduced severe reversions).  Also the Raspberry PI 4B has hardware suitable for running Xen and recent versions of GRUB (2.02 has the module, but only >=2.04 has an appropriate /etc/grub.d/20_linux_xen) will load Xen/ARM64 out of the box.

This would be easier to accomplish using u-boot and extlinux, with extlinux you can add an optional menu. One problem though, would be the current kernel packaging, as currently it purges the old kernel, dtbs, initrd, overlays and headers during install.

That doesn't seem easier except for the first time setup.  Maintenance is harder since it means spinning everything by hand, whereas GRUB has everything scripted out of the box.

More importantly, you missed the second part.  I don't believe extlinux can load Xen (two kernels plus an initial ramdisk).

As for Grub, I've played around with it on other SBCs, but am not 100% sure how to set that up correctly on a Pi.

You use U-Boot's UEFI support to have it load GRUB (SuSE uses this approach).  While wasteful due to having an extra bootloader stage, you gain GRUB's massively better functionality.

c0rnelius

Member

Registered: 2020-06-13

Posts: 51  

Re: Is any work planned for devuan on the raspberry pi 4?

Is there any hope Raspberry PI 4B images with U-Boot => GRUB will show up?

I like being able to easily boot previous kernels when the latest fails (modified kernels do fail and sometimes security update kernels have introduced severe reversions).  Also the Raspberry PI 4B has hardware suitable for running Xen and recent versions of GRUB (2.02 has the module, but only >=2.04 has an appropriate /etc/grub.d/20_linux_xen) will load Xen/ARM64 out of the box.

This would be easier to accomplish using u-boot and extlinux, with extlinux you can add an optional menu. One problem though, would be the current kernel packaging, as currently it purges the old kernel, dtbs, initrd, overlays and headers during install.

That doesn't seem easier except for the first time setup.  Maintenance is harder since it means spinning everything by hand, whereas GRUB has everything scripted out of the box.

More importantly, you missed the second part.  I don't believe extlinux can load Xen (two kernels plus an initial ramdisk).

As for Grub, I've played around with it on other SBCs, but am not 100% sure how to set that up correctly on a Pi.

You use U-Boot's UEFI support to have it load GRUB (SuSE uses this approach).  While wasteful due to having an extra bootloader stage, you gain GRUB's massively better functionality.

You aren't taking under account kernel packaging and the problems therein. Not to mention overlays and whatnots are gonna be different between kernel revisions, so now that would also need to be taken under consideration. Grub would also need to be scripted to know what to look for, which presents even more headaches.

Even other SBCs that use grub aren't trying to boot more than one kernel, as there is a lot of things to account for. But hey, if you feel like looking into it and investing the time and effort to make it work, go for it.

Last edited by c0rnelius (2021-07-26 22:31:59)

ehem

Member

Registered: 2021-07-24

Posts: 10  

Re: Is any work planned for devuan on the raspberry pi 4?

As for Grub, I've played around with it on other SBCs, but am not 100% sure how to set that up correctly on a Pi.

You use U-Boot's UEFI support to have it load GRUB (SuSE uses this approach).  While wasteful due to having an extra bootloader stage, you gain GRUB's massively better functionality.

You aren't taking under account kernel packaging and the problems therein. Not to mention overlays and whatnots are gonna be different between kernel revisions, so now that would also need to be taken under consideration. Grub would also need to be scripted to know what to look for, which presents even more headaches.

Even other SBCs that use grub aren't trying to boot more than one kernel, as there is a lot of things to account for. But hey, if you feel like looking into it and investing the time and effort to make it work, go for it.

There was some discussion on Debian bug #824954.  Some of the necessary scripting can be found as GRUB wishlist #52939.

This though is only needed for covering the most extreme case, where GRUB needs to load a kernel-specific device-tree.  This isn't needed if you're switching between kernel patch levels, which is adequate if you're switching between 5.10.0-1 and 5.10.0-2 (which would be security update versions).  This is also overkill if you're simply rebuilding Devuan's kernel source with custom configuration.

You're also yet again ignoring the other highly important issue.  It is possible, but quite difficult to boot Xen directly from U-Boot.  Whereas, GRUB will boot Xen out of the box.

In other news I find device-trees rather underwhelming.  Most UEFI implementations will boot Linux kernels from 3.0 to 5.10 with the exact same implementation.  The same implementation will also boot *BSD, or other closed OSes from Redmond.  Yet a device-tree implementation is only likely to work with one kernel version of one OS.

Last edited by ehem (2021-07-27 01:12:41)

c0rnelius

Member

Registered: 2020-06-13

Posts: 51  

Re: Is any work planned for devuan on the raspberry pi 4?

You use U-Boot's UEFI support to have it load GRUB (SuSE uses this approach).  While wasteful due to having an extra bootloader stage, you gain GRUB's massively better functionality.

You aren't taking under account kernel packaging and the problems therein. Not to mention overlays and whatnots are gonna be different between kernel revisions, so now that would also need to be taken under consideration. Grub would also need to be scripted to know what to look for, which presents even more headaches.

Even other SBCs that use grub aren't trying to boot more than one kernel, as there is a lot of things to account for. But hey, if you feel like looking into it and investing the time and effort to make it work, go for it.

There was some discussion on Debian bug #824954.  Some of the necessary scripting can be found as GRUB wishlist #52939.

This though is only needed for covering the most extreme case, where GRUB needs to load a kernel-specific device-tree.  This isn't needed if you're switching between kernel patch levels, which is adequate if you're switching between 5.10.0-1 and 5.10.0-2 (which would be security update versions).  This is also overkill if you're simply rebuilding Devuan's kernel source with custom configuration.

You're also yet again ignoring the other highly important case.  It is possible, but quite difficult to boot Xen directly from U-Boot.  Whereas, GRUB will boot Xen out of the box.

In other news I find device-trees rather underwhelming.  Most UEFI implementations will boot Linux kernels from 3.0 to 5.10 with the exact same implementation.  The same implementation will also boot *BSD, or other closed OSes from Redmond.  Yet a device-tree implementation is only likely to work with one kernel version of one OS.

I'm not ignoring it, I just don't care I find it at this time to be a bit fruitless, hence why I suggested if you wanna put in the work to make it happen. Have at it!

You can simply review the latest changes in mainline to find what ur saying about kernel revisions isn't accurate at this time: https://git.kernel.org/pub/scm/linux/ke … 10.52&dt=2

I'm not against getting this working, I'm simply saying that the effort needed to get that done would be very time consuming.

Cheers!

ehem

Member

Registered: 2021-07-24

Posts: 10  

Re: Is any work planned for devuan on the raspberry pi 4?

I'm not ignoring it, I just don't care I find it at this time to be a bit fruitless, hence why I suggested if you wanna put in the work to make it happen. Have at it!

Numerous people have demonstrated it isn't much work, and has distinct benefits.  Most of the work is getting people claiming it is too much work to get out of the way.

In other news I find device-trees rather underwhelming.  Most UEFI implementations will boot Linux kernels from 3.0 to 5.10 with the exact same implementation.  The same implementation will also boot *BSD, or other closed OSes from Redmond.  Yet a device-tree implementation is only likely to work with one kernel version of one OS.

You can simply review the latest changes in mainline to find what ur saying about kernel revisions isn't accurate at this time: https://git.kernel.org/pub/scm/linux/ke … 10.52&dt=2

I think you just demonstrated why I'm highly underwhelmed by device-trees.  Their implementation is awful.

I'm not against getting this working, I'm simply saying that the effort needed to get that done would be very time consuming.

No, it isn't.  I'm far from expert in these pieces, but I've gotten things functioning without much work.  A very little bit of scripting might be needed, the main work is keeping the pieces synchronized.  Mostly needing to keep a combination of U-Boot, GRUB and device-tree which are compatible together.

Have I mentioned device-trees are garbage?  (this could merely be an issue of lack of standards, whereas UEFI was an organization behind it keeping things mostly sane)

Last edited by ehem (2021-07-27 02:01:07)

c0rnelius

Member

Registered: 2020-06-13

Posts: 51  

Re: Is any work planned for devuan on the raspberry pi 4?

ehem

Lets say we use u-boot. The DTB file can't be defined in extlinux, as the next stage of the bootloader will get confused and at worst not boot at all. If it did boot by chance, it would be all out of whack and certain onboard things wouldn't work. How do I know this? I've experimented with it

Your hate of the device-tree doesn't change how the bootloader works. In all honesty it would probs be easier to get a multi OS boot before a multi kernel boot on the same medium.

As for the device-tree, its essential. There are no if and or buts about it. This is not your Dads x86 computer Not all DTB files are gonna support the next kernel exactly the same and there isn't much any of us can do about it and unfortunately defining that DTB using extlinux and or grub is gonna create a headache in the boot process.

Of course, I'm just going on my own testing. I welcome you to play with it and see if you can get further.

Edit:
I'll extend an olive branch. How would one define which DTB to use for each kernel, if the DTB is undefinable?

Last edited by c0rnelius (2021-07-27 02:35:04)

ehem

Member

Registered: 2021-07-24

Posts: 10  

Re: Is any work planned for devuan on the raspberry pi 4?

Lets say we use u-boot. The DTB file can't be defined in extlinux, as the next stage of the bootloader will get confused and at worst not boot at all. If it did boot by chance, it would be all out of whack and certain onboard things wouldn't work. How do I know this? I've experimented with it

Okay.  So what?  You're using `extlinux` which cannot load device-trees.  GRUB can and I already pointed to someone who had a patch for their scripts which functioned (updates to the scripts mean the patch no longer applies, but it isn't difficult to update by hand).

Of course, I'm just going on my own testing. I welcome you to play with it and see if you can get further.

I already had it functioning more than 6 months ago.  Polish is needed, but the boot sequence U-Boot => GRUB is workable.

c0rnelius

Member

Registered: 2020-06-13

Posts: 51  

Re: Is any work planned for devuan on the raspberry pi 4?

Extlinux can load device-trees. It is the next stage of the bootloader on the Pi that gets confused, which is really just the first stage. That's the So what? As you so finely put it.

If you've had it working for 6 months why are you keeping it a secret and being a jerk about it here? Why not just contribute?

ehem

Member

Registered: 2021-07-24

Posts: 10  

Re: Is any work planned for devuan on the raspberry pi 4?

I'll extend an olive branch. How would one define which DTB to use for each kernel, if the DTB is undefinable?

This edit came in after I was already typing.  What do you mean?

Unfortunately the functionality is usually provided by the `flash-kernel` package, but if `flash-kernel` is installed it will copy the appropriate DTB from /usr/lib/<kernel-version> to /boot/dtb-<kernel-version>.  The GRUB wishlist bug 52939 includes a patch for /etc/grub.d/10_linux to cause GRUB to load the device-tree from /boot/dtb-<kernel-version>.  The patch was made for an older version of GRUB thus needs manual application and also needs to modify /etc/grub.d/10_linux_xen.

c0rnelius

Member

Registered: 2020-06-13

Posts: 51  

Re: Is any work planned for devuan on the raspberry pi 4?

So if I'm reading that correctly it depends highly on kernel packaging, yes? I believe I've already went over this and suggested that the current packaging isn't adequate. It simply isn't suitable for multi kernel boot and I never set it up to do so.

ehem

Member

Registered: 2021-07-24

Posts: 10  

Re: Is any work planned for devuan on the raspberry pi 4?

So if I'm reading that correctly it depends highly on kernel packaging, yes? I believe I've already went over this and suggested that the current packaging isn't adequate. It simply isn't suitable for multi kernel boot and I never set it up to do so.

No, it simply needs appropriate scripts to be loaded on the machine.  Noticed how many on target machine scripts x86 kernel packages rely upon?  I will agree the packaging of kernels is suboptimal, but it is mostly good enough (notably on ARM Debian kernel packages shouldn't depend upon "flash-kernel", but upon "linux-kernel-installer" which is provided by "flash-kernel").

Extlinux can load device-trees. It is the next stage of the bootloader on the Pi that gets confused, which is really just the first stage. That's the So what? As you so finely put it.

That doesn't make sense.  `extlinux` is for loading a Linux kernel from an ext2/3/4 or btrfs filesystem.  The true earliest stage was the binary blob loaded by the Video Core portion of the chip, next stage is something which might be based off of syslinux which loads the kernel off of vfat (I recall reading the RP4 may skip the Video Core blob off of vfat).

If you've had it working for 6 months why are you keeping it a secret and being a jerk about it here? Why not just contribute?

I've been reporting experiments in places where others were reporting things.  I had hopes SuSE's approach would take over due to shear superiority (again, GRUB has much better boot functionality).  Since I need to give the outline here too...

Install the packages "u-boot-rpi", "raspi-firmware", "grub-efi-arm64", and "flash-kernel" (yuck, need a cut-down package "html5-kernel" which simply includes the scripts for copying device-tree files into appropriate placed, ideally using `cp -l`).

Setup the boot vfat filesystem.  Mount this as /boot/efi and then do the following:

cp /usr/lib/raspi-firmware/* /boot/efi

cp /usr/lib/u-boot/rpi_arm64/u-boot.bin /boot/efi/u-boot64.bin

cp /usr/lib/u-boot/rpi_3/u-boot.bin /boot/efi/u-boot3.bin
cp /usr/lib/u-boot/rpi_4/u-boot.bin /boot/efi/u-boot4.bin

grub-install --bootloader-id=BOOT
cp /boot/efi/EFI/BOOT/grubaa64.efi /boot/efi/EFI/BOOT/bootaa64.efi

echo bootaa64 > /boot/efi/startup.nsh

Now, I'm unsure whether `cp /boot/dtbs/$(uname -r)/broadcom/bcm2*-rpi*.dtb /boot/efi` is required; or perhaps as you've suggested U-Boot can make due with its built-in device-tree.  I've also run into a mention of GRUB merely being able to overwrite an incoming device-tree and not being able to install one from scratch.  You'll also want to adjust /etc/grub.d/10_linux* in line with the patch from here (the original patch is out of date).

These directions are not 100%, but they're most of the way there.  Biggest issue is getting the versions of everything lined up.