Re: reasons to ditch LILO before upgrading to jessie?
On Fri 08 Jul 2016 at 18:13:01 -0400, Gary Dale wrote:
> >>On 08/07/16 02:19 PM, Brian wrote:
> >
> >If you have some way of easily adjusting files in /etc/grub.d to the
> >needs of a user I wish you would say.
> So that's the problem. You never took the time to RTFM. See
> https://help.ubuntu.com/community/Grub2/Setup#File_Structure
That page, no matter how informative it may be, is not the manual. My
comment was intended to elicit some specific technical advice on how to
adjust an /etc/grub.d file(s) to perform a particular task. Something
like the topic in
https://lists.debian.org/debian-user/2016/07/msg00278.html
Using labels in a hand written grub.cfg is a snap. Stopping it being
overwritten is another snap. Perhaps altering file X in grub.d is just
as easy and unstressful.
Maybe one day I will read 'pinfo grub'. :)
> >>same change either way but the grub template file won't get clobbered so
> >>there is no need to run dpkg-divert.
> >It's not the same change. ("grub template file". What is that? There
> >isn't one as far as I can see).
> Again, RTFM. There are lots of files for you to tinker with in /etc/grub.d.
> You can even add your own and it's guaranteed not be tampered with by any
> updates.
So there are. Users should stay away from them (40_custom excepted)
unless they know what they are doing.
> >>Moreover, you don't need to update a system manual to note that you are
> >>diverting a package. You just need to note that a single file is not the
> >>package maintainers default - something you have to do either way.
> >Diverting is a Debian thing. The GRUB manual would never mention it.
> >
> No, but you do have to document each system that you are running. If you are
> doing anything that is not standard, it has to be recorded so that the next
> person (or you 3 months later) will know that you've done it.
>
> I gather from your comment that you aren't doing this. That's asking for
> trouble, especially if you are running custom configurations and protecting
> them with diversions. Complexity added onto complexity without documentation
> is a good recipe for disaster.
I cannot argue with that.
Reply to: