Garuda Assistant Testing - Round 2

[dr460nf1r3]

@dalto

snapper can no longer see the snapshots

Thats what I noticed as well as the tab was empty. Is there any way to get the labels also displayed on the always present tab? (eg. store them in a list or something, no idea if thats hard to implement )

[dalto]

@dr460nf1r3

Is there any way to get the labels also displayed on the always present tab? (eg. store them in a list or something, no idea if thats hard to implement )

It wouldn’t be easy. I would either have to manually find and parse the snapper metadata or perhaps create a dummy config and try to trick snapper to providing the data.

[dalto]

Changes pushed, should be in the next build.

EDIT: and, yes....my test machine is still in German

[TilliDie]

You are currenly booted into snapshot /@/xxxxxxx /xxxxx would sound better

[dalto]

[alexjp]

ok, so I finally made my backups and played with snapper and garuda assistant. guess nobody waited for me
good news was that backups weren't needed, but now I have a borgmatic config and backup done for garuda

so , my notes:

• when enabling snapper timeline and snapper cleanup there is not feedback when clicking apply. ( some feedback like when changing snapper configurations would be nice )

• what is snapper boot enabled ? ( its creating a new snapshot at boot ? maybe a hint or more info ? )

• name of the snapshots on the grub : maybe just like normal instead of kernel + initramfs + microcode ( and fallback not be first )

• when restoring, the window on garuda assistant should show the info of the snapshot: data + comment
  ( also saying that you can click no and restore it later on the "snapper tab" )

• why can we only restore when booting off a snapshot, when in that mode we can restore which snapshot we want ? for example, booting off snapshot 5 can restore to snapshot 3 ( if one clicks no and then select snapshot 3 on restore ).

final note: I will have to check on my opensuse backup, but I think this isn't the method that opensuse uses. But .... its better. Its awesomely better, since it doesn't have the only issue I have with opensuse snapper -> its through manipulation of the root btrfs subvolume default. ( I will have to check, because maybe they only do this for transactional/readonly roots ).

After final note: maybe you can include checks to make sure than when enabling snapper, the right packages are installed and grub-btrfs.path is correct. I was following your instructions, but maybe it would be good to check it for anyone just enabling it without having instructions.

All in all .... congratulations, you win the internet this weekend !

[dalto]

@alexjp

when enabling snapper timeline and snapper cleanup there is not feedback when clicking apply. ( some feedback like when changing snapper configurations would be nice )

Oops, I inadvertently removed the feedback there. I can fix that.

@alexjp

what is snapper boot enabled ? ( its creating a new snapshot at boot ? maybe a hint or more info ? )

It enables snapper-boot.timer which takes snapshots at each boot.

@alexjp

name of the snapshots on the grub : maybe just like normal instead of kernel + initramfs + microcode ( and fallback not be first )

This is managed by grub-btrfs, not the assistant.

@alexjp

when restoring, the window on garuda assistant should show the info of the snapshot: data + comment
( also saying that you can click no and restore it later on the “snapper tab” )

See above, when booted off of a snapshot, that info isn’t available.

@alexjp

why can we only restore when booting off a snapshot, when in that mode we can restore which snapshot we want ? for example, booting off snapshot 5 can restore to snapshot 3 ( if one clicks no and then select snapshot 3 on restore ).

Because you can’t restore a snapshot to a mounted volume. Technically speaking, it isn’t only when you are booted off a snapshot. If you booted off the ISO you could also restore any snapshot.

@alexjp

After final note: maybe you can include checks to make sure than when enabling snapper, the right packages are installed and grub-btrfs.path is correct. I was following your instructions, but maybe it would be good to check it for anyone just enabling it without having instructions.

The plan is to create a separate package that does all this.

[alexjp]

thanks

just to note, i was only nitpicking, because it works awesome. I think the only issues might be in terms of "usuability", meaning people who never used either btrfs or snapper and are trying the first time.

but really, congrats dalto , sorry for nitpicking ! as you can see in my introductory : Greetings from new vm user , i mentioned that I preferred snapper to timeshift.
so ...a week later you appear with the solution I am very impressed ! if you wanted to impress, you did it !

[dalto]

@alexjp

just to note, i was only nitpicking, because it works awesome. I think the only issues might be in terms of “usuability”, meaning people who never used either btrfs or snapper and are trying the first time.

No, I appreciate the feedback. I want it to be as usable as possible.

