search

coreos / rpm-ostree

⚛📦 Hybrid image/package system with atomic upgrades and package layering
https://coreos.github.io/rpm-ostree
Other
849 stars 191 forks source link

Differentiate grub entries #1239

Open matthiasclasen opened 6 years ago

matthiasclasen commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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:

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 commented 6 years ago

Yet another idea: let me provide a label to differentiate

jlebon commented 5 years ago

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 commented 5 years ago

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

jlebon commented 4 years ago

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 commented 1 year ago

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.