On Tue, Dec 15, 2020 at 12:14 PM Brian C. Lane <bcl@xxxxxxxxxx> wrote: > > On Mon, Dec 14, 2020 at 11:03:03PM -0700, Chris Murphy wrote: > > Right. The two I've previously suggested: btrfs seed and dm-verity. > > Every read is verified, the user can't opt out, and they are more > > performant than checkisomd5. Upon detecting error, both emit EIO which > > is handled at the application level, i.e. stop the installation and > > notify the user. > > Those would require significant changes to how live works though. Simple > is better. I agree simpler is better. Btrfs is a drop-in replacement for ext4, assuming no other changes. Like I said, Will Woods had this working a long time ago. This is not my original idea. I've tried it and it works fine, and we get integrity checking for data and metadata for free.[1] I'm not sure what significant change you think is required. https://www.redhat.com/archives/anaconda-devel-list/2011-March/msg00263.html New functionality certainly would require significant changes. For example: Matt and Máirín Duffy et al, have been discussing a try-it-out-and-maybe-install-later workflow. This proposes making the USB stick media persistent by default. https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx/thread/OJYOUDZVPGUILFEXJWOYNTABNWPWO4ZO/ This suggests two new use cases: - Persistence by default for USB stick media - An easy way to migrate the USB stick environment to a permanent installation The live ISO tells three conflicting truths about itself: ISO 9660, MBR, and GPT each tell different stories. To add persistence, we need to add a partition. Per the UEFI spec, this MBR with two partition entries means the GPT is invalid. Possibly the preferred tool is systemd-repart, which only works on GPT, but if it's strictly spec complying it won't see the GPT as valid. The alternative is to get Fedora Media Writer capable of doing surgery on these two partition maps. That sounds significant and I don't really want to go down that rabbit hole if it's avoidable. Maybe the USB stick image needs to be a new dedicated image. Drop the ISO 9660 portion, and just make it a simple spec complying GPT, and then once written to a USB stick, we can setup the additional partition with write persistence from the initramfs. Making the rootfs Btrfs has other advantages for the "try before you (don't) buy (because it's free!)" workflow. It will behave like a real installation, rather than layering two different file systems. Btrfs features are available to this user from the start, rather than getting different experiences. Enabling compression by default will improve throughput and reduce latency. Even fast reading USB sticks write slowly. Data integrity for everything, metadata and data. And the option to do either a clean install from this stick media, or easily migrate their entire persistent modifications to a permanent installation. Somewhat simplified: btrfs device add /dev/laptop / btrfs device remove /dev/stick / That implies mkfs, resize, and kicks off replication of block groups from the USB stick to the laptop drive. All apps (app removals, additions, updates), customizations, user files, subvolumes, snapshots - one command. We still need all the bootloader stuff Anaconda does, the option to clean install or replicate is just a matter of picking between two fs UUIDs or labels. And yeah all of that is significant. But that's new functionality. Not because it's Btrfs. Whether it's something better suited for Ignition than Anaconda, will need to be explored. >If squashfs has integrity checking it would be perfect :) It > looks like zstd has support for checksums but it doesn't look like > that's supported in any of the tools, or the kernel squashfs module. > > Another possibility is for lmc to add a sha256sum of the rootfs image > that can be checked by dracut when booting, or anaconda before > installing. Doesn't this turn back the clock to 2005? The point of computing md5 fragments was to fail sooner. https://www.redhat.com/archives/anaconda-devel-list/2005-March/msg00053.html [1] by default btrfs uses 4 bytes crc32c per 4KiB. md5sum on ~20 fragments, recording only 3 characters from each md5sum to create the ISO's md5sum. This surely exposes the check to collisions, but maybe someone would like to compute this. A 4 byte crc32c per 4KiB has a chance of collisions, but on a file system less than 1T, the probability is low. But if that is considered risky these days, the image can use one of the other hashes available. -- 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
