Re: Installation image layout

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

 



On Sun, Oct 14, 2018 at 12:21 PM, Neal Gompa <ngompa13@xxxxxxxxx> wrote:
> On Sun, Oct 14, 2018 at 1:58 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
>>
>> On Sat, Oct 13, 2018 at 6:24 PM, Neal Gompa <ngompa13@xxxxxxxxx> wrote:

>> > This is a really interesting idea...
>>
>>
>> https://lore.kernel.org/linux-btrfs/CAJCQCtTPwQnzwkpk=4ZsZXfWTC7HymYETxp-9xUU_tsvOTW0ZQ@xxxxxxxxxxxxxx/t.atom
>>
>
> I'm interested to see how that thread turns out... It's a tempting
> idea, because it gives you so much more flexibility. Installation onto
> a disk could be a "btrfs send" and overlay changes could be easily
> flattened on top of the target system. It'd also be much cheaper and
> lighter for supporting the live environment.

Ha! I just realized after all this time that the Btrfs wiki does not
make clear how to make a sprout, even though it mentions the more
esoteric recursive seed.[1] Of course you can mkfs.btrfs, mount it,
and send/receive. But send requires read only snapshots. Making a
sprout is easier, you just remove the seed device. This is supported
since 2009.

# losetup -r /dev/loop0 root.img
# mount /dev/loop0 /mnt/
# btrfs device add /dev/sda3 /mnt
# mount -o remount,rw /mnt
# btrfs device remove /dev/loop0 /mnt

And now it replicates extents from seed to sprout.  The copy is faster
than pvmove, rsync, dd, or rpm-ostree deploy.

OK so let's say you have a USB stick 'sdb' and internal drive 'sda'.
And the stick already has a Fedora LiveOS imaged on it, only change is
the root.img is a Btrfs seed. The simplistic systemd pre-mount and
mount look like:

# losetup -r /dev/loop0 root.img
# mount -t btrfs /dev/loop0 /
# btrfs device add /dev/zram1 /
# mount -t btrfs -o remount,rw /

- now you have a live overlay in RAM; user can start using this LiveOS
environment including making changes like installing software; setting
up non-volatile persistence on the stick looks like:

# btrfs device add /dev/sdb3 /
# btrfs device remove /dev/zram1 /
# echo 1 > /sys/class/zram-control/hot_remove

- now the extents on zram1 are moved from zram1 to sdb3 (the stick);
setting up an installation to the internal drive 'sda' by "flattening"
as you say, merely means adding the internal drive to the mounted
Btrfs volume and removing all others:

# btrfs device add /dev/sda3 /
# btrfs device remove /dev/sdb3 /
# btrfs device remove /dev/loop0 /

- now extents on sdb3 (stick) and loop0 (seed) are copied to sda3
(internal), including any changes the user is making while all of this
is happening. In fact, the user does not even have to reboot because
once the operation finishes, and the loop is torn down, the stick is
not in use by the kernel. The user can just unplug the stick and keep
working. A spin or downstream could very sanely, and straightforwardly
build a no-UI OS installation.

It's not obvious that 'btrfs device add' incorporates a mkfs and that
you can now just delete the ro seed. Also not obvious is the 'dev add'
on an ro mounted seed causes a new volume UUID to be generated. This
is immediately discovered by libblkid. The kernel knows that this new
volume is a two device (or three device, whatever the case is) btrfs
and which devices they are. And this is such basic btrfs handling code
that GRUB and extlinux Btrfs code understand it.

[1]
https://btrfs.wiki.kernel.org/index.php/Seed-device


-- 
Chris Murphy
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
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