# NVMe Base Duo, 6.18.29 & Trixie 13.5 **URL:** \ **Category:** Support\ **Created:** [May 17, 2026, 2:17pm UTC](https://forums.pimoroni.com/t/nvme-base-duo-6-18-29-trixie-13-5/28866 "2026-05-17T14:17:43Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Adrian\_Day](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.pimoroni.com/adrian_day/32/172_2.png) [@Adrian\_Day](https://forums.pimoroni.com/u/Adrian_Day)\ **Post date:** [May 17, 2026, 2:17pm UTC](https://forums.pimoroni.com/t/nvme-base-duo-6-18-29-trixie-13-5/28866/1 "2026-05-17T14:17:43Z")
I’ve been using the Base Duo sucessfully for about a year without any problems. The boot and root partitions are on one drive and a LVM volume spans both drives. Last week I upgraded the kernel to 6.18.29 and rebooted. The boot sequence failed when attempting to mount the LVM volume. The update had pulled the new kernel and a new bootloader (rpi-eeprom) but I did not update the bootloader prior to restarting the system. Recovery involved rebooting via SD card and updating the bootloader. This morning I updated the system to the latest release (13.5). This automatically updated the bootloader. The system hung again on reboot. I have since reverted to the 6.12.75 kernel. In the absence of a fix, I would strongly advise anyone to avoid updating to 6.18.29 until the root cause is identified and a fix made available. I have raised a ticket on the raspberrypi/linux devs GitHub. ( [Kernel 6.18.29 - NVMe boot failure · Issue #7367 · raspberrypi/linux · GitHub](https://github.com/raspberrypi/linux/issues/7367) ) ---
**Author:** ![bablokb](https://avatars.discourse-cdn.com/v4/letter/b/ee59a6/32.png) [@bablokb](https://forums.pimoroni.com/u/bablokb)\ **Post date:** [May 18, 2026, 6:28am UTC](https://forums.pimoroni.com/t/nvme-base-duo-6-18-29-trixie-13-5/28866/2 "2026-05-18T06:28:23Z")
The bootloader is one of the weakest components during boot IMHO. This is the reason I always keep the boot-partition (FAT) on the SD, while booting the system from the NVMe. You have to edit the `cmdline.txt` for this to work. It seems like a waste to have an additional SD-card, but I also keep a backup of the system-partition there. ---
**Author:** ![Adrian\_Day](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.pimoroni.com/adrian_day/32/172_2.png) [@Adrian\_Day](https://forums.pimoroni.com/u/Adrian_Day)\ **Post date:** [May 18, 2026, 12:30pm UTC](https://forums.pimoroni.com/t/nvme-base-duo-6-18-29-trixie-13-5/28866/3 "2026-05-18T12:30:21Z")
It’s beginning to look more like a problem relating to 6.18 and lvm I disabled the LVM volume in /etc/fstab. Added ‘nvme.max\_host\_mem\_size=0’ to config.txt, and booted into the 6.18 kernel from the NVMe drive. Success. Unfortunately, there’s no trace of the LVM volume when you run ‘lsblk -f’ It shows up when you run… sudo pvs sudo vgs sudo lvs sudo lvchange -ay I sense a fix will be available soon. ---
**Author:** ![bablokb](https://avatars.discourse-cdn.com/v4/letter/b/ee59a6/32.png) [@bablokb](https://forums.pimoroni.com/u/bablokb)\ **Post date:** [May 18, 2026, 1:17pm UTC](https://forums.pimoroni.com/t/nvme-base-duo-6-18-29-trixie-13-5/28866/4 "2026-05-18T13:17:18Z")
Have you checked the device-mapper rules? Maybe something was messed up there. Or the lvm.conf has changed (unlikely, updates don’t do that). Since they show up when you manually execute various commands, there seems to be a problem with autoactivation which is driven by udev+device-mapper. ---
**Author:** ![Adrian\_Day](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.pimoroni.com/adrian_day/32/172_2.png) [@Adrian\_Day](https://forums.pimoroni.com/u/Adrian_Day)\ **Post date:** [May 18, 2026, 2:31pm UTC](https://forums.pimoroni.com/t/nvme-base-duo-6-18-29-trixie-13-5/28866/6 "2026-05-18T14:31:03Z")
Regenerating the initramfs having first ensured the lvm2-monitor.service was up and runnning has fixed everything. My real concern is that things went pear-shaped when an OS update automatically generated a new initramfs. ---
**Author:** ![Adrian\_Day](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.pimoroni.com/adrian_day/32/172_2.png) [@Adrian\_Day](https://forums.pimoroni.com/u/Adrian_Day)\ **Post date:** [June 7, 2026, 2:10pm UTC](https://forums.pimoroni.com/t/nvme-base-duo-6-18-29-trixie-13-5/28866/7 "2026-06-07T14:10:52Z")
The issue I was experiencing turned out not to be related to NVMe. When I upgraded to the 6.18 kernel from 6.12, lvm support was not automatically included when running ‘update-initramfs’. As a consequence, the boot hung when the system tried to mount the LVM volume. The fix is to include ‘dm\_mod’ in ‘/etc/initramfs-tools/modules’ prior to creating the initial ram filesystem (or upgrading to the 6.18 kernel branch). ---
**Author:** ![Adrian\_Day](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.pimoroni.com/adrian_day/32/172_2.png) [@Adrian\_Day](https://forums.pimoroni.com/u/Adrian_Day)\ **Post date:** [June 10, 2026, 11:46am UTC](https://forums.pimoroni.com/t/nvme-base-duo-6-18-29-trixie-13-5/28866/8 "2026-06-10T11:46:28Z")
Adding ‘dm\_mod’ was a workaround. This has now been properly fixed in the most recent initramfs-tools package.