I'm unfortunately not able to get any interactive output from the device when booting with the new kernel and the new tools - as mentioned, it either kernel panics or doesn't get past systemd's initial startup. Here's what I can get, though:
>From the booted device on the old kernel and initramfs: jarl@auth2:~$ uname -a Linux auth2.intra.algiz.nu 6.1.0-32-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.129-1 (2025-03-06) x86_64 GNU/Linux jarl@auth2:~$ sudo multipath -ll mpatha (36001405ed795e11f015f6aa128403b70) dm-0 LIO-ORG,IBLOCK size=20G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw `-+- policy='service-time 0' prio=50 status=active |- 0:0:0:0 sda 8:0 active ready running `- 0:0:1:0 sdb 8:16 active ready running jarl@auth2:~$ sudo dmsetup ls mpatha (254:0) mpatha-part1 (254:1) mpatha-part2 (254:2) mpatha-part3 (254:3) dmesg (failure): https://gist.github.com/Nihlus/5c88ddf3dbb1f5bb697857e234abd04a dmesg (success): https://gist.github.com/Nihlus/cf31edd5792977f59b5e31e8b59eeedb Going by the above, it looks like the newer ramdisk is missing some tools wanted by the startup scripts (pidof and grep). I poked around in the new scripts vs the old scripts, and they have changed a fair amount. If it's just this that's the issue, we should be good if the missing dependencies are just copied in as required. As for my setup, it's more or less like this: 1. A SAN with a local block device exposes iSCSI targets on two separate network paths 2. A hypervisor connects to this SAN over a local network, mapping two targets to two SCSI LUNs in qemu 3. The VM is configured to boot with UEFI, and uses multipath-tools-boot to map the two SCSI LUNs together into a single root device 4. The boot then continues from this mapped device Completely reproducing the bug locally would involve setting up a similar structure, but I suspect the issue would be visible during boot if any multipath device is available during boot. On Mon, 28 Apr 2025 at 00:03, Chris Hofstaedtler <z...@debian.org> wrote: > > * Chris Hofstaedtler <z...@debian.org> [250428 00:00]: > >* Jarl Gullberg <jarl.gullb...@gmail.com> [250427 23:12]: > >>If I boot from the old kernel and initramfs (6.1.0-32) which was created > >>on Debian 12, the system boots successfully. > >> > >>I can see in the logs that dm-0 is created, so the paths do appear to be > >>discovered and the device is appropriately created. It also does not > >>appear to be related to the kernel version, because if I regenerate the > >>initramfs using the old kernel (6.1.0-32) and the new Debian 13 system > >>with multipath-tools 0.11.1, the same issue occurs. > > > >Please compare the output of multipath -ll between the different > >versions / boots and post both here. > > Also useful might be: > > - a log of the actual errors > > - output of `dmsetup ls` for both variants > > - a description of your setup > > - how to reproduce it > > Chris >
