On Fri 25 Oct 2024 at 23:50:05 (-0400), Felix Miata wrote: > David Wright composed on 2024-10-25 14:08 (UTC-0500): > > On Fri 25 Oct 2024 at 13:51:06 (-0400), Felix Miata wrote: > > >> Manual editing of /boot/grub/grub.cfg does not persist. Every kernel > >> addition or > >> removal causes its regeneration anew based upon the content of > >> /etc/default/grub > >> and the regeneration script(s), same as running grub-mkconfig. > > > FTR, editing the Grub menu itself is, of course, totally ephemeral. > > Type whatever you like, boot from it, and the edits are gone for good. > > > But editing /boot/grub/grub.cfg does persist as long as > > Therein lies the difference between my word collection and yours - as long > as. It > persists, but only until some _inevitable_ event occurs, as we both described: > > > that particular grub.cfg is not reconfigured with > > grub-mkconfig/update-grub, which is done by kernel upgrades, > > and, of course, the very occasional Grub upgrades. > > Just a little editing of my text produces an equivalent result. Change > > does not persist. Every kernel addition or removal… > to > persists only until kernel addition or removal… > > and what I wrote is equivalent to what you wrote.
I felt "does not persist" was too emphatic. Although kernel upgrades etc. are kind of inevitable, they are (or should be) active events, which take place when the sysadmin decides¹, and I felt that your words made it sound more passively driven by "external" events. > > I postprocess my grub.cfg files as a matter of routine, mainly > > to convert UUIDs to LABELs, but also to uniquify them, if I may > > use that word. > > Such postprocess is pointless here. The bulk of my custom.cfg entries use > LABELS. > None use UUIDs. And, grub.cfg entries are ignored, displayed onscreen as > available > selections only after scrolling past 20-30 or more custom.cfg entries: Sure, I would expect you to write custom.cfg entries exactly as you want them to appear. OTOH my postprocessing operates on the entries generated by Grub's scripts. Many years ago, I looked at the scripts to see whether I could make them produce LABELs instead of UUIDs, but it didn't appear to be trivial, so I just generate a little lookup array from the E:ID_FS_UUID and E:ID_FS_LABEL values in /run/udev/data/b*. ¹ Obviously I'm assuming no unattended upgrades and other such horrors. Cheers, David.
