WangLu's Notes

After a routine system update and an unfortunate hang that required a hard reset, my Linux machine refused to boot. Instead of the familiar login prompt, I was greeted by a cryptic GRUB error:  error: no cryptodisk module can handle this device. My setup uses LUKS2 + LVM. From the GRUB rescue shell, I could actually decrypt the LUKS container. But once decrypted, GRUB completely failed to detect any LVM volumes. It simply acted as if the LVM structure didn't exist. Meanwhile, if I boot it from a Live Rescue USB, everything worked perfectly. I could open the LUKS container, and the volume group appeared immediately. Tools like  vgck  and  pvck  reported no issues. After a length discussion with AI, eventually I found the magical commands: vgcfgbackup -f lvm_backup.txt <vg_name> vgcfgrestore -f lvm_backup.txt <vg_name> After running these commands and rebooting, GRUB recognized the LVM volumes immediately, and I was back in my system. Supposedly this f...

I recently tried to install Qubes OS alongside an existing Windows installation. It turned out to be surprisingly difficult—way harder than my last attempt—likely due to a combination of my encrypted  /boot  setup and older hardware. Here are some notes from the process. Shrinking an NTFS Volume I needed to free up some space from a Windows NTFS volume. Normally, this just takes a few clicks in Disk Management. This time, however, Windows reported a "shrinkable volume" that was suspiciously small. Following  this answer , I tried the standard fixes: Disabled hibernation ( powercfg /h off ) Disabled the pagefile Disabled system protection This increased the shrinkable volume a bit, but nowhere near the actual free space left on the partition. Digging into the Windows Application logs in Event Viewer, I finally found the culprit:  The last unmovable file appears to be: \$Mft::$DATA . It turns out  $Mft  is a special block in NTFS that cannot be easily moved, ...

I've been running Qubes OS on Machine A alongside Windows for a while. My setup involved storing the unencrypted  /boot  partition and the LUKS header on an external USB drive. Recently, I planned to install Qubes on Machine B, also in a dual-boot configuration. However, the complexity jumped significantly: Machine B has Secure Boot enabled because BitLocker requires it. On previous installs, I grew tired of toggling Secure Boot in the BIOS every time I switched operating systems. I only have one USB drive. Managing separate  /boot  partitions for two different Qubes installations on a single thumb drive is messy. After some experimentation, I found a way to solve both problems. Sharing One USB Drive for Multiple Qubes Installations The solution is elegant: Don't store  /boot  on the USB drive. Instead, move  /boot  to the encrypted internal disk partition. The USB drive's only job is to unlock that partition and hand over control to the system. O...