I tried the idea of creating a dummy config when booting off a snapshot but it doesn’t work because it is read only.

[alexjp]

@dalto

I tried the idea of creating a dummy config when booting off a snapshot but it doesn’t work because it is read only.

yeah, the opensuse way its just a matter of changing the default root and marking the snapshot as rw. but i really don’t like that, especially if one has alot of subvolumes and “roots” ( other distros or editions for example ).

one idea that might solve all this “restoring thing” is … the garuda live iso’s have installed a restore garuda assistant.

So … imagine that dunno how but user can’t boot to a snapshot that works and reaches garuda assistant ( maybe because being RO or dunno ).
So he just boots the garuda live usb and does the restoring there. ( this is a sure way to work, but maybe complicated with chroot’s involved, depending on the details of snapper ).

[dalto]

@alexjp

So … imagine that dunno how but user can’t boot to a snapshot that works and reaches garuda assistant ( maybe because being RO or dunno ).

It works even with ro snapshots. You will get some minor errors but nothing that stops you stop from running garuda assistant or restoring a snapshot.

@alexjp

So he just boots the garuda live usb and does the restoring there. ( this is a sure way to work, but maybe complicated with chroot’s involved, depending on the details of snapper ).

No chroot is needed to restore a snapshot.

[TNE]

@dalto

I tried the idea of creating a dummy config when booting off a snapshot but it doesn’t work because it is read only.

What about creating a bind-mount to a file in /tmp or similar? Would that work?

[dalto]

@TNE

Would that work?

No. Snapper needs it to be at /.snapshots and you can’t symlink or create a directory to bind mount to because the filesystem is read-only.

[alexjp]

@dalto

It works even with ro snapshots. You will get some minor errors but nothing that stops you stop from running garuda assistant or restoring a snapshot.

yeah, it worked with kde and sddm ( although sddm gave an error ). but i haven’t tested with gnome or xfce or etc.

anyway my idea of the live iso being able to do restores would be a great failsafe, but sounds like i am already complicating stuff. sorry, i am a complicated person!

I will stop now and just say something If I see an error.

[dalto]

@alexjp

anyway my idea of the live iso being able to do restores would be a great failsafe, but sounds like i am already complicating stuff. sorry, i am a complicated person!

Err…did you my response to you earlier?

@dalto

If you booted off the ISO you could also restore any snapshot.

[alexjp]

ohh I can do that already in an ISO with garuda assistant git ?

btw I was doing more inspections, what happens to the "pre restore root", the one in space before I do a restore ( for example, mine created a @183833591 ). Will this be cleaned eventually ?

[dalto]

@alexjp

ohh I can do that already in an ISO with garuda assistant git ?

Yes. As long as you mount the btrfs partition(either the root one of the subvolumes) you will be able to.

@alexjp

Will this be cleaned eventually ?

The idea is that you would delete it if you don’t want it. It seems like a bad idea to autoremove them.

[alexjp]

@dalto

Yes. As long as you mount the btrfs partition(either the root one of the subvolumes) you will be able to.

awesome … i will test that later on ! that is awesome ! the word impressed don’t carry the full meaning of how much impressed I am

@dalto

The idea is that you would delete it if you don’t want it. It seems like a bad idea to autoremove them.

yeah, autoremove would be bad ideia, I agree. Maybe a tab of “backed up btrfs backups without cleaning timers” ? and the name being “@_pre_restore_183833591” instead of just “@183833591” ?

Sorry to keep asking you more and more and more. Its great the way it is now ! again, this is minor nitpicking for “new users” ( I am getting out of ideas to nitpick ).

[dalto]

I am going to look into seeing how slow it is to manually load the xml files for all the root snapshots to populate the snapper screen for root when booted off a snapshot.

@alexjp

Maybe a tab of “backed up btrfs backups without cleaning timers” ?

On the subvolume screen if you uncheck snapshots they should be pretty obvious. I could make that box unchecked by default.

@alexjp

and the name being “@_pre_restore_183833591” instead of just “@183833591” ?

Sure, they can be renamed. Maybe restore_backup_@_183833591

[alexjp]

@dalto

Sure, they can be renamed. Maybe restore_backup_@_183833591

perfect! this enough is good so that going to the subvolume tab one sees that it should be cleaned up if the restore was really intended and the previous root unwanted!

I am done! … I dunno what more to do!