Re: [RFC] btrfs: strategy to perform a rollback at boot time

[Goffredo Baroncelli <kreijack@inwind.it>]

On 7/27/20 7:25 PM, Goffredo Baroncelli wrote:
> On 7/27/20 2:26 PM, David Sterba wrote:
>> On Fri, Jul 24, 2020 at 01:56:58PM +0200, Goffredo Baroncelli wrote:
>>>> This could be done already from the initramfs.
>>>
>>> Ok, this means that we have three possibility:
>>> 1) do this at bootloder level (eg grub)
>>> 2) do this at initramfs
>>> 3) do this at kernel level (see my patch)
>>>
>>> All these possibilities are a viable solution. However I find 1) and
>>> 2) the more "intrusive", and distro specific. My fear is that each
>>> distro will take a different choice, leading to a more fragmentation.
>>> I hoped that the solution nr 3, could help to find a unique solution....
>>
>> IMO bootloader or initrd are the right places to do the mount test and
>> eventual rollback. What kernel provides is to mount the subvolume, it's
>> up the the user to supply the right one. When I read the proposal the
>> option 2 was the the first thought that can be implemented with the
>> existing kernel support already.
>>
>> Distros take different approach to various problems, and this is fine.
>> Here the list of fallback subvolumes, naming, where it's stored or
>> whatever may differ and the kernel provides the base functionality.
>>
>> It would make sense to push that down one level in case all distros have
>> to repeat the same code and there would be an established way to do the
>> main/rollback switch.
> 
> I am looking for another solution, which is based on some suggestions taken
> from Zygo and Chris. This solution requires no change to initrd, kernel and bootloader.
> 
> More or less the sequence is the following:
> 
> During the upgrade
> ==================
> 1 cleanup previous unclean subvolume and snapshot pairs (due to an unattended abort)
> 2 take a snapshot of the main subvolume
> 3 swap (atomically via renameat2) the original subvolume and its snapshot
>      this means that in case of an unattended reboot, the system starts
>      from the snapshot
> 4 update the filesystem
> 5 re-swap original subvolume and its snapshot
> 6 delete the snapshot (or collect it to provide a way to return to previous configuration)

Of course the devil is in the detail: with the process described above, during "grub" upgrade
the grub.cfg will be generated on the current root subvolume, which is the name of the snapshot

:-(


> 
> This procedure has three possible endings:
> 1) all ok, nothing to do
> 2) unattended reboot happened; at startup a cleanup of the subvolume is required
> 3) unattended abort happened without a reboot; we still have the two subvolumes, at least
> during the shutdown the subvolume and its snapshot have to be swapped (if required)
> 
> During the startup
> ==================
> A script checks if the system started from the snapshot, and if so
> delete the original subvolume (or collect it to provide an history)
> 
> 
> During the shutdown
> ===================
> a script checks if both the subvolume and its snapshot are present.
> This happens if the upgrade procedure abort for some reasons (but the system doesn't reboot).
> In this case I think that it is safe to swap snapshot and original subvolume and
> drop the snapshot (or collect it to provide....)
> 
> 
>>
> 
> 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5