Achim Gratz writes:

How exactly? I know how to mount sublvolid=0 to some temporary place, but I don't find a way to check which subvolume is actually mounted as / at the moment, for instance.

OK, the latter part is done by # btrfs subvolume show / and it clearly shows that it is indeed having the snapshot mounted. So if I mount the btrfs root to some other place, what do I need to do before I can set the default subvolume back to zero? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andrei Borzenkov writes:

How *me* would do it - boot from live media, mount current snapshot on /src and root subvolume on /tgt and run

rsync -a --delete /src/ /tgt/

then reset default subvolume.

Hmm. Wouldn't that stomp all over hardlinks and such stuff?

But you can also try what is suggested here

https://www.suse.com/documentation/sled-12/book_sle_admin/data/sec_snapper_s...

i.e. snapper rollback. I wonder if this does not do the same under the hood ... :)

That's what got me where I am today. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andrei Borzenkov writes:

That definitely requires bug report.

https://bugzilla.suse.com/show_bug.cgi?id=937047 Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

В Fri, 03 Jul 2015 20:05:20 +0200 Achim Gratz пишет:

Andrei Borzenkov writes:

...

...

# btrfs subvolume get-default / ID 2337 gen 115112 top level 282 path .snapshots/1974/snapshot

Yes, I never liked it and still believe that is wrong design. ...

I don't understand what you are trying to say.

I think that more clean solution would be to have /<subvol>/ <root-1> <root-2> ... This way you can switch between them by just adding rootflags=subvol=root-1, there is no special dedicated "initial root" which makes it easy to go back and forth between them, Top level subvolume is just to group them in one namespace.

...

...

So how do I get the default subvolume back to where it should be, so

As far as I understand the only possibility is to copy data from current snapshot to top level volume and reset default. There is no way I am aware of to reshuffle subvolumes in btrfs.

How exactly? I know how to mount sublvolid=0 to some temporary place, but I don't find a way to check which subvolume is actually mounted as / at the moment, for instance.

btrfs subvolume show /

...

...

I can remove some more snapshots and do the update?

Why cannot you remove other snapshots? They should be independent, no?

I can remove other snapshots, however there is no indication that some snapshot in the midst of things really is the default subvolume and the next time the snapper cleanup tried to delete this snapshot (unless it checks for the default subvolume) it will hose the system again.

I'm not sure it was intended to run this way for a long time. But I guess bug report won't harm. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello Achim, Andrei, and all, On 2015-07-03 T 21:25 +0300 Andrei Borzenkov wrote:

I think that more clean solution would be to have

/<subvol>/ <root-1> <root-2> ...

This way you can switch between them by just adding rootflags=subvol=root-1, there is no special dedicated "initial root" which makes it easy to go back and forth between them,

Top level subvolume is just to group them in one namespace.

this is not exactly, but very similar to how it works in SUSE Linux Enterprise 12, and how I had assumed it were configured in openSUSE 13.2 and Tumbleweed. However, I learned last week that the configuration (at least of openSUSE 13.2) is different from the one in SUSE Linux Enterprise 12, and this might lead to this question and problems. For the future, the plan is this: - the root filesystem is _always_ installed in a separate subvolume - the "independent" subvolumes (/var/log, /opt, /srv, /home) are by default installed underneath another separate primary level subvolume called "@" (this naming is inherited from the Debain community years ago) With that setup a clean switching between different "root"s is possible. More details in the Bugzilla on monday. Enjoy the weekend! So long - MgE -- Matthias G. Eckermann, Senior Product Manager SUSE® Linux Enterprise SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Jul 6, 2015 at 10:16 AM, Thorsten Kukuk wrote:

On Fri, Jul 03, Andrei Borzenkov wrote:

...

В Fri, 03 Jul 2015 20:05:20 +0200 Achim Gratz пишет:

...

Andrei Borzenkov writes:

...

...

# btrfs subvolume get-default / ID 2337 gen 115112 top level 282 path .snapshots/1974/snapshot

Yes, I never liked it and still believe that is wrong design. ...

I don't understand what you are trying to say.

I think that more clean solution would be to have

/<subvol>/ <root-1> <root-2> ...

This way you can switch between them by just adding rootflags=subvol=root-1, there is no special dedicated "initial root" which makes it easy to go back and forth between them,

Top level subvolume is just to group them in one namespace.

That's exactly what we have today.

Except that system itself is installed in top level subvolume. At least, it was this way last time I tried btrfs install.

Except that the path is: /.snapshots/<id>/snapshot/ and not /subvol/root-<id>

And with grub2 you don't need "rootflags=", grub2 shows you all available "root" you can boot into.

The question is not to boot into it but to revert your top level volume to the same state as one of these snapshots. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello Andrei and all On 2015-07-06 T 10:29 +0300 Andrei Borzenkov wrote:

...

That's exactly what we have today.

Except that system itself is installed in top level subvolume. At least, it was this way last time I tried btrfs install.

as I wrote, this unfortunately is a difference between openSUSE and SUSE Linux Enterprise: SUSE Linux Enterprise does install the original root filesystem in a separate subvolume (called "@"), and I am convinced that this is the right™ way, and thus is what openSUSE should also do going forward. Please open a separate bugreport for Tumbleweed, thus the change can be tracked, ... So long - MgE -- Matthias G. Eckermann - Senior Product Manager SUSE® Linux Enterprise SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2015-07-06 T 12:15 +0200 Jan Engelhardt wrote:

Well, probably so. But at the same time, it would help if btrfs had a "pivot_root"-ish interface to swap the root subvolume with another, so as to facilitate quick snapshot deletion of the root volume. :)

While this sounds useful, I doubt that it is practically possible. Example: I am running Kernel 3.12.43-52.6-default, and I have a root filesystem with these four kernels installed: # ls -1d /lib/modules/* /lib/modules/3.12.28-4-default /lib/modules/3.12.38-44-default /lib/modules/3.12.39-47-default /lib/modules/3.12.43-52.6-default Now, my snapshot 707 has these kernels installed: # ls -1d /.snapshots/707/snapshot/lib/modules/* /.snapshots/707/snapshot/lib/modules/3.12.28-4-default /.snapshots/707/snapshot/lib/modules/3.12.36-38-default /.snapshots/707/snapshot/lib/modules/3.12.38-44-default /.snapshots/707/snapshot/lib/modules/3.12.39-47-default Doing a pivot_root-ish rollback to 707 via "snapper pivot-rollback 707" would lead to a broken system, as modules would not be found anymore -- beyond other potential issues, which I have not considered yet. In other words: to be effective, a rollback of the root filesystem must be finalized with a reboot. That said, for the future we might think about "forward" rolling without a reboot. That could work without a reboot, if there is an entity which controls the environment and the actions (e.g. the ZYpp stack). What do you think? So long - MgE -- Matthias G. Eckermann - Senior Product Manager SUSE® Linux Enterprise SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org