-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all,
There is a problem with our shiny new templates for Qubes 4.0. Partition table there make it hard to resize root filesystem. Current partition layout of a template in Qubes 4.0 is: 1. xvda1: root filesystem (almost all available space) 2. xvda2: EFI system partition (empty, prepared for PVHv2 boot with VM-provided kernel) 3. xvda3: BIOS boot (grub2 installed, used when `kernel=''`) This makes resizing root volume hard, because one need to move xvda[23] data to the (new) end of the disk first. Also, having partitions at all (de facto required by grub2), makes online resize of root volume hard/impossible. Proposed solution: reorder partitions to 1. ESP, 2. BIOS boot, 3. root filesystem. This will not solve online resize problem, but will allow offline one (with VM restart in the middle). The problem is, it is a bit late for changing such fundamental thing... Affected components: - template builder[1] - initrd[2] (responsible for mounting root filesystem) So, at this stage, changing partition layout (dropping support for the current one, adding support for the new one) IMO is out of the options. The only possibility (if at all) is to add support for new layout and keep support for the current one. In a way not breaking the current setup. Alternatively, we can keep it as is (and change later - like in Qubes 4.1). And for now document how to extend root volume manually. Something like: 1. Shutdown VM (TemplateVM/StandaloneVM) 2. Use `qvm-volume` to extend root volume 3. Set VM kernel to some version (if was set to empty - i.e. VM provided) 3. Start VM 4. Launch fdisk, remove all partitions 5. Re-create partition 1 with new size - almost the whole disk - minus 202M, set its type to "Linux" 6. Re-create partition 2 with size 200M, set its type to "EFI system partition" 7. Re-create partition 3 with size 2M, set its type to "BIOS boot" 8. Restart VM (to reload partition table) 9. Re-install grub (`grub2-install /dev/xvda`) 10. Restore original kernel property (if changed in step 3) A lot of things can go wrong in the process. Yet another option would be to automate the above in initrd, before mounting root filesystem - so it is possible to reload partition table there, without VM restart. This would require copying data of partitions 2 & 3. Not sure if grub will survive such thing (because of moving BIOS boot partition). It is fragile operation, too. Any preference, or maybe another solution? Tracking issue: https://github.com/QubesOS/qubes-issues/issues/3173 [1] https://github.com/QubesOS/qubes-linux-template-builder/blob/master/prepare_image#L59-L76 - - and other places there assuming root fs is on the first partition [2] https://github.com/QubesOS/qubes-linux-utils/tree/master/dracut - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJZ36tUAAoJENuP0xzK19csGXcH/iwlhVVSURbAxGB9Xam1q7po RoOSG8SqOTU56zGw2V+3I1ILZcwXDmlUy9qE2Fqpn7ZkeuOpV22mzRh4Bl+yFxaH s0tTta3SQb7vxkf5GW1/2bScSmmvJ9onLKPcX42PLEMfAzgS/nJ716Oi7HWYB+l3 hO+oYezBGUELJ+LY1sXUwUmCGupFxlYqITwIa4CP0EK2HgtfW4LoiwpVI9pnt6bB HCFT617MKldszIibKRVSjgRpHexAdKg+IPE7y2lFkJHAAg5dMwjCkDQAJ8BcS50t dmp5oKWOHgyZEzuvmI9M8qfXH6m7Okfwyf3Cpr1KShQzYuwZ6d0ZpTpoyuWgQT4= =+a57 -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20171013222228.GF10749%40mail-itl. For more options, visit https://groups.google.com/d/optout.
