End of tether... to boot or not to boot?

[thomasl]

I tested my trusty MX23 frugal install on an old MS Surface Pro 4 and almost everything works (great ). The touch screen (always a touchy issue) doesn't but that was expected and after installing a patched kernel for Surface devices and creating a new system it did work. I basically created an encrypted live USB with live-usb-maker, booted this and it worked. So... all set!

Not so fast. I next copied the three relevant files (vmlinuz, initrd.gz and linuxfs) to the existing MX23 frugal install (with the old kernel) on the SP4. vmlinuz and initrd.gz sit on the EFI partition in /MX23 (plus the "encrypted" file with the UUID of the encrypted partition). The new linuxfs goes into /MX23 on the encrypted partition. I double-checked everything and re-booted. Or rather, didn't as the boot broke off with the message that "MX23/encrypted" can't be found on any searched device. Among the searched devices is /dev/nvme0n1p1, the one with all EFI files and with vmlinuz, initrd.gz and encrypted in /MX23.

So I rebooted with "bp=3" and a quick "cat /dev/nvme0n1p" showed that this exists and can be read. I normally use rEFInd but also tried grub2, won't boot either. So, I am stumped.

A quick recap. The original MX23 install on the SP4 SSD with the old kernel was encrypted, booted OK from the SSD and worked but w/o touch. The encrypted USB stick (with the new kernel) boots perfectly OK and also works, including the touch screen. The exact same three files when copied from the USB to the exact same locations on the SSD do not boot because MX23/encrypted can't be found (I triple checked that the files are indeed the same, including md5sum).

I have no idea whatever I could try next.

The QSI is the booting old version.

Code: Select all

Snapshot created on: 20240213_1535
System:
  Kernel: 6.1.0-18-amd64 [6.1.76-1] arch: x86_64 bits: 64 compiler: gcc v: 12.2.0 parameters: quiet checkfs
    loglevel=0 from=hd bdir=MX23 hostname=msp4mx persist=root!,home! initrd=MX23\initrd.gz
  Desktop: Xfce v: 4.18.1 tk: Gtk v: 3.24.36 info: xfce4-panel wm: xfwm v: 4.18.0 vt: 7
    dm: LightDM v: 1.32.0 Distro: MX-23.3_x64 Libretto February 16  2024 base: Debian GNU/Linux 12
    (bookworm)
Machine:
  Type: Laptop System: Microsoft product: Surface Pro 4
    v: 124000000000000000000000D:0B:08F:1C:03P:38 serial: <superuser required> Chassis: type: 9
    serial: <superuser required>
  Mobo: Microsoft model: Surface Pro 4 serial: <superuser required> UEFI: Microsoft
    v: 109.3748.768 date: 05.04.2021
Battery:
  ID-1: BAT1 charge: 23.3 Wh (65.6%) condition: 35.5/38.2 Wh (93.1%) power: 18.9 W volts: 7.4
    min: 7.5 model: DYN X910528 type: Li-ion serial: <filter> status: discharging cycles: 61
CPU:
  Info: model: Intel Core i5-6300U bits: 64 type: MT MCP arch: Skylake gen: core 6 level: v3
    note: check built: 2015 process: Intel 14nm family: 6 model-id: 0x4E (78) stepping: 3
    microcode: 0xEA
  Topology: cpus: 1x cores: 2 tpc: 2 threads: 4 smt: enabled cache: L1: 128 KiB
    desc: d-2x32 KiB; i-2x32 KiB L2: 512 KiB desc: 2x256 KiB L3: 3 MiB desc: 1x3 MiB
  Speed (MHz): avg: 725 high: 777 min/max: 400/3000 scaling: driver: intel_pstate
    governor: powersave cores: 1: 725 2: 700 3: 777 4: 700 bogomips: 19999
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: gather_data_sampling status: Vulnerable: No microcode
  Type: itlb_multihit status: KVM: VMX disabled
  Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
  Type: mds mitigation: Clear CPU buffers; SMT vulnerable
  Type: meltdown mitigation: PTI
  Type: mmio_stale_data mitigation: Clear CPU buffers; SMT vulnerable
  Type: retbleed mitigation: IBRS
  Type: spec_rstack_overflow status: Not affected
  Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: IBRS, IBPB: conditional, STIBP: conditional, RSB filling,
    PBRSB-eIBRS: Not affected
  Type: srbds mitigation: Microcode
  Type: tsx_async_abort mitigation: TSX disabled
Graphics:
  Device-1: Intel Skylake GT2 [HD Graphics 520] vendor: Microsoft driver: i915 v: kernel
    arch: Gen-9 process: Intel 14n built: 2015-16 ports: active: eDP-1 empty: DP-1, DP-2, HDMI-A-1,
    HDMI-A-2 bus-ID: 00:02.0 chip-ID: 8086:1916 class-ID: 0300
  Display: x11 server: X.Org v: 1.21.1.7 compositor: xfwm v: 4.18.0 driver: X:
    loaded: modesetting unloaded: fbdev,vesa dri: iris gpu: i915 display-ID: :0.0 screens: 1
  Screen-1: 0 s-res: 1710x1140 s-dpi: 96 s-size: 451x301mm (17.76x11.85") s-diag: 542mm (21.35")
  Monitor-1: eDP-1 model: Samsung 0x3853 built: 2015 res: 1710x1140 hz: 60 dpi: 167 gamma: 1.2
    size: 260x173mm (10.24x6.81") diag: 312mm (12.3") ratio: 3:2 modes: 2736x1824
  API: OpenGL v: 4.6 Mesa 22.3.6 renderer: Mesa Intel HD Graphics 520 (SKL GT2)
    direct-render: Yes
Audio:
  Device-1: Intel Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Imaging Unit driver: N/A
    bus-ID: 00:05.0 chip-ID: 8086:1919 class-ID: 0480
  Device-2: Intel CSI-2 Host driver: N/A bus-ID: 00:14.3 chip-ID: 8086:9d32 class-ID: 0480
  Device-3: Intel Sunrise Point-LP HD Audio driver: snd_hda_intel v: kernel
    alternate: snd_soc_skl,snd_sof_pci_intel_skl bus-ID: 00:1f.3 chip-ID: 8086:9d70 class-ID: 0403
  API: ALSA v: k6.1.0-18-amd64 status: kernel-api tools: alsactl,alsamixer,amixer
Network:
  Device-1: Marvell 88W8897 [AVASTAR] 802.11ac Wireless driver: mwifiex_pcie v: 1.0 pcie: gen: 1
    speed: 2.5 GT/s lanes: 1 bus-ID: 02:00.0 chip-ID: 11ab:2b38 class-ID: 0200
  IF: mlan0 state: up mac: <filter>
Bluetooth:
  Device-1: Marvell Bluetooth and Wireless LAN Composite driver: btusb v: 0.8 type: USB rev: 2.0
    speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 1-5:5 chip-ID: 1286:204c class-ID: e001
    serial: <filter>
  Report: hciconfig ID: hci0 rfk-id: 1 state: down bt-service: N/A rfk-block: hardware: no
    software: no address: <filter>
  Info: acl-mtu: 1021:7 sco-mtu: 240:3 link-policy: rswitch hold sniff
    link-mode: peripheral accept
Drives:
  Local Storage: total: 357.54 GiB used: 8.55 GiB (2.4%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Samsung model: MZFLV128HCGR-000MV size: 119.24 GiB
    block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s lanes: 4 tech: SSD serial: <filter>
    fw-rev: BXV75M0Q temp: 34.9 C scheme: GPT
  ID-2: /dev/sda maj-min: 8:0 vendor: Generic model: USB3.0 CRW -SD size: 238.3 GiB block-size:
    physical: 512 B logical: 512 B type: USB rev: 3.0 spd: 5 Gb/s lanes: 1 mode: 3.2 gen-1x1
    tech: N/A serial: <filter> fw-rev: 1.00 scheme: GPT
  SMART Message: Unknown USB bridge. Flash drive/Unsupported enclosure?
Partition:
  Message: No partition data found.
Swap:
  Alert: No swap data was found.
Sensors:
  System Temperatures: cpu: 41.0 C pch: 37.5 C mobo: N/A
  Fan Speeds (RPM): N/A
Repos:
  Packages: pm: dpkg pkgs: 1885 libs: 961 tools: apt,apt-get,aptitude pm: rpm pkgs: 0 pm: flatpak
    pkgs: 0
  No active apt repos in: /etc/apt/sources.list
  Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list
    1: deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/debian.list
    1: deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
    2: deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/mx.list
    1: deb http://mxrepo.com/mx/repo/ bookworm main non-free
  Active apt repos in: /etc/apt/sources.list.d/vivaldi.list
    1: deb [arch=amd64] https://repo.vivaldi.com/stable/deb/ stable main
Info:
  Processes: 216 Uptime: 1m wakeups: 3 Memory: total: 4 GiB available: 3.75 GiB
  used: 2.75 GiB (73.3%) Init: SysVinit v: 3.06 runlevel: 5 default: graphical tool: systemctl
  Compilers: gcc: 12.2.0 alt: 12 Client: shell wrapper v: 5.2.15-release inxi: 3.3.28
Boot Mode: UEFI

[m_pav]

A fully encrypted drive needs to have an unencrypted boot partition to read the bootloader out from. Your QSI shows, no partitions data found which might point to the source of the problem.

Is there any reason why you wouldn't just do a regular installation with full disk encryption and then integrate the changes you desire while respecting all drive naming and UUID conventions? All the other fluff concerning getting the touch working, in particular the kernel which I'm guessing is a third party kernel that needs some additional work-arounds to get working on your machine can be done post install.

[baldyeti]

I next copied the three relevant files (vmlinuz, initrd.gz and linuxfs)

Not that i ever tried anything this tricky or had to deal with similar HW, but wouldn't you also have to copy (at least) /usr/lib/modules/$(uname -r) ?

[thomasl]

@baldyeti I think this is being taken care after installing the new kernel (from a .deb file) and creating the encrypted live usb as those files will end up in the newly created linuxfs. At any rate, the non-boot happens way before anything is mounted anyway.

@m_pav I've seen that line in the QSI as well but the fact remains that my original MX23 (which created this QSI) boots perfectly OK on the SP4, encryption and all (/dev/nvme0n1p1 is the unencrypted EFI partition which carries the vmlinuz, initrd.gz and encrypted files needed to commence booting; /dev/nvme0n1p5 is the encrypted LUKS/ext4 partition with linuxfs and the persistence files). To reiterate: this boots and works very well, with the exception of the touchscreen, as evidenced by the QSI shown above. I've got no idea why the QSI shows no partition data but I'm inclined to think this is not the source of the problem, because...

The encrypted USB stick created by live-usb-maker with the new kernel does boot as well and works also, including the touch screen. So I've once again booted this and have done another QSI, see below. And lo and behold, this QSI also says there are no partition data. That's why I think that this is not the cause of the problem. Additionally, the "hanging" boot process clearly identifies the /dev/nvme0n1p* partitions and as I wrote in my OP, those partitions are readable from within the boot.

I think that there's perhaps a subtle but significant difference in the way rEFInd (and "my" grub2, both from the SSD) work and the way the grub2 from the booting USB stick works. Another possibility is a subtle but significant difference in the way the EFI partitions on the two drives have been created or work.

Last but not least the next two shots show the booting process. The first is from the SSD ("fatal error"), the second from the USB stick just before I enter the LUKS password.

To reiterate: the QSI in post #1 is the SP4 booting the original encrypted MX23 installed on the SSD, this QSI is the SP4 booting from the encrypted USB stick. The only difference between the booting SSD version and the non-booting SSD (see the first attached pic) are the three files I've copied from the USB stick to the exact same locations on the SSD: vmlinuz and initrd.gz to /MX23 on the unencrypted /dev/nvme0n1p1 and linuxfs to /MX23 on the encrypted /dev/nvme0n1p5... a layout that has booted before.

Code: Select all

Snapshot created on: 20240213_1535
System:
  Kernel: 6.1.13-surface arch: x86_64 bits: 64 compiler: gcc v: 9.4.0
    parameters: BOOT_IMAGE=/MX23/vmlinuz quiet checkfs bdir=MX23 loglevel=0 initrd=MX23/initrd.gz
    lang=en_GB kbd=us tz=Europe/London
  Desktop: Xfce v: 4.18.1 tk: Gtk v: 3.24.36 info: xfce4-panel wm: xfwm v: 4.18.0 vt: 7
    dm: LightDM v: 1.32.0 Distro: MX-23.3_x64 Libretto July 12  2024 base: Debian GNU/Linux 12
    (bookworm)
Machine:
  Type: Laptop System: Microsoft product: Surface Pro 4
    v: 124000000000000000000000D:0B:08F:1C:03P:38 serial: <superuser required> Chassis: type: 9
    serial: <superuser required>
  Mobo: Microsoft model: Surface Pro 4 serial: <superuser required> UEFI: Microsoft
    v: 109.3748.768 date: 05.04.2021
Battery:
  ID-1: BAT1 charge: 26.6 Wh (75.1%) condition: 35.4/38.2 Wh (92.7%) power: 21.8 W volts: 7.4
    min: 7.5 model: DYN X910528 type: Li-ion serial: <filter> status: discharging cycles: 62
CPU:
  Info: model: Intel Core i5-6300U bits: 64 type: MT MCP arch: Skylake gen: core 6 level: v3
    note: check built: 2015 process: Intel 14nm family: 6 model-id: 0x4E (78) stepping: 3
    microcode: 0xEA
  Topology: cpus: 1x cores: 2 tpc: 2 threads: 4 smt: enabled cache: L1: 128 KiB
    desc: d-2x32 KiB; i-2x32 KiB L2: 512 KiB desc: 2x256 KiB L3: 3 MiB desc: 1x3 MiB
  Speed (MHz): avg: 600 min/max: 400/3000 scaling: driver: intel_pstate governor: powersave
    cores: 1: 600 2: 600 3: 600 4: 600 bogomips: 19999
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: itlb_multihit status: KVM: VMX disabled
  Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
  Type: mds mitigation: Clear CPU buffers; SMT vulnerable
  Type: meltdown mitigation: PTI
  Type: mmio_stale_data mitigation: Clear CPU buffers; SMT vulnerable
  Type: retbleed mitigation: IBRS
  Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: IBRS, IBPB: conditional, RSB filling, PBRSB-eIBRS: Not affected
  Type: srbds mitigation: Microcode
  Type: tsx_async_abort mitigation: TSX disabled
Graphics:
  Device-1: Intel Skylake GT2 [HD Graphics 520] vendor: Microsoft driver: i915 v: kernel
    arch: Gen-9 process: Intel 14n built: 2015-16 ports: active: eDP-1 empty: DP-1, DP-2, HDMI-A-1,
    HDMI-A-2 bus-ID: 00:02.0 chip-ID: 8086:1916 class-ID: 0300
  Display: x11 server: X.Org v: 1.21.1.7 compositor: xfwm v: 4.18.0 driver: X:
    loaded: modesetting unloaded: fbdev,vesa dri: iris gpu: i915 display-ID: :0.0 screens: 1
  Screen-1: 0 s-res: 1710x1140 s-dpi: 96 s-size: 451x301mm (17.76x11.85") s-diag: 542mm (21.35")
  Monitor-1: eDP-1 model: Samsung 0x3853 built: 2015 res: 1710x1140 hz: 60 dpi: 167 gamma: 1.2
    size: 260x173mm (10.24x6.81") diag: 312mm (12.3") ratio: 3:2 modes: 2736x1824
  API: OpenGL v: 4.6 Mesa 22.3.6 renderer: Mesa Intel HD Graphics 520 (SKL GT2)
    direct-render: Yes
Audio:
  Device-1: Intel Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Imaging Unit driver: ipu3-imgu
    alternate: ipu3_imgu bus-ID: 00:05.0 chip-ID: 8086:1919 class-ID: 0480
  Device-2: Intel CSI-2 Host driver: ipu3-cio2 alternate: ipu3_cio2 bus-ID: 00:14.3
    chip-ID: 8086:9d32 class-ID: 0480
  Device-3: Intel Sunrise Point-LP HD Audio driver: snd_hda_intel v: kernel
    alternate: snd_soc_skl, snd_soc_avs, snd_sof_pci_intel_skl bus-ID: 00:1f.3 chip-ID: 8086:9d70
    class-ID: 0403
  API: ALSA v: k6.1.13-surface status: kernel-api tools: alsactl,alsamixer,amixer
Network:
  Device-1: Marvell 88W8897 [AVASTAR] 802.11ac Wireless driver: mwifiex_pcie v: 1.0 pcie: gen: 1
    speed: 2.5 GT/s lanes: 1 bus-ID: 02:00.0 chip-ID: 11ab:2b38 class-ID: 0200
  IF: mlan0 state: down mac: <filter>
Bluetooth:
  Device-1: Marvell Bluetooth and Wireless LAN Composite driver: btusb v: 0.8 type: USB rev: 2.0
    speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 1-5:6 chip-ID: 1286:204c class-ID: e001
    serial: <filter>
  Report: hciconfig ID: hci0 rfk-id: 0 state: down bt-service: N/A rfk-block: hardware: no
    software: no address: <filter>
  Info: acl-mtu: 1021:7 sco-mtu: 240:3 link-policy: rswitch hold sniff
    link-mode: peripheral accept
Drives:
  Local Storage: total: 364.76 GiB used: 6.69 GiB (1.8%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Samsung model: MZFLV128HCGR-000MV size: 119.24 GiB
    block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s lanes: 4 tech: SSD serial: <filter>
    fw-rev: BXV75M0Q temp: 27.9 C scheme: GPT
  ID-2: /dev/sda maj-min: 8:0 vendor: Generic model: USB3.0 CRW -SD size: 238.3 GiB block-size:
    physical: 512 B logical: 512 B type: USB rev: 3.0 spd: 5 Gb/s lanes: 1 mode: 3.2 gen-1x1
    tech: N/A serial: <filter> fw-rev: 1.00 scheme: GPT
  SMART Message: Unknown USB bridge. Flash drive/Unsupported enclosure?
  ID-3: /dev/sdb maj-min: 8:16 vendor: Toshiba model: TransMemory size: 7.22 GiB block-size:
    physical: 512 B logical: 512 B type: USB rev: 2.0 spd: 480 Mb/s lanes: 1 mode: 2.0 tech: N/A
    serial: <filter> fw-rev: 1.00 scheme: MBR
  SMART Message: Unknown USB bridge. Flash drive/Unsupported enclosure?
Partition:
  Message: No partition data found.
Swap:
  Alert: No swap data was found.
Sensors:
  System Temperatures: cpu: 34.0 C pch: 32.0 C mobo: N/A
  Fan Speeds (RPM): N/A
Repos:
  Packages: pm: dpkg pkgs: 1886 libs: 961 tools: apt,apt-get,aptitude pm: rpm pkgs: 0 pm: flatpak
    pkgs: 0
  No active apt repos in: /etc/apt/sources.list
  Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list
    1: deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/debian.list
    1: deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
    2: deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/mx.list
    1: deb http://mxrepo.com/mx/repo/ bookworm main non-free
  Active apt repos in: /etc/apt/sources.list.d/vivaldi.list
    1: deb [arch=amd64] https://repo.vivaldi.com/stable/deb/ stable main
Info:
  Processes: 221 Uptime: 2m wakeups: 2 Memory: total: 4 GiB available: 3.76 GiB
  used: 1.47 GiB (39.1%) Init: SysVinit v: 3.06 runlevel: 5 default: graphical tool: systemctl
  Compilers: gcc: 12.2.0 alt: 12 Client: shell wrapper v: 5.2.15-release inxi: 3.3.28
Boot Mode: UEFI

[thomasl]

OK, problem solved. This is a wee bit involved but perhaps it helps someone else with the same or similar problem. Also perhaps an interesting read for those poor souls (like me) who love to play with boot sectors, EFI files and suchlike

To boot a frugal encrypted MX via EFI, you need three elements.
1. The EFI boot files (ie grubx64.efi or the rEFInd stuff). These reside on the EFI partition and this has to be a vfat partition.
2. The three files vmlinuz, initrd.gz and encrypted (that's the literal filename and the file has the UUID of the encrypted partition) to start the boot process. These have to be on a mountable and unencrypted partition.
3. linuxfs and the persistence files (rootfs and/or homefs). These are on the encrypted partition referenced by the "encrypted" file of point 2.

So now to my problem. On the booting USB stick (which,let's remember, was created by live-usb-maker), there are three partitions:

The first (Live-usb) is ext4 and has the files mentioned in point 2 above.
The second is the LUKS-encrypted ext4 partition mentioned in point 3 above.
The third (LIVE-UEFI) is simply the EFI partition.

On my non-booting SP4 SSD, there are only two relevant partitions because I so far have always put the EFI files (point 1) and the unencrypted files of point 2 on the same partition, namely the EFI vfat partition (/dev/nvme0n1p1), and the files for point 3 in an LUKS-encrypted ext4 partition (/dev/nvme0n1p5). And that's where the trouble starts. The new SP4 vmlinuz and initrd.gz are loaded by the boot loader (rEFInd or grub2) from the EFI partition (by definition the boot loader must be able to read the vfat EFI partition). So after loading those two files the loader lets the kernel, vmlinuz, take over which runs the init script. This in turn now has to find and read the file needed to boot the LUKS-encrypted system: the file called "encrypted" with the UUID of the encrypted partition. To do this, init has to mount the "candidate" partitions and look for file "encrypted".

And now the whole thing implodes: the standard 6.1 MX kernel can mount vfat partitions, so it'll happily mount my EFI (vfat) partition with the "encrypted" file, locates and reads it and goes ahead with booting the system from the encrypted partition. By contrast, the new SP4 kernel simply doesn't (perhaps even can't) mount vfat partitions on its own, so it'll not mount my EFI (vfat) partition with the "encrypted" file... and so can't find that file... and naturally calls it a day . The live USB stick version doesn't have that problem, since there only the EFI files are on the vfat partition (3), the other files needed (point 2) are on an ext4 partition (1) which the new SP4 kernel can mount on its own... and so the init script can locate and read the "encrypted" file.

So to resolve this I simply copied the "encrypted" file to an unencrypted existing ext4 data partition (/dev/nvme0n1p7 in my case) and

Yeah, the booting stuff is always good for a surprise or three.

[fehlix]

I next copied the three relevant files (vmlinuz, initrd.gz and linuxfs) to the existing MX23 frugal install (with the old kernel) on the SP4. vmlinuz and initrd.gz sit on the EFI partition in /MX23 (plus the "encrypted" file with the UUID of the encrypted partition). The new linuxfs goes into /MX23 on the encrypted partition. I double-checked everything and re-booted. Or rather, didn't as the boot broke off with the message that "MX23/encrypted" can't be found on any searched device. Among the searched devices is /dev/nvme0n1p1, the one with all EFI files and with vmlinuz, initrd.gz and encrypted in /MX23.

If understand this correctly your bootdir "/MX23" is on the ESP of the SSD. As ESP is normally a vfat (FAT32 or similar FAT),
suggest to use lowercase to avoid the FAT lower/uppercase filename issues.

[thomasl]

@fehlix I've used /MXL (for MX18), /MX19 and /MX23 for many years now w/o ever running into any problem. What exactly are those issues you're talking about? (Googling brought many pages but no obvious warning of trouble.)

(At any rate, methinks the case of MX* has no bearing on this thread's problem.)

[fehlix]

@fehlix I've used /MXL (for MX18), /MX19 and /MX23 for many years now w/o ever running into any problem. What exactly are those issues you're talking about? (Googling brought many pages but no obvious warning of trouble.)

In short:
On FAT file systems file-/directory name with mixed upper /lower case
like mx23 or MX23 are identical.
And on the early stage, you never know what the used (on efi or busybox) kernel file system driver
will report back. Highly depend on the used mount options or the default ones
use by the kernel, which may also get adjusted in newer kernels.
For finding files /or directories on the ESP you often will find such constructs:
regexp [EeFfIi] constructs to cater for /EFI or /efi reported names, which are pointing
to the identical directory.
Also the filesystem may only report 8.3 names, and not a longer name which was used originally.
Try this on fat:

Code: Select all

touch me
mv me ME

and you get error, b/c you cannot move a file to itself, as they are identical.

(At any rate, methinks the case of MX* has no bearing on this thread's problem.)

Maybe, you solved probably both of two potential issues with moving to ext4,
the FAT upper/lower case issue, and potentially the live-system may either not look for fat or not using the fat mount option to get
mixed names properly for the encrypted flag file. The later I have not confirmed, b/c haven't looked in to the live-init code for luks recently, yet.

[thomasl]

Yeah, it's well-known that MS OSes are case insensitive, though IIRC they're case preserving. Anyway, the point here seems to be what various kernels, drivers etc actually do in the field and not what the MS stuff does. So point taken but as I had no trouble with MX* so far I'll stick with it. And thanks, @fehlix, for the heads up.