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

Bug#983107: os-prober: generic subvolume support for btrfs



Hi Osamu,

Correction for previous email: Fedora 33 does not use "subvol=rootfs",
it uses "subvol=root".  I'm not sure if they changed this sometime in
the last few years, or if I misremembered and typed "rootfs" by habit.

Reply follows inline:

Osamu Aoki <osamu@debian.org> writes:

<snip>

> If you want to use timeshift (Ubuntu origin?) or snapper (Suse origin
> ?), they seem to use non-ID-5 subvol for the system install, i.e.,
> root-FS.  People use these tools on Debian too.
>

Doesn't this mean the new subvol=@rootfs (without set-default=@rootfs)
actually fulfills the assumptions required by Timeshift (Ubuntu
subvol=@, no set-default=@) and Snapper?

Hideki, would you please confirm that the changes introduced in
partman-btrfs 53 do not break Snapper?  If so, is it difficult to fix
this in Snapper, and if necessary, do you have time to do so before
bullseye's release or would you like help?  I still worry that Snapper
might have SUSE-specific assumptions in its design (see previous message
at bug #983107 for more context), and if the "subvolid=5" aka "subvol=/"
(Debian pre-bullseye) has hidden a "set-default=@" (SUSE) assumption
that might now manifest as broken functionality in Snapper.
Alternatively, maybe snapper installs a grub config hook?

<snip>

> === Additional Tips ===
>
> You can convert a system from EXT2/3/4 to btrfs as follows by booting
> system from another system on the multiboot set-up.
>
> File system conversion is trivial as described in
> https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3
>
> -----
> $ sudo fsck.ext3 -f /dev/xxx
> $ sudo btrfs-convert /dev/xxx
> $ sudo mount -t btrfs /dev/xxx /mnt
> -----

Ahhh.  Is the ext4-to-btrfs via btrfs-convert case the basis for your
preference for the use of subvol=/ or set-default=@foo?

<snip>

> Also, you need to update many relevant parts of grub.cfg, too.  Roughly
> as ...
> -----
> --- grub.cfg-orig       2021-02-17 09:32:35.855910912 +0900
> +++ grub.cfg    2021-02-19 14:26:12.728005239 +0900
> ...
> -insmod ext2
> +insmod btrfs

Given "You can convert a system from EXT2/3/4 to btrfs as follows by
booting system from another system on the multiboot set-up": 

From a live boot with live/rescue media, update-grub already does the
right thing for subvolume renames, or moving rootfs from subvolid=5 to a
named subvolume mounted with "-o subvol=@foo", and I don't know why the
btrfs-convert case is special.  Why not, post-btrfs-convert:

1. umount the just-converted partition
   * suppose it's /dev/sda2
2. mount /dev/sda2 -o subvol=/ /target
3. btrfs sub snap /target /target/@rootfs
4. btrfs sub sync /target && btrfs fi sync /target
   * hasn't been necessary since linux-4.4 IIRC
5. umount /target
6. mount /dev/sda2 -o subvol=@rootfs /target
7. (make bind mounts)
8. chroot to /target as usual
9. update-grub as usual

ISTM that update-grub will do the right thing ("-insmod ext2; +insmod
btrfs") if the partition is unmounted, then remounted before running
update-grub.

Cheers,
Nicholas

Attachment: signature.asc
Description: PGP signature


Reply to: