Re: Pre-made live image with actual functioning persistent storage?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Following from the Btrfs as rootfs idea in the "Proposal: drop 'Test
installation media' from live media" thread, I went down the separate
rabbit hole of how to do persistence by default. The following is not
Btrfs specific.

The xorriso options (isohybrid-mbr, et al) we're using creates a
deeply conflicted image. I'm not finding an easy way of dealing with
it. The short answer is, I think we need a dedicated image for
enabling persistence. Or alternatively, teach Fedora Media Writer how
to do substantial surgery akin to livecd-iso-to-disk, but going even
further.

Here's what I've found with the current Live ISOs used by desktops:

1. The image, and thus the USB stick, is firstly an ISO 9660 image.
This format "owns" the entire media, and has no partitions.
2. The image also has MBR and GPT partition maps with different
(conflicting) information in them. These are intended to be used by
the firmware when booting the image from a USB stick.
3. Because the MBR is not a PMBR, and also has more than one partition
entry, per the UEFI spec the GPT is invalid.
4. I haven't discovered a tool that will modify the GPT alone, without
insisting on stomping on the MBR. gdisk even refuses to modify the
GPT, requiring a completely new GPT. I expect systemd-repart won't
touch the GPT either: a) it only supports GPT, b) the GPT is invalid,
c) the MBR isn't a PMBR.
5. Overwriting the MBR and GPT with a proper one that contains merged
partitions from both the original MBR and GPT still boots both UEFI
and BIOS computers.
6. However, following boot, /dev/vda is considered ISO 9660 by linux.
None of the partitions will mount. I get EBUSY.
7. I can't create a file system for overlayfs, nor extend the Btrfs
seed rootfs, using a spare partition I've created from the vast free
space on the USB stick. I get EBUSY.

So I'm stuck. The rootfs image needs to be extracted from the ISO 9660
image, in order to bring about the possibility of persistence.
Further, it should do so in a way that doesn't require the entire
stick to be FAT32 based, which limits root and home to 4G each at
best.

A. Teach Fedora Media Writer how to do this surgery.
B. Teach the compose system, maybe OS Build, to create a ready-to-go
image for this purpose.


--
Chris Murphy
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux