Snapper - current snapshot

I wish to determine whether the system has now booted from the latest snapshot (today’s or the “current snapshot” – #274) or a prior one, as I began the rollback process by selecting “Start Bootloader from a read-only snapshot” on the bootloader splash screen, selecting snapshot #246 from yesterday. For whatever reason, the process stopped on login.

I believe I am back to where I started (at snapshot #274), but I can’t find anything in /var/log/snapper.log or var/log/boot.log, or in the files in /boot (nothing there has today’s date).

And I am unable to find a shell command that would reveal that information. I looked at the man pages for snapper, but other than list -a, which yields #0 and the label “current,” it does not tell me when the snapshot was created or anything else.

Please let me know where I may look for this. Thanks.

You may fine the SUSE Linux Enterprise (SLE) documentation useful when it
comes to this:

https://www.suse.com/documentation/sled-12/book_sle_admin/data/sec_snapper_snapshot-boot.html

This is not a SLED or SLES forum, of course, but docs there may be better
and should be pretty close.

Also, to see dates of snapshots, ‘snapper list’ should show you what you
need (executed as ‘root’).


Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

Thanks for the suggestion. I am familiar with the documentation for SuSE Enterprise products, which did not provide the answer I am seeking, but coincidentally I found something even better.

There is now a fairly comprehensive set of guides, etc. for the openSuSE versions, including Leap 42.1. With regard to snapper specifically, see https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.snapper.html, which from the reference guids (https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/index.html). Links to all of the 42.1 documentation may be found at https://doc.opensuse.org/. Although a solution may be in there somewhere, I did not find anything specific to my inquiry.

I’m still optimistic someone may know of a simple way to determine the nature of the “current” snapshot.

Thanks again.

Hello

The only way I have been able to determine the current snapshot booted from is by looking at the kernel parameters of the booted system

cat /proc/cmdline

BOOT_IMAGE=/boot/vmlinuz-3.12.59-60.41-default root=UUID=8b7a6398-4ddb-4f8f-8e22-6cc83f1151b5 rootflags=subvol=/@/.snapshots/29/snapshot showopts

This tells me I am booted from snapshot #29.

Hopefully this is what you are looking for and it is helpful.

gaubbs -

Thanks. That is the information I’m looking for, but when I ran the command, no snapshot!

linux-5:~ # cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.1.26-21-default root=UUID=67b9d30a-3413-43fa-97ca-4a6e257e8521 resume=/dev/disk/by-uuid/c7dbed1d-6fb7-489b-8737-bd866c0f915d splash=silent quiet showopts
linux-5:~ #

I have looked at man pages, searched a bit in various logs (e.g., boot, kernel) and on the web, but I am unable to obtain an output similar to what you show. Either there is some option I must enter with command or perhaps the information doesn’t exist on this system. I tried the command on two other 42.1 systems and obtained similar results.

Thanks again.

/proc is a virtual directory and shows the processes running in the system it does not exist on the drive only a running system. That virtual file should be there

gogalthorp -

Thank you. But when I went there earlier, I found the same code:

BOOT_IMAGE=/boot/vmlinuz-4.1.26-21-default root=UUID=67b9d30a-3413-43fa-97ca-4a6e257e8521 resume=/dev/disk/by-uuid/c7dbed1d-6fb7-489b-8737-bd866c0f915d splash=silent quiet showopts

As one might expect, that also shows up under the Kernel parameters tab in the bootloader panel in YaST.

Did you boot from a snapshot??

gogalthorp -

Good question. As I began this thread, I don’t believe I did successfully boot from a snapshot, i.e., an earlier snapshot, and am trying to confirm that. Perhaps the absence of a reference to rootflags and snapshots indicates that the process was in fact not completed.

Also, examining grub.cfg, as well as a cursory glance at the contents of the /.snapshots directory, doesn’t indicate a change in the booting on the date in question (at least to me).

I’m not sure what you might look for to verify you’re actually booting using a particular snapshot (I assume that would be complicated by what the actual differences might be from one snapshot to another) but…

You should know that any time you roll back to a historical shapshot, you’re actually incrementing (adding another snapshot). There is no such thing as destructively going back in time, snapshotting always moves forward, adding the newly rolled back to existing history. Another way to think of snapshot history is that you can move forwards and backwards through your snapshot history without limitation because nothing is ever lost.

Maybe snapshots should support a custom field for your own comments and notes…

In general though I personally keep track of snapshots roughtly by their dates and when I run an install or uninstall (a snapshot is automatically created for every install/uninstall).

TSU

tsu2 -

Thanks. What I’m really looking for is a log record or some other indication showing what occurred on July 6th, namely an attempt to boot from an earlier snapshot (whichever one). But as stated, the process appears to have aborted. When I rebooted, the system may have reverted to the same point in time (and configuration) as when I first started up the pc. If so, I would not expect any record or other indication of a rollback attempt.

Perhaps there is no record in the logs, as the subvolume /var/log was also mounted read-only, when you invoked # snapper rollback. I cannot test here, because my installation is in a virtual partition of LVM, where booting read-only snapshots are not supported.

snapper rollback creates a read-write snapshot and sets it as the default subvolume. If there was no error message, then it would have succeeded.

Best regards,
Bequimão

This means you are not booted from a snapshot and are looking at ‘current’. Same output here when not booted from a snapshot.

Booted from ‘current’

> cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.12.59-60.41-default root=UUID=27b40815-72b0-43e6-8160-0ea0a5f8821c showopts

Booted from snapshot 24

> cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.12.59-60.41-default root=UUID=27b40815-72b0-43e6-8160-0ea0a5f8821c rootflags=subvol=/@/.snapshots/24/snapshot showopts

Booting from a snapshot will give you a system with a read only file system anyway. You will know if you are booted from a snapshot.

gaubbs -

Thanks. That’s what I am guessing to be the case, but I haven’t found any documentation to back up my supposition. I do have some other indications that the earlier configuration was not booted, but again I was hoping to see a log of what transpired or some other file confirming that I re-booted from the most recent snapshot.

If you have persistent journal logs you can go back and see how each boot looked. You will see the kernel parameters in the log

journalctl --boot=-1


Jul 09 21:46:39 darkstar kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-3.12.59-60.41-default root=UUID=27b40815-72b0-43e6-8160-0ea0a5f8821c rootflags=subvol=/@/.snapshots/24/snapshot showopts

Here is the output from a ‘current’ boot

journalctl


Jul 09 20:22:40 darkstar kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-3.12.59-60.41-default root=UUID=27b40815-72b0-43e6-8160-0ea0a5f8821c showopts

Unfortunately persistent journal logs need to be enabled. If you did not have them enabled you probably can’t use this.

gaubbs -

Thanks. That is indeed what I was seeking from the outset. And the journal contains the entire history from the initial installation date, which includes July 6th - the date on which I attempted to boot to an earlier snapshot.

Curiously, I did find two entries that reference a snapshot, one preceded by “Command line” and the other “Kernel command line”:

Jul 06 15:06:49 linux-5 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.1.26-21-default root=UUID=67b9d30a-3413-43fa-97ca-4a6e257e8521 rootflags=subvol=/@/.snapshots/237/snapshot resume=/dev/disk/by-uuid/c7dbed1d-6fb7-489b-8737-bd866c0f915d splash=silent quiet showopts
. . .
Jul 06 15:06:49 linux-5 kernel: Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.1.26-21-default root=UUID=67b9d30a-3413-43fa-97ca-4a6e257e8521 rootflags=subvol=/@/.snapshots/237/snapshot resume=/dev/disk/by-uuid/c7dbed1d-6fb7-489b-8737-bd866c0f915d splash=silent quiet showopts

But the UUIDs are the same as the entries as today’s (UUID=67b9…e8521 and uuid c7dbed…915d):

Sun Jul 10 10:35:01 EDT 2016
linux-5:~ # cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.1.26-21-default root=UUID=67b9d30a-3413-43fa-97ca-4a6e257e8521 resume=/dev/disk/by-uuid/c7dbed1d-6fb7-489b-8737-bd866c0f915d splash=silent quiet showopts
linux-5:~ #

And the journal entry for the very first boot also shows the same UUIDs:

Jun 18 17:42:09 linux-rj13 kernel: Command line: BOOT_IMAGE=/@/.snapshots/1/snapshot/boot/vmlinuz-4.1.21-14-default root=UUID=67b9d30a-3413-43fa-97ca-4a6e257e8521 resume=/dev/disk/by-uuid/c7dbed1d-6fb7-489b-8737-bd866c0f915d splash=silent quiet showopts

Is the reference to snapshot 237 on July 6th confirmation that I continued to boot the current or latest snapshot or configuration notwithstanding my attempt to boot to an earlier one?

The UUID is the uuid of your root file system. It will be the same regardless of what snapshot you boot from.

On July 6th you booted from snapshot 237. You did not boot from ‘current’ which is not a snapshot. Whatever snapshot 237 was at the time (latest snapshot or a previous one, but it is a snapshot).

gaubbs -

Thank you. The entry would lead one to suspect that’s the case. But here, I never logged into a terminal following the selection of snapshot #247 and did not enter the command “snapper rollback,” and thus never completed the rollback process as I understand it. Further, when I did an rpm query on July 8th, two days after attempt to rollback, all of the YaST updates that occurred after the earlier snapshot were present (they were not subsequently downloaded again). I recognize that a rollback may not remove those items, but I don’t know for certain.

When you roll back there are 2 more snapshots that get created and the default subvolume is set to the read-write one.

snapper rollback

Creating read-only snapshot of default subvolume. (Snapshot 25.)
Creating read-write snapshot of current subvolume. (Snapshot 26.)
Setting default subvolume to snapshot 26.

What you are running from currently you can get with

btrfs subvolume get-default /

ID 300 gen 469 top level 258 path @/.snapshots/26/snapshot

This should complete the picture.

gaubbs -

Here is the command and output:

linux-5:~ # btrfs subvolume get-default /
ID 259 gen 23083 top level 258 path @/.snapshots/1/snapshot

What does the number “1” mean in this context?