Differentiate grub entries

[matthiasclasen]

When I use package layering, rpm-ostree creates a second grub entry for the images with the layered packages. That is very useful in principle. But sadly, both entries have identical labels,

Fedora 27 (Workstation Edition) 27.68 (ostree)

on my system. It would be enough to add a hint that lets me find out which one is the one 'with the layer', say

Fedora 27 (Workstation Edition) 27.68 (ostree+layer)

[cgwalters]

Well...we generate a new deployment (bootloader entry) for any change, which could include just say rpm-ostree initramfs --enable or rpm-ostree override remove docker....
Or just plain rpm-ostree upgrade.

We also currently don't retain a bootloader entry for the "base tree" by default.

So the initial state is unusual in doing this transition, after that we'll keep a rollback around that was your previous booted.

I'm not entirely sure what the +layer would bring then as you'd quite commonly see +layer in both.

[matthiasclasen]

Right. I don't care about the details of the label. What's important is that they are not identical and I can figure out which one I want...

[jlebon]

Yeah, that's a good point, and something I've also desired in the past as well. OTOH, it'd be pretty messy to condense what a layer changes into a convenient number of characters minimal enough for the GRUB2 entry.

Random ideas:

• just add the first e.g. 7 chars of the layered checksum
• append a +$N to the Version string in layered commits, where we auto-increment $N

In both cases, the user needs to know which corresponds to which (e.g. "oh yeah, 27.42+5 is the deployment where I added tmux").

[matthiasclasen]

Yet another idea: let me provide a label to differentiate

[jlebon]

Or +N-M where N is the number of layered packages and M the number of removed packages? (Both skipped if they're 0 of course).

[fbruetting]

If you unlayer one package and layer another one, you still can’t differentiate.

[jlebon]

Yet another idea: let me provide a label to differentiate

The problem with that is that it's not sustainable as you keep updating and doing other operations.

The easiest solution for this is to just add the timestamp of when it was deployed, e.g.:

Fedora 30.20190922.0 (2019-09-30T00:45:54Z) (Workstation Edition) (ostree)

Then it's obvious which one was deployed in which order even if one does rollback. And timestamps are more meaningful to humans than any cryptic scheme.

Aside: I think we should get rid of the (ostree) part once we actually have Silverblue branding there; it's redundant. And then instead of (Workstation Edition), just making it part of the pretty name, e.g.:

Fedora Silverblue 30.20190922.0 (2019-09-30T00:45:54Z)

[glidingthrough]

Including in the GRUB label whether something is pinned or not, and at what pin location (e.g. pin 0, pin 1) would be useful.

I also agree with the OP that custom labels would be useful, but specifically for pinned deployments - e.g. 'New Install', 'Pre-rebasing 37 to 38', etc. Optional, of course, as some users wouldn't use this feature, but would make the GRUB entries much easier to navigate for those that do.

[westurner]

• support configuring host to retain more than two deployments #577