On Fri 08 Jul 2016 at 19:19:00 (+0100), Brian wrote: > On Thu 07 Jul 2016 at 23:34:11 -0400, Gary Dale wrote: > > On 07/07/16 05:12 PM, Brian wrote: > > >On Thu 07 Jul 2016 at 15:18:05 -0400, Gary Dale wrote: > > >>On 07/07/16 02:55 PM, David Wright wrote: > > >>>On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote: > > >>>>The big selling feature of Grub over Lilo was that it didn't need to > > >>>>updated each time you changed something. That fell by the wayside > > >>>>with Grub 2. Now the big selling feature is that it works with more > > >>>>than just Linux. > > >>>I guess I don't know what you mean by "update". > > >>>If I change the contents of grub.cfg, the effect is immediate: > > >>>the changes will be seen at the next boot. I don't do anything more. > > >>However the second line of grub.cfg says "DO NOT EDIT THIS FILE". If you > > >>do > > >>edit it, the changes will be overwritten the next time a debian upgrade > > >>automatically regenerates it. The only method for preserving your changes > > >>is > > >>to update the grub templates then run update-grub. > > >No it's not. dpkg-divert. That's sufficient to search the list archives > > >for something which has been mentioned a few times but has passed you by. > > > > A lot of trouble for something that can be avoided if you just edit the > > correct files in the first place. > > Let's see. You write your own grub.cfg or edit the existing one. You > want to preserve your file from being changed so you use a *one line > command* to ensure that. But this one line command is a lot of trouble. > A one line command is onerous? > > It is much easier to edit the unspecified "correct files" to stop any > changes to grub.cfg at a Debian upgrade which attempts to regenerate > it? One lives and learns.
I *think* I've worked out what this rant is all about: the replacement of /boot/grub/menu.lst in old Grub by /boot/grub/grub.cfg in Grub2. So under the old system, you generated or wrote menu.lst and then you could edit it to your heart's content. Under the new system, grub.cfg is always (re)built from a set of scripts and some preference data in /etc/default/grub, unless you've protected it with your one-line command. In case of the latter, it behaves just like menu.lst did: if you edit it, the effect is immediate (and unlike lilo). Somebody else then chimed in about how the partition numbering scheme has been screwed (more like corrected IMHO) which meant people were scratching their heads over "Is it (hd1,0) or (hd0,1)" when the world has moved on to using UUID/LABELs instead if worrying about whether the kernel happened to discover their disks in the right order. Cheers, David.
