The officially official Devuan Forum!

You are not logged in.

#1 Re: Hardware & System Configuration » Installer *.iso problems - again ... » 2025-06-27 12:27:38

dzz

Here's the way forward (IMO) for rpi 3b+:

https://github.com/pftf/RPi3

No need for dd images or installer iso's. Ditch the uboot for grub.

3b+ here runs (headless) multiboot daedalus, excalibur and ceres, selectable from grub menu. All done at first with debootstrap (mmdebstrap is better IMO) and chroot, with the sdcard temporarily in another (amd64) devuan machine.

#2 Re: Off-topic » Debian removed multi-init support from the latest shipped grub » 2025-06-20 01:28:50

dzz

Thanks Prowler_Gr for exposing a clearly political move, during Trixie "hard freeze" mode (and yes it's in today's Excalibur updates).

Who do these people work for? The changelog doesn't tell us much unless you dig deeper:

grub2 (2.12-8) unstable; urgency=medium

  [ Mate Kukri ]
  * d/default/grub: Always get distributor string from `/etc/os-release`
  * Avoid adding extra GNU/Linux suffix to menu entries (Closes: #1076723)

-- Felix Zielcke <fzielcke@z-51.de>  Wed, 11 Jun 2025 17:42:34 +0200

Thanks also Prowler_Gr for your great work with AntiX and MX, much respect to both and many fond memories from the days of sidux where anticapitalista was a superb contributor. Although I never (yet) got to understand that unique live-boot process..

#3 Re: DIY » Does anyone here use Mintstick for making livUSB's? Need testers. » 2025-05-31 13:58:07

dzz

@Altoid, thanks for your input. I missed your linked post till now, what a battle!

All I can say about that without closer scrutiny: I have seen boot failure on USB drives which had grub previously installed (by design, accident , incorrectly or for another system) or had isohybrid previously dd'd.

What mostly worked here to sort that was, before any formatting, to zero out the mbr plus a bit more e.g.

dd if=/dev/zero of=/dev/sdX bs=512 count=4096

"few and minor modifications" in this case means simply copy the contents of /isolinux/ to /syslinux/ then copy /syslinux/isolinux.cfg to /syslinux/syslinux.cfg. On a properly prepared USB drive of course.

Apologies if this is somewhat off-topic but might help resolve *some* usb boot issues.

#4 Re: DIY » Does anyone here use Mintstick for making livUSB's? Need testers. » 2025-05-31 03:47:28

dzz

A UEFI machine will not boot if there is no UEFI partition it can find on the boot device.

True but.. The 'esp' and 'boot' flags don't need setting on the USB. UEFI will look in /EFI/ on the first partition, which must be FAT formatted.  Other files can  be on the same partition. Therefore an ISO built with UEFI support can be simply copied to a FAT formatted USB and will boot in UEFI mode.

Done like this a USB will also boot in mbr mode; with few and minor modifications, the 'boot' flag set and syslinux correctly installed.

It should boot in both cases exactly like the cdrom with the same splash and boot menu.

As for 32-bit UEFI machines, I heard of them but never seen one..

#5 Re: News & Announcements » Initramfs changes in Excalibur + refracta2usb » 2025-04-30 18:43:24

dzz

Thanks fsmithred, I tested the modified r2u OK in excalibur and daedalus host, on similar and different OS live images. In Trinity Desktop and in XFCE. Except for one new bug discovered:

Live mounts now go to /run/live/ not (/usr)/lib/live/mount .. so setup usb from running live system option is broken in excalibur. It's a simple fix around line 158 in the main script, I can post an updated experimental package to the same place at some point.

It looks like snapshot is OK with handling initramfs edits. But that method is unsuitable for r2u since we may be working on a live OS that's different from the running system.

Thanks also greenjeans for your testing and alternative live iso flavours.

EDIT: Updated and posted https://exegnulinux.net/files/refracta2usb/

#6 Re: News & Announcements » Initramfs changes in Excalibur + refracta2usb » 2025-04-29 15:47:56

dzz

That change calls mkinitramfs. It doesn't seem to work on an extracted directory. I tried it on an extracted excalibur initrd.img (while in daedalus). The output, when itself extracted, had files from my running system, not what was expected! And I see nothing in it's man page that mentions input from a directory.

EDIT: Of course, snapshot would only  be used on a running system (unless in a chroot, never tried that). Maybe then it does work for snaphot, or at least appears to. But there is still the multiple cpio  issue to consider..

#7 Re: News & Announcements » Initramfs changes in Excalibur + refracta2usb » 2025-04-29 15:11:19

dzz

unmkinitramfs version in excalibur doesn't extract as it was built (normally by update-initramfs).  Kernel modules (already compressed) are in an uncompressed "early" cpio, prepended to the compressed "main" cpio.. However  excalibur's unmkinitramfs extracts it to the "main".

The daedalus version does work as expected.

Unless I missed something, that's probably unsuitable for our purposes and maybe breaks something. I used a custom script, not wanting to rely on a deprecated version of what's probably not actually designed for our purposes..

#8 Re: News & Announcements » Initramfs changes in Excalibur + refracta2usb » 2025-04-29 11:29:08

dzz

Now posted here:

https://exegnulinux.net/files/refracta2usb/

No guarantees those changes are all good, till well tested in different scenarios. It's a work in progress with Excalibur in mind but should be compatible with at least daedalus.

The git repo is a great idea. For now, maybe take a diff against the extracted, original refracta2usb-2.4.3.deb to highlight the changes.

Thanks in advance anyone who wants to test but please be warned this stuff runs as root and is experimental so far.

And thanks especially fsmithred for this and the other superb refracta tools!

#9 News & Announcements » Initramfs changes in Excalibur + refracta2usb » 2025-04-28 19:31:03

dzz
Replies: 10

Refracta2usb remains, for me, the best tool to create a live usb. It is in need of some maintenance however.

Newer initrd layouts (excalibur>) place the kernel modules (now individually compressed) in a separate,
uncompressed cpio archive to which is concatenated to the main compressed cpio. Previously this was all lumped together. Also, if you have cpu microcode installed that will also be placed in separate, uncompressed and concatenated cpio archives. Plus live-boot (to be patched) is now version 20250225 for excalibur.

This breaks the patch_initrd function in refracta2usb which enables RW access to the partition containing the live-media. It's particular useful for a usb pen and various debugging activities.

Here's a list of those and some other changes I made here for refracta2usb. Not in any "official" capacity. Primarily for my own use but others may be interested. Starting with the most recent refracta2usb, newest changes first.

  * Update patch-initrd for live-boot 20250225 (Excalibur).
  * Support patch initramfs with multiple cpio's.

  * Fix chown failure on vfat.
  * Move PATH addition /opt/trinity/bin to main script.
  * Fix failure to delete loop device.
  * Fix failure to umount.
  * Tidy up some script comments.

  * Set USB mount options for user rw access.
  * Open file manager/editor instances as user not root.
  * Remove dialog references to root editor and file manager.
  * Include /opt/trinity/bin/kwrite as editor option.
  * Include final check and warning for USB umount failure.

  * Trinity Desktop will crash if kwrite is called from root:
  * Add extra launcher to suit TDE (shown only in TDE).
  * Add adwaita-icon-theme to recommends (cosmetic only).
  * Add --progress to all rsync commands in main script.
  * Fix root owned logfile in user's $HOME

  * Sort Lintian errors:
  * Add lintian override to suppress refracta2usb.desktop warning
  * Create basic man page (incomplete as yet).
  * Add "extended description" to debian/control.
  * Remove executable flag on some text files.

  * Remove deprecated "snapshot2usb" title references.
  * Add option to set debug mode in conf file
  * Package as "Debian Native" with full source tarball.

I haven't got round to proper testing yet in all scenarios but seems good so far.

If anyone is interested I can post later, somewhere, the result. Maybe someone else could test it and write back. Maybe the next official version can use some of this.

#10 Re: Other Issues » [SOLVED] Excalibur minimal-live isos need something. » 2025-04-11 00:35:10

dzz

Most recent iso, unpacked and chrooted:

mv /lib /zzzlib
ln -s usr/lib lib
apt install --reinstall linux-image-6.12.21-amd64
apt install --reinstall live-boot

Initramfs was auto generated and manually copied to /live. Rebuilt iso, booted in qemu, seems OK!

Hazy memory of a ceres bootstrap a while ago, had to include usrmerge from the start. But I use mmdebstrap. Best check your initial bootstrap before adding to it.

Missing package, makes navigating in cli-only much easier: tree

btw: desktop-base 5.9 tested OK here (so far). Don't wait, get it from ceres.

#11 Re: Other Issues » [SOLVED] Excalibur minimal-live isos need something. » 2025-04-10 17:40:20

dzz

I don't mind testing these, time permitting, if it helps.  I have custom scripts ready to unpack, inspect, chroot and rebuild iso's. Also, they help me as test beds for some things I'm working on.

Neither of the images you posted have symlinks lib > usr/lib .. Others (bin, sbin, lib64) do. Therefore usrmerge was not done right. That explains the live-* errors and probably many others not yet noticed!

Newer live-boot I know installs to merged usr locations. Probably live-config also. I see there is a devuan live-config package but I not inspected that yet.

There is no actual /boot/initrd.img* on either iso, probably for the same reason.

#12 Re: Other Issues » Preliminary excalibur desktop-live isos need testing » 2025-04-07 14:48:57

dzz

One issue: Can't set a different background in settings dialog from anywhere except /usr/share/images/desktop-base/ .. Most of us will want a custom background after install.

If I go to init 1, delete xfce4-desktop.xml from /etc/xdg/ and /home/devuan/ then back to init 2 then only what's in /usr/share/backgrounds/xfce/ is then available. So the xml in /etc/xdg/ must be doing something. No idea yet why other locations don't work.

BTW what's with the monster initrd.img?

#13 Re: Other Issues » Preliminary excalibur desktop-live isos need testing » 2025-04-07 12:47:53

dzz

This worked here (qemu and usb), default backgroung is the one configured by /etc/alternatives:

1) Extract the iso

2) chroot the filesystem

3):

dpkg-divert --divert /usr/share/backgrounds/xfce/xfce-x.svg.dist --rename /usr/share/backgrounds/xfce/xfce-x.svg

ln -s /etc/alternatives/desktop-background /usr/share/backgrounds/xfce/xfce-x.svg

4) Exit chroot, rebuild the iso, boot it.

devuan@devuan:~$ dpkg -S /usr/share/backgrounds/xfce/xfce-x.svg
local diversion from: /usr/share/backgrounds/xfce/xfce-x.svg
local diversion to: /usr/share/backgrounds/xfce/xfce-x.svg.dist
xfdesktop4-data: /usr/share/backgrounds/xfce/xfce-x.svg

Maybe something similar could  go in preinst/prerm of desktop-base.

devuan@devuan:~$ ls -la /usr/share/backgrounds/xfce
total 2388
drwxr-xr-x 2 root root     292 Apr  7 11:33 .
drwxr-xr-x 3 root root      27 Apr  2 16:10 ..
-rw-r--r-- 1 root root  197011 Mar  3 01:34 xfce-blue.jpg
-rw-r--r-- 1 root root   28575 Mar  3 01:34 xfce-cp-dark.svg
-rw-r--r-- 1 root root   16972 Mar  3 01:34 xfce-flower.svg
-rw-r--r-- 1 root root  160740 Mar  3 01:34 xfce-leaves.svg
-rw-r--r-- 1 root root 1428420 Mar  3 01:34 xfce-light.svg
-rw-r--r-- 1 root root  263520 Mar  3 01:34 xfce-mouserace.svg
-rw-r--r-- 1 root root  322121 Mar  3 01:34 xfce-shapes.svg
-rw-r--r-- 1 root root    4904 Mar  3 01:34 xfce-stripes.svg
-rw-r--r-- 1 root root    6791 Mar  3 01:34 xfce-teal.svg
-rw-r--r-- 1 root root    4584 Mar  3 01:34 xfce-verticals.svg
lrwxrwxrwx 1 root root      36 Apr  7 11:33 xfce-x.svg -> /etc/alternatives/desktop-background
-rw-r--r-- 1 root root    9298 Mar  3 01:34 xfce-x.svg.dist
devuan@devuan:~$ 

#14 Re: Other Issues » Preliminary excalibur desktop-live isos need testing » 2025-04-06 23:12:49

dzz

Unfortunately the xml file edits I made don't stick for a rebuilt iso. This affects not only Devuan:

https://gitlab.xfce.org/xfce/xfdesktop/-/issues/364

Seems xml files in /etc/xdg no longer work to set default backdrop since 4.19. Default desktop is set to /usr/share/backgrounds/xfce/xfce-x.svg unless compiled differently.

#15 Re: Other Issues » Preliminary excalibur desktop-live isos need testing » 2025-04-05 20:07:17

dzz

The cursed rat..

Inserting between line 36 and 37 in /etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-desktop.xml-devuan-sapphire:

  <property name="monitorLVDS-1" type="empty">
        <property name="workspace0" type="empty">
          <property name="last-image" type="string" value="/usr/share/images/desktop-base/desktop-background"/>
        </property>

Gives the desired result in a laptop usb boot. For a qemu session it needs to be "monitorVirtual-1". Maybe two entries will work for either. I don't know about other scenarios but will try on a tower case later.

#16 Re: Other Issues » Preliminary excalibur desktop-live isos need testing » 2025-03-25 13:38:38

dzz

Can you get into a tty from the live-session grub screen and edit with nano?

One way is to add "1" (no quotes) to the cmdline (boot menu). Enter root password "toor" then you can run nano. That done, enter "init 2" to continue normal boot.

Confirmed here, after taking out the line for plugin 7 (EDIT: line 22) in /etc/xdg/xfce4/panel/default.xml-devuan-sapphire the error is gone.

EDIT (more):

dpkg -S /etc/xdg/xfce4/panel/default.xml-devuan-sapphire
desktop-base: /etc/xdg/xfce4/panel/default.xml-devuan-sapphire

There's the cause! Also, the offending plugin is undefined in default.xml-deepsea ..

I can't see what default.xml.dpkg-new is there for, nothing seems to own it.

#17 Re: ARM Builds » refractasnapshot-base syslinux arm64 » 2025-03-16 16:19:21

dzz

I think the OP's original question is mostly answered, i.e. refractasnapshot can work on arm64 with some very minor modification. At least for efi-capable hardware. I don't agree that isolinux/syslinux is deprecated (yet), it remains a boot iso standard for bios/mbr hardware. Most such iso's also include grub for efi including refractasnapshot. But I have still more to add, re Refracta tools + arm64

We already have tested that another grub can boot the iso image via "loopback". Now I see that, although this machine seems unable to boot a dd'd isohybrid (pukes on loading the kernel), it can boot a usb with the snapshot live iso files simply copied.

Now I discover that refractainstaller can work on arm64 without modification! A live snapshot here was installed to a dedicated partition (not on the boot drive) and can be booted with, so far, no apparent problems. I chose to not do grub-install, I have grub manually configured elsewhere.

#18 Re: ARM Builds » refractasnapshot-base syslinux arm64 » 2025-03-07 19:33:25

dzz

(Apologies, off-topic): My previous script ssh edits were unnecessary. Whatever is in the script's ssh function (hence the final iso) gets changed by live-config's openssh-server on boot. Only way round that is, disable it (and deal with the security risk yourself) or make a custom live-config script to run after it. Or use a "live-hook" script which could go in /live.

I disabled it on the cmdline. In fact I disabled live-config altogether, for this build, none of it is needed.

Or chmod -x it, dpkg-divert it or delete it.. but.. I noticed in refractasnapshot-base_10.4.2 line 824>:

# Enable or disable password login through ssh for users (not root)
# Remove obsolete live-config file 
if [[ -e "$work_dir"/myfs/lib/live/config/1161-openssh-server ]] ; then
	rm -f "$work_dir"/myfs/lib/live/config/1161-openssh-server
fi

That won't work, it's actually "1160-openssh-server" in Daedalus>!

On topic, I added near the top of the mkefi function a test for arm64

# Detect if arch is arm64
arch=$(dpkg --print-architecture)
if [ "$arch" = "amd64" ]; then

	efi_files="x86_64-efi"
	efi_binary="bootx64.efi"

elif [ "$arch" = "arm64" ]; then
	efi_files="arm64-efi"
	efi_binary="bootaa64.efi"
fi

Then replaced further down all instances of x86_64-efi with ${efi_files} and bootx64.efi with ${efi_binary}.

It works and produces arm64-efi files and bootaa64.efi in the iso.
Not that it's of much use if your hardware can't boot an iso directly..

#19 Re: ARM Builds » refractasnapshot-base syslinux arm64 » 2025-03-06 19:01:52

dzz

Refractasnapshot (sort of) working here on arm64, a Raspberry Pi 3b+.

I recompiled refractasnapshot from source tarball. Far as I can see it doesn't need dependency on syslinux. Most (all?) of the syslinux files to be copied over are actually part of syslinux-common, that's for all arches. For Daedalus at least. Kept isolinux (not arch-specific) dependency.

I also disabled in the script, the part where ssh is modified, by making it a function which doesn't actually run. Not sure if that was actually necessary but first try, I couldn't ssh it and this machine is intended to be headless.

Only other changes were refractasnapshot.conf and snapshot_exclude.list to suit.

This pi has uefi emulation boot (not uboot) therefore I can use grub to boot the snapshot iso. And boot it does, given the right cmdline (note "nocomponents" to disable live-config). It networks automatically and accepts ssh.

Snip from /etc/grub.d/40_custom:

menuentry "Refractasnapshot ARM ISO boot" {
  set isofile="(hd0,2)/home/snapshot/snapshot.iso"
  loopback loop $isofile
  linux    (loop)/live/vmlinuz-6.13.0-rc7 boot=live findiso=/home/snapshot/snapshot.iso nocomponents 
  initrd   (loop)/live/initrd.img-6.13.0-rc7

}

How useful this all is is another matter, the machine itself first needs a working grub (maybe not extlinux) to boot an actual iso. The other snapshot files, outside /live, are probably redundant in this scenario. Anyway it's a good backup and potentially installable.

#20 Re: Hardware & System Configuration » Bluetooth support on laptop » 2025-03-05 22:21:29

dzz

Blueman installs here without pulseaudio. Makes life a lot simpler to connect bluetooth devices.  Do you have dbus-x11? There is a nasty alt dependency, default-dbus-session-bus .. failing that you could apt-pin pulseaudio to -1 and see what happens.

:~$ dpkg -l|egrep "pulse|blueman"
ii  apulse:amd64                           0.1.13-2                                amd64        PulseAudio emulation for ALSA
ii  blueman                                2.3.5-2+b1                              amd64        Graphical bluetooth manager
ii  libpulse-mainloop-glib0:amd64          16.1+dfsg1-2+b1                         amd64        PulseAudio client libraries (glib support)
ii  libpulse0:amd64                        16.1+dfsg1-2+b1                         amd64        PulseAudio client libraries
ii  pipewire-pulse                         0.3.65-3+deb12u1                        amd64        PipeWire PulseAudio daemon

Another laptop here, working bluetooth sound, uses bluez-alsa. It comes with no sysvinit script but one is here: https://github.com/joe-skb7/bluealsa-sysvinit ..

#21 Hardware & System Configuration » Raspberry Pi Devuan, multiboot, uefi, grub, no uboot, no image dd » 2025-02-27 19:07:54

dzz
Replies: 0

Some interesting experiments here with a raspberry pi 3b+ I was given. Some of this may well apply to other models. It's a different way from the usual dd of someone else's image, or compilation>dd from e.g. rpi-image-builder https://github.com/pyavitz/rpi-img-builder (thanks c0rnelius).

Early days so far and I didn't document everything very well.

The sd card was partitioned, using a Devuan system, with a small fat32 "boot" partition. To this was copied (not dd'd) the "virtual" uefi from here https://github.com/pftf/RPi3 .. Other files needed were EFI/boot/bootaa64.efi (simple to make and the bootloader found it automatically) and boot/grub with the usual (arm64) layout and a custom grub.cfg ..

The rest was formatted ext2 containing Devuan Daedalus loaded via mmdebstrap (superior IMO to debootstrap), then built up in chroot, complete with standard kernel.

On boot the grub menu appears and behaves normally. Everything seems to work including wireless. Bluetooth sound was more challenging, now working with alsa only + bluez-alsa. No xserver for now.

Interestingly I can chain the grub to another grub on a usb pen which (sdcard) grub always detects as /dev/sda. Other distributions are installed there, including another Daedalus and Ceres. Alternative kernels are installed there including a self-compiled mainline 6.13 (used default arm64 defconfig) and one compiled as a deb package using rpi-image-builder. Apparently 6.13 has improved pi support but they all work. A normal update-grub enables them all in the secondary grub menu.

Another revelation: I can boot a custom live image from iso. I never saw that done for arm64.

Anyone else here tried a pi setup like that? Multiboot with uefi, grub, no uboot, no image dd. Pure Devuan except in this case some maybe unnecessary firmware. Maybe you found something I missed or have better or different ideas. If something similar was posted here before either I never found it or it's way outdated.

#22 Re: Other Issues » [SOLVED] linux-image not updated » 2025-02-02 21:05:29

dzz

Then maybe some answers (after you checked for no held packages) from:

apt update && apt install linux-image-amd64

#23 Re: Other Issues » Is it possible to install a package permanently on Live ? » 2025-01-19 18:13:26

dzz

@SpongeBOB: Why not try msdos partition table?

R2u uses syslinux/isolinux,  it's more complex to get that working for gpt (and you don't need gpt)..

#24 Re: Other Issues » Is it possible to install a package permanently on Live ? » 2025-01-19 01:10:00

dzz

Is it possible to install a package / program permanently on a Live version ?

If the package is not so large or complex and doesn't call update-intramfs, you can use live-config's "live-hook" mechanism.

You can write a simple live-hook script (which could call e.g. dpkg -i /path/to/package or even another set of subscripts) and place it on any present media/disk, inside or outside the iso. It's automatically activated via the cmdline.

man live-config

is a learning curve but very well documented.

The package would of course need all it's deps sorted first. Script those in order and it should work.

Note the need to use wget-style absolute paths (file:///whatever), that's the awkward one.

Works here..

EDIT: If you use full persistence also, maybe you can then disable your hook script, since it will be already merged into the live system.. ?

#25 Re: Packaging for Devuan » yt-dlp is very outdated » 2024-10-18 19:05:12

dzz

If you install yt-dlp as Ron suggests, the update option is already built-in. As root, simply:

yt-dlp -U

If you installed it from the repos,  that option is disabled. An error will show and it can only list the installed and available versions.

Board footer

Forum Software