The officially official Devuan Forum!

tyder

Member

From: Oslo, Norway

Registered: 2016-12-19

Posts: 37  

Needs for better modularization of installs

Running and maintaining any Linux distro should be as independent on filesystems and organization as possible. To me it seems Debian has moved in the opposite direction. An install may work with an overlay file system for years, through several remakings of a read-only, compressed base, but the current Trixie release proves to be seriously challenged with respect to understanding file systems.  Booting and kernel/initramfs administration is much affected.
This influences a lot of functionality, and is typically something that should be easy to unselect when not needed. But they don't want to let you escape in any easy way.
So, I encounter crashes in post-install scripts, often based on this error condition:

/usr/sbin/grub-probe: error: failed to get canonical path of `overlay'

Patching them with 'exit 0' kind of breakpoints allows me to get my job done, and this has no relevance for my daily use whatsoever.
But it shouldn't be like that.
Developers of the 'Universal operating system' basic components should follow the most basic Unix principle: Do one thing, and do it well.
In this case, it is about providing a solution for booting and kernel updating. That is necessary, but it is not done well. And forcing the  solution to booting is scope creep. That hardware/firmware is an erratically moving target makes the approach all the worse.
Thus, the current setup that is forced upon us IMO breaks both the basic One Thing-principle, and the requirement to do it well. 

I might have been more positive if the solution had proven to be strictly necessary to get Debian-based systems up&running. But it isn't. Me writing this is a simple counterexample. And one counterexample is enough.

This should be modularized, and instead of discussing this over and over with the upstream developers, we should try to produce a proof of concept.
I don't think we have to channel Erich Boleyn, but it might help ;-)

Last edited by tyder (2026-03-09 16:40:33)

Altoid

Member

Registered: 2017-05-07

Posts: 1,984  

Re: Needs for better modularization of installs

Hello:

... the current setup that is forced upon us IMO breaks both the basic One Thing-principle

The basic Unix principle: Do one thing, and do it well has been broken for many years now.

... we should try to produce a proof of concept.

Hmm....

If we* means the already overworked / short staffed group of people working as well as they can to keep Devuan systemd free, you may want to stop and think a bit.

The die is cast: unless an important group of distributions turn their back on systemd (and I choose systemd as the prime example of the enshittification of the Linux ecosystem) I do not think anything is happening.

* I was going to attempt a humorous approach to this with a "whatyoumin we white man?" quip but I decided against it.
Political correction and all.

Best,

A.

Last edited by Altoid (Yesterday 07:26:59)

dzz

Member

From: Exmouth, South West England

Registered: 2016-12-01

Posts: 112  

Re: Needs for better modularization of installs

/usr/sbin/grub-probe: error: failed to get canonical path of `overlay'

Unless you run systemd: that happens if you upgrade a kernel running live persistence in a VM (at least some circumstances if not all).

Those errors are caused by Debian maintainer scripts /etc/kernel/postrm.d/zz-update-grub and /etc/kernel/postinst.d/zz-update-grub:

if type systemd-detect-virt >/dev/null 2>&1 &&
   systemd-detect-virt --quiet --container; then
	exit 0
fi

That supports systemd only! If you add after that chunk (both files):

if (grep -q QEMU /proc/cpuid); then exit 0; fi

it will work, update-grub won't run. You don't want it to in a persistence VM, grub will error out causing dpkg errors in turn.

Generating the initramfs is another issue, only way I found was to call update-initramfs.orig.initramfs-tools manually. There is probably something wrong in /bin/live-update-initramfs and/or /etc/kernel/post*.d/initramfs-tools ..

Success here in the end (qemu, persistence, devuan 6.1.1 iso with vmlinuz-6.12.57+deb13-amd64):

:~$ uname -r
6.12.73+deb13-amd64

Last edited by dzz (Yesterday 19:39:13)

fsmithred

Administrator

Registered: 2016-11-25

Posts: 2,865  

Re: Needs for better modularization of installs

only way I found was to call update-initramfs.orig.initramfs-tools manually

Only if the live-tools package is installed. Without that, update-initramfs does not get diverted.

dzz

Member

From: Exmouth, South West England

Registered: 2016-12-01

Posts: 112  

Re: Needs for better modularization of installs

Yes, in theory. But at least, it can't work if fromiso/findiso was used. Maybe it does using the extracted squashfs, yet to test that.

root@devuan:/# cat /proc/mounts|grep medium
/dev/loop0 /run/live/medium iso9660 ++++++++++++++++

(snip from /bin/live-update-initramfs):

if grep -qs "\/run\/live\/medium" /proc/mounts
	then
		# live system with live media mounted as /run/live/medium
		_DEVICE="$(awk '/\/run\/live\/medium/ { print $1 }' /proc/mounts)"

		mount -o remount,rw ${_DEVICE} > /dev/null 2>&1 || true

		if touch /run/live/medium/.test > /dev/null 2>&1
		then
			_READ_WRITE="true"

Script exits on failure to remount /run/live/medium/ .. you can't mount iso9660 RW. And you don't need to because the new initrd should be written to the overlay!

root@devuan:/# update-initramfs -u
I: update-initramfs is disabled (live system is running on read-only media

)

Last edited by dzz (Yesterday 21:19:43)

dzz

Member

From: Exmouth, South West England

Registered: 2016-12-01

Posts: 112  

Re: Needs for better modularization of installs

Update:

root@devuan:/home/devuan# cat /proc/cmdline
BOOT_IMAGE=(hd0,1)/devuan/live/vmlinuz boot=live live-media-path=/devuan/live username=devuan nottyautologin apparmor=0 keyboard-layouts=gb noeject mountmode=rw persistence persistence-path=/devuan-pers persistence-label=pers3 debug showmounts

root@devuan:/home/devuan# LATEST_KERNEL=$(ls /boot|sort -r|grep -m 1 vmlinuz|sed 's/vmlinuz-//')
root@devuan:/home/devuan# echo $LATEST_KERNEL
6.12.73+deb13-amd64

root@devuan:/home/devuan# update-initramfs -d -k $LATEST_KERNEL
update-initramfs: Deleting /boot/initrd.img-6.12.73+deb13-amd64
cp: cannot create regular file '/run/live/medium/live/vmlinuz1.new': No such file or directory

root@devuan:/home/devuan# update-initramfs -c -k  $LATEST_KERNEL
update-initramfs: Generating /boot/initrd.img-6.12.73+deb13-amd64
cryptsetup: ERROR: Couldn't resolve device overlay
cryptsetup: WARNING: Couldn't determine root device
W: Couldn't identify type of root file system 'overlay' for fsck hook
live-boot: core filesystems dm-verity devices utils udev blockdev dns.
cp: cannot create regular file '/run/live/medium/live/vmlinuz1.new': No such file or directory

So it does work using extracted squashfs. The errors seem just warnings. It's there in the overlay. The overlay can be mounted in main system and new initrd copied to where the the relevant bootloader can find it.

But it doesn't work using fromiso/findiso (my preferred use case) without user intervention as noted. I don't see that mentioned in live-boot's manual.