Hi, On Sat, 3 Oct 2026 11:27:04 +0900 Sunjoong Lee <[email protected]> wrote:
> Hi Guix Community, > > During a severe heatwave this past summer, my main system's old hard > drive unfortunately failed. Fortunately, I was able to temporarily > boot into Windows using a Ventoy-based "WindowsToGo" USB image I had > created a while ago. However, my primary OS is GuixSD. While > struggling to recover my environment, an idea struck me: "Can we > declaratively create a 'GuixToGo' system that boots from a single USB > drive while fully maintaining configurations and support upgrades, > just like WindowsToGo?" I've no idea what WindowsToGo is, but booting Guix on USB drives is relatively easy to do and it doesn't require custom code, as long as specific partition(s) in the drive are dedicated to Guix. That said, I find the idea of booting of a loop file interesting because that enables to easily test a configuration that is isolated from the rest of the system, without any additional hardware. I think that the implementation could be simplified somehow, especially if you want to upstream part of it (in order to be able to use it with more recent Guix revisions). A way to do that would be to depend on ventoy because ventoy uses a modified GRUB with a custom Linux kenrel module to create a block device out of loop file, so that makes integration in a lot of environments difficult. As I see it, Guix should instead be modified to retrieve where the loop file is, how to mount it, etc, ideally from inside (mapped-devices [...]) and (file-systems) inside system definitions, because the file could be inside an encrypted filesystem, on a RAID device, in an LVM partition, etc. And this would also allow to just use loop files in general. Then there is the problem of how to boot the kernel and the initramfs. Here if things don't depend on ventoy, this also opens the door to a lot more possibilities. For instance Guix could be modified to generate a grub configuration as well so people would copy the results in specific locations (like /guix/rootfs.img and /guix/grub.cfg) and once /guix/grub.cfg is loaded by the GRUB of another distribution, /guix/grub.cfg would contain code that would then open the loop device and load the GRUB configuration that is inside the loop device which would load the kernel and initramfs. This would require to take care of a lot of things and/or reflect constraints to users. For instance GRUB itself doesn't see BTRFS subvolumes (so GRUB tools detect that in GNU/Linux and generates a GRUB configuration that produces the right path, even with subvolumes). The generated GRUB configuration inside the loop would need to be made for loop devices, etc. But this would also allow to generate an UEFI GRUB image instead that could also do all that work as well. Under GNU/Linux, efibootmgr can add UEFI boot entries and so on. But on other OS I've no idea if something similar is available or not. A kexec script could be generated as well. So a lot more possibilities are possible if we don't depend on ventoy. That said using ventoy should also normally work with this new scheme out of the box, and here you would just use labels to describe the partition(s) of the USB key and you'd also describe in which partition the loop file is. About: > I discovered an interesting limitation: Guix's built-in > find-partition-by-label fails on NTFS partitions because it does not > fully parse the NTFS Master File Table (MFT) structure. This could also be fixed along the way. Or if it's too complex to fix maybe some files in '/dev/disk/by-*/' are persistent enough and available in the initramfs. Also if the goal is to boot on NTFS without Windows, it would be a good idea to warn users that we don't have any free software tool that can repair NTFS partitions (see ntfsfix for more details), so it would be a good idea to only use NTFS for that that is fast to recreate. And if the idea is to boot on NTFS with Windows, then, it would probably require users to go in their UEFI settings and add the grub image by hand as I'm unsure if there is something like efibootmgr on Windows. In either case it would also be a good idea to make sure that the in-kenrel new NTFS driver is used to simplify the implementation and just see NTFS as a regular filesystem. Denis.
pgpoqEwuFg6ti.pgp
Description: OpenPGP digital signature
