The officially official Devuan Forum!

You are not logged in.

#1 Re: ARM Builds » [Raspberry Pi 400] Why is wifi interface named wlan1 on the Pi400? » 2021-11-25 23:41:09

Well if you were using systemd you could just add net.ifnames=0 to the cmdline. But as this isn't an option on Devuan, you would need to play around with the udev rules.

sudo tee /etc/udev/rules.d/80-net-setup-link.rules <<EOF

SUBSYSTEM!="net", GOTO="net_setup_link_end"

IMPORT{builtin}="path_id"

ACTION!="add", GOTO="net_setup_link_end"

# IMPORT{builtin}="net_setup_link"

NAME=="", ENV{ID_NET_NAME}!="", NAME="wlan0"

LABEL="net_setup_link_end"
EOF

I use a rule like this to insure the ethernet interface comes up as eth0 on Pi3's.

#2 Re: ARM Builds » Any Chimaera Rpi3/4 builds in the pipeline? » 2021-11-13 14:24:35

The builders have now been updated to work on both Debian and Ubuntu. Although I haven't added Devuan as a supported Distro, I see no reason why reviewing the package list and installing manually wouldn't work.

https://github.com/pyavitz/rpi-img-builder
https://github.com/pyavitz/debian-image-builder

Cheers

#3 Re: ARM Builds » Any Chimaera Rpi3/4 builds in the pipeline? » 2021-11-03 13:43:41

batmore wrote:

>They need testing: https://github.com/pyavitz/binary/releases/tag/images

Here to tell you that the  rpi-devuan-chimaera-5.10.76-ext4-2021-10-30.img.xz  image worked a charm for my RaspberryPi Zero W stick.
I had to comment out the hardline lan eth0 stanza before the wifi worked, but after that it worked well.
Kudos to you on providing those images. Thanks much.

I tried your rpi-img-builder, but it refused to install/run on my Ceres box, said 'The OS you are running is not supported'.   
I'll install Chimaera and try again.  I'd be good to generate my own images with your tool to help.

I'm not sure why eth0 would be interfering with it, considering it doesn't have an ethernet port, but I'm happy you got it working.

As for the builder, because of the different versions of GCC and compilers it currently supports and will support in the future, I ended up moving it over to Ubuntu as the Host. Debian and Devuan stable for example only support GCC-9/10. The builder currently supports GCC-8/9/10 and by the start of next year will also support GCC-11 and CLang-13. Basically, Ubuntu unfortunately provides more options.

If need be docker is an option?

You can also install depends manually on Debian and Devuan, but just know certain options won't be available to you. Such as Clang and anything gcc-8 related if building on Bullseye or Chimaera.

#4 Re: ARM Builds » Any Chimaera Rpi3/4 builds in the pipeline? » 2021-10-31 15:11:25

They need testing: https://github.com/pyavitz/binary/releases/tag/images

I also included support for the Zero 2 W, but as I don't own the board yet, I'm not sure it boots and if it does, how well it works.

#5 Re: ARM Builds » Installer images for armel, armhf and ppc64 need testing » 2021-10-29 16:42:15

att2 wrote:

Well, that is my problem, because, on the officially supported Ubuntu image, these overlays do exist, and I have them in my "config.ini" file, and they work neatly ; but Ubuntu is booting terribly slow. Any recommendations of what, exactly, to do to get these overlays working in Devuan?

My suggestion would be to ask tobetter if he could please include the said overlays. I've only chit-chatted with him a few times concerning problems in the linux source, but he has always been really kind and receptive. He does include them for the Odroid N2/+ so i don't see why it would be that much of a stretch?

tobetter --> https://github.com/tobetter/linux

#6 Re: ARM Builds » Installer images for armel, armhf and ppc64 need testing » 2021-10-26 19:51:33

Is it possible to install Devuan on a Odroid C4 and use the tobetter kernel source which includes the overlays, yes. But I don't see all the overlays you are asking about?

ls /usr/lib/meson*/amlogic/overlays/odroidc4
hifishield2.dtbo  hktft35.dtbo  spi0.dtbo         w1-gpio_p15.dtbo
hktft32.dtbo      pcf8563.dtbo  sx865x-i2c1.dtbo  w1-gpio_p22.dtbo

Also the current imgs I build use extlinux and although it does have overlay support now, I have personally never tried to use it.

#7 Re: ARM Builds » Beowulf 3.1.0 arm64 rpi4 image fails to boot on recent RPI4 » 2021-10-05 16:28:01

The image you are using was made with the following builder: https://github.com/pyavitz/rpi-img-builder

I've made lots of changes to the builder since that img was created, one of those changes is in relation to firmware, how its installed and where its located. I don't use the firmware provided by Debian, Devuan or Ubuntu as its usually outdated and incomplete.

The firmware used --> https://github.com/pyavitz/firmware
The firmware function --> https://github.com/pyavitz/rpi-img-buil … ersal#L291
The line now added to the /boot/cmdline.txt --> firmware_class.path=/lib/firmware/updates/brcm

The script used to update kernels, firmware and userland: fetch -h

The gist of it in my opinion is that the imgs on the site need to be updated. I have no access and did not make those imgs myself, so there isn't anything I can do except point out the problem.

The reason the deb install is failing is because the firmware wasn't installed using apt, so you would need to remove the firmware by hand and then run the apt install.

#8 Re: ARM Builds » Beowulf 3.1.0 arm64 rpi4 image fails to boot on recent RPI4 » 2021-10-03 17:45:13

Why a 2GB model wouldn't boot I don't know, but as for the firmware error?

As for why it hit an error is due to the fact the firmware is already in place and apt doesn't like to replace files that it didn't install its self.

#9 Re: ARM Builds » Any Chimaera Rpi3/4 builds in the pipeline? » 2021-09-20 18:01:48

Assuming you have a Pi4 and an extra SDCARD you can produce them yourself without much effort.

Go here, download the pre-made Hirsute IMG and write it to said SD. From there follow the instructions on the README.

When creating an IMG you have 3 options, but only two will probably be of interest. That being make config and make admin, depending on which you choose, fill in the information of choice and create the userdata file.

You can speed up the process by pulling a pre-made kernel, using make helper.

So for example, if you wanted a quick rpi4 img... Create the userdata file and run: make 2711; make rootfs; make image

I'm not in the know of when there will be an official release, plus I'm still waiting to find out what the official sources.list file will look like.

#11 Re: ARM Builds » Is any work planned for devuan on the raspberry pi 4? » 2021-07-27 17:33:49

You are missing the point.

Device Tree files
There are various Device Tree blob files, which have the extension .dtb. These contain the hardware definitions of the various models of Raspberry Pi, and are used on boot to set up the kernel according to which Pi model is detected.

https://www.raspberrypi.org/documentati … _folder.md

The keyword here is: Detected.

The DTB file should not be defined, as the bootloader detects which version of the pi and loads it accordingly. You can however define it inside the /boot/config.txt file, but that is usually only done if it's not in its default location or someone is using a custom DTB. Either way, this is done during the normal boot process of the Pi and has nothing to do with u-boot ==> {boot.scr,extlinux,grub}

So the problem still becomes, how does each kernel know which DTB to load if it is not definable when using u-boot and only takes place after the fact? I believe you had mentioned before that it may be/is possible for grub to copy the correct dtb into place during the boot process and if so I assume this would be doable. But then we still have the problem of Kernel packaging, which at this time isn't suitable.

You are more than welcome to work out the logistical elements of this and contribute if you wanna make this happen. You can find me on irc @ libera: #devuan-arm or #arm-img-builder

#12 Re: ARM Builds » Is any work planned for devuan on the raspberry pi 4? » 2021-07-27 13:25:17

On other SoCs the device tree blob/binary needs to be loaded with the kernel in Extlinux and is defined by using

fdtdir /location

and

fdt /location/file

but on the PI this can't been done. Not sure why Grub would be able to handle this, but ok? I'll read over ur post further when I have some time.

#13 Re: ARM Builds » Is any work planned for devuan on the raspberry pi 4? » 2021-07-27 03:07:45

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.

#14 Re: ARM Builds » Is any work planned for devuan on the raspberry pi 4? » 2021-07-27 02:52:06

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?

#15 Re: ARM Builds » Is any work planned for devuan on the raspberry pi 4? » 2021-07-27 02:26:45

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 smile

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

#16 Re: ARM Builds » Is any work planned for devuan on the raspberry pi 4? » 2021-07-27 01:20:50

ehem wrote:
c0rnelius wrote:
ehem wrote:

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

#17 Re: ARM Builds » Is any work planned for devuan on the raspberry pi 4? » 2021-07-26 22:24:04

ehem wrote:
c0rnelius wrote:
ehem wrote:

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


c0rnelius wrote:

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.

#18 Re: ARM Builds » Is any work planned for devuan on the raspberry pi 4? » 2021-07-26 14:49:03

ehem wrote:

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.

#19 Re: ARM Builds » Is any work planned for devuan on the raspberry pi 4? » 2021-06-09 03:09:09

Aconcagua wrote:

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.

#20 Re: ARM Builds » Is any work planned for devuan on the raspberry pi 4? » 2021-06-08 07:56:36

Aconcagua wrote:

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.

#21 Re: ARM Builds » Is any work planned for devuan on the raspberry pi 4? » 2021-05-02 09:38:16

vladomiro wrote:
c0rnelius wrote:

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.

#22 Re: ARM Builds » Installer images for armel, armhf and ppc64 need testing » 2021-04-26 14:15:44

zen253230 wrote:

Sorry to ask the question !
but I tried at least twenty times to login on Rpi2 image with
login/password = pi/board
And I can swear it doesn't work after checking caps lock, input language,...!
any hint about where I could be wrong, please ?

Try this one: https://github.com/pyavitz/rpi-img-buil … -26.img.xz

The name of the img is misleading, as it will actually boot both the Raspberry Pi 2 and 3.
More information on the img and options can be found here: https://github.com/pyavitz/rpi-img-buil … tag/images

#23 Re: ARM Builds » Installer images for armel, armhf and ppc64 need testing » 2021-04-09 10:27:40

Florent wrote:

Hi everyone,

Flashed the folllowing image on an SD card and launched.
devuan_beowulf_3.1.0_arm64_rpi4.img
The install starts, but I get stucked after one minute with a login and password prompt:
"BCM2711 login"
Cannot find the solution in the README.txt file. Made a quick search on google but could not find anything.

Would you happen to know what I am missing or a step I might have overlooked?

Should be:
username: pi
password: board

As for sudo, it's setup so that you do not need to input a password to execute sudo.
You can find more information about the base image here: https://github.com/pyavitz/rpi-img-buil … tag/images

#24 Re: ARM Builds » Testimage: RaspberryPi 3+, Chimaera + TDE 14.1 » 2021-03-31 09:53:38

berni51 wrote:

@cOrnelius: Thanks, that worked perfect and the image now runs fine at an USB-3 port. On another raspi 4 I use one of your images and there I must not fix the quirk issue. Is this depending from the SSD type and manufacturer?

Yes, it seems to vary in USB-3 storage type and manufacture.

#25 Re: ARM Builds » Testimage: RaspberryPi 3+, Chimaera + TDE 14.1 » 2021-03-30 22:16:12

Sounds like a usb-storage.quirks issue. Try adding it to the cmdlline and see if it corrects the usb3 problem.

Board footer

Forum Software