Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #169754 > unrolled thread
| Started by | Giovanni Gigante <giov-debian@deepsky.it> |
|---|---|
| First post | 2016-07-05 15:40 +0200 |
| Last post | 2016-07-08 06:10 +0200 |
| Articles | 20 on this page of 66 — 19 participants |
Back to article view | Back to linux.debian.user
reasons to ditch LILO before upgrading to jessie? Giovanni Gigante <giov-debian@deepsky.it> - 2016-07-05 15:40 +0200
Re: reasons to ditch LILO before upgrading to jessie? Don Armstrong <don@debian.org> - 2016-07-05 19:20 +0200
Re: reasons to ditch LILO before upgrading to jessie? Marc Shapiro <marcnshap@gmail.com> - 2016-07-05 21:00 +0200
Re: reasons to ditch LILO before upgrading to jessie? Don Armstrong <don@debian.org> - 2016-07-05 23:50 +0200
Re: reasons to ditch LILO before upgrading to jessie? Jonathan Dowland <jmtd@debian.org> - 2016-07-06 11:00 +0200
Re: reasons to ditch LILO before upgrading to jessie? Don Armstrong <don@debian.org> - 2016-07-06 21:30 +0200
Re: reasons to ditch LILO before upgrading to jessie? <tomas@tuxteam.de> - 2016-07-07 08:40 +0200
Re: reasons to ditch LILO before upgrading to jessie? Lisi Reisz <lisi.reisz@gmail.com> - 2016-07-07 11:40 +0200
Re: reasons to ditch LILO before upgrading to jessie? Brian <ad44@cityscape.co.uk> - 2016-07-07 12:40 +0200
Re: reasons to ditch LILO before upgrading to jessie? <tomas@tuxteam.de> - 2016-07-07 12:50 +0200
Re: reasons to ditch LILO before upgrading to jessie? Brian <ad44@cityscape.co.uk> - 2016-07-07 13:30 +0200
Re: reasons to ditch LILO before upgrading to jessie? Giovanni Gigante <giovanni.gigante@deepsky.it> - 2016-07-07 17:20 +0200
Re: reasons to ditch LILO before upgrading to jessie? Stephen Powell <zlinuxman@fastmail.com> - 2016-07-08 02:40 +0200
Re: reasons to ditch LILO before upgrading to jessie? Felix Miata <mrmazda@earthlink.net> - 2016-07-08 03:00 +0200
Re: reasons to ditch LILO before upgrading to jessie? Stephen Powell <zlinuxman@fastmail.com> - 2016-07-09 15:10 +0200
Re: reasons to ditch LILO before upgrading to jessie? Felix Miata <mrmazda@earthlink.net> - 2016-07-09 17:00 +0200
Re: reasons to ditch LILO before upgrading to jessie? Stephen Powell <zlinuxman@fastmail.com> - 2016-07-09 19:20 +0200
Re: reasons to ditch LILO before upgrading to jessie? Brian <ad44@cityscape.co.uk> - 2016-07-09 22:10 +0200
Re: reasons to ditch LILO before upgrading to jessie? Erwan David <erwan@rail.eu.org> - 2016-07-09 22:10 +0200
Re: reasons to ditch LILO before upgrading to jessie? Felix Miata <mrmazda@earthlink.net> - 2016-07-09 22:40 +0200
Re: reasons to ditch LILO before upgrading to jessie? Brian <ad44@cityscape.co.uk> - 2016-07-10 00:20 +0200
Re: reasons to ditch LILO before upgrading to jessie? <tomas@tuxteam.de> - 2016-07-10 10:40 +0200
Re: reasons to ditch LILO before upgrading to jessie? Brian <ad44@cityscape.co.uk> - 2016-07-10 13:20 +0200
Re: reasons to ditch LILO before upgrading to jessie? Stephen Powell <zlinuxman@fastmail.com> - 2016-07-09 22:50 +0200
Re: reasons to ditch LILO before upgrading to jessie? Brian <ad44@cityscape.co.uk> - 2016-07-10 00:30 +0200
Re: reasons to ditch LILO before upgrading to jessie? Stephen Powell <zlinuxman@fastmail.com> - 2016-07-10 04:20 +0200
Re: reasons to ditch LILO before upgrading to jessie? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-07-10 10:20 +0200
Re: reasons to ditch LILO before upgrading to jessie? Stephen Powell <zlinuxman@fastmail.com> - 2016-07-10 14:10 +0200
Re: reasons to ditch LILO before upgrading to jessie? Felix Miata <mrmazda@earthlink.net> - 2016-07-10 00:50 +0200
Re: reasons to ditch LILO before upgrading to jessie? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-07-10 09:50 +0200
Re: reasons to ditch LILO before upgrading to jessie? Felix Miata <mrmazda@earthlink.net> - 2016-07-09 22:40 +0200
Re: reasons to ditch LILO before upgrading to jessie? Stephen Powell <zlinuxman@fastmail.com> - 2016-07-09 23:10 +0200
Re: reasons to ditch LILO before upgrading to jessie? Richard Owlett <rowlett@cloud85.net> - 2016-07-10 15:40 +0200
Re: reasons to ditch LILO before upgrading to jessie? Brian <ad44@cityscape.co.uk> - 2016-07-10 16:30 +0200
Re: reasons to ditch LILO before upgrading to jessie? Joel Roth <joelz@pobox.com> - 2016-07-10 08:40 +0200
UEFI bootloaders (was: Re: reasons to ditch LILO before upgrading to jessie?) Joel Roth <joelz@pobox.com> - 2016-07-10 23:20 +0200
Re: UEFI bootloaders (was: Re: reasons to ditch LILO before upgrading to jessie?) "Byung-Hee HWANG (황병희)" <soyeomul@doraji.xyz> - 2016-07-11 01:20 +0200
Re: reasons to ditch LILO before upgrading to jessie? David Wright <deblis@lionunicorn.co.uk> - 2016-07-07 20:30 +0200
Re: reasons to ditch LILO before upgrading to jessie? Gary Dale <garydale@torfree.net> - 2016-07-07 20:50 +0200
Re: reasons to ditch LILO before upgrading to jessie? David Wright <deblis@lionunicorn.co.uk> - 2016-07-07 21:00 +0200
Re: reasons to ditch LILO before upgrading to jessie? Gary Dale <garydale@torfree.net> - 2016-07-07 21:20 +0200
Re: reasons to ditch LILO before upgrading to jessie? David Wright <deblis@lionunicorn.co.uk> - 2016-07-07 21:40 +0200
Re: reasons to ditch LILO before upgrading to jessie? Brian <ad44@cityscape.co.uk> - 2016-07-07 23:20 +0200
Re: reasons to ditch LILO before upgrading to jessie? Gary Dale <garydale@torfree.net> - 2016-07-08 05:40 +0200
Re: reasons to ditch LILO before upgrading to jessie? Brian <ad44@cityscape.co.uk> - 2016-07-08 20:20 +0200
Re: reasons to ditch LILO before upgrading to jessie? Gary Dale <garydale@torfree.net> - 2016-07-08 21:10 +0200
Re: reasons to ditch LILO before upgrading to jessie? Brian <ad44@cityscape.co.uk> - 2016-07-08 22:00 +0200
Re: reasons to ditch LILO before upgrading to jessie? Gary Dale <garydale@torfree.net> - 2016-07-09 00:20 +0200
Re: reasons to ditch LILO before upgrading to jessie? Brian <ad44@cityscape.co.uk> - 2016-07-09 01:10 +0200
Re: reasons to ditch LILO before upgrading to jessie? Gary Dale <garydale@torfree.net> - 2016-07-09 05:30 +0200
Re: reasons to ditch LILO before upgrading to jessie? David Wright <deblis@lionunicorn.co.uk> - 2016-07-08 21:30 +0200
Re: reasons to ditch LILO before upgrading to jessie? Brian <ad44@cityscape.co.uk> - 2016-07-08 22:20 +0200
Re: reasons to ditch LILO before upgrading to jessie? David Wright <deblis@lionunicorn.co.uk> - 2016-07-09 00:10 +0200
Re: reasons to ditch LILO before upgrading to jessie? Brian <ad44@cityscape.co.uk> - 2016-07-09 00:30 +0200
Re: reasons to ditch LILO before upgrading to jessie? Michael Milliman <michael.e.milliman@gmail.com> - 2016-07-07 21:40 +0200
Re: reasons to ditch LILO before upgrading to jessie? rhkramer@gmail.com - 2016-07-08 00:50 +0200
Re: reasons to ditch LILO before upgrading to jessie? Michael Milliman <michael.e.milliman@gmail.com> - 2016-07-08 02:00 +0200
Re: reasons to ditch LILO before upgrading to jessie? Michael Milliman <michael.e.milliman@gmail.com> - 2016-07-08 02:00 +0200
Re: enumerating with Grub* (was: reasons to ditch LILO before...) Felix Miata <mrmazda@earthlink.net> - 2016-07-08 02:10 +0200
Re: enumerating with Grub* (was: reasons to ditch LILO before...) David Wright <deblis@lionunicorn.co.uk> - 2016-07-08 03:10 +0200
Re: enumerating with Grub* (was: reasons to ditch LILO before...) rhkramer@gmail.com - 2016-07-08 04:20 +0200
Re: enumerating with Grub* Felix Miata <mrmazda@earthlink.net> - 2016-07-08 05:00 +0200
Re: enumerating with Grub* David Wright <deblis@lionunicorn.co.uk> - 2016-07-08 07:20 +0200
Re: enumerating with Grub* Felix Miata <mrmazda@earthlink.net> - 2016-07-08 07:50 +0200
Re: enumerating with Grub* David Wright <deblis@lionunicorn.co.uk> - 2016-07-08 16:50 +0200
Re: reasons to ditch LILO before upgrading to jessie? Felix Miata <mrmazda@earthlink.net> - 2016-07-08 06:10 +0200
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Gary Dale <garydale@torfree.net> |
|---|---|
| Date | 2016-07-07 21:20 +0200 |
| Message-ID | <rSn05-2Gq-5@gated-at.bofh.it> |
| In reply to | #169846 |
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. > >> It also has a "rescue shell" that I've never been able to do >> anything useful with. When grub fails, I boot from a rescue cd >> instead. That way I get a real working environment. > Horses for courses. > > Cheers, > David. > Glad you find the grub shell useful. I've yet to encounter a boot error that it could fix.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2016-07-07 21:40 +0200 |
| Message-ID | <rSnjs-2Pm-23@gated-at.bofh.it> |
| In reply to | #169847 |
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. Well, if you want to use templates to build your grub.cfg, then you have to build it with update-grub. That's hardly surprising. If you roll your own, you don't. The reason I wrote 'I don't know what you mean by "update"' is because AIUI if you changed /etc/lilo.conf, you had/have to remember to run /sbin/lilo to reinstall the loader again. With grub, you don't. AFAICT that's the big selling feature you mentioned above, was it not? If not, what was it, and what has changed between grub 1 and 2? Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2016-07-07 23:20 +0200 |
| Message-ID | <rSoSe-3SM-5@gated-at.bofh.it> |
| In reply to | #169847 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Gary Dale <garydale@torfree.net> |
|---|---|
| Date | 2016-07-08 05:40 +0200 |
| Message-ID | <rSuNX-7F4-7@gated-at.bofh.it> |
| In reply to | #169854 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2016-07-08 20:20 +0200 |
| Message-ID | <rSIxz-8ma-15@gated-at.bofh.it> |
| In reply to | #169871 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Gary Dale <garydale@torfree.net> |
|---|---|
| Date | 2016-07-08 21:10 +0200 |
| Message-ID | <rSJjY-sh-9@gated-at.bofh.it> |
| In reply to | #169887 |
On 08/07/16 02:19 PM, 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. > Let's see then. You can edit a grub template file or grub.cfg. You make the same change either way but the grub template file won't get clobbered so there is no need to run dpkg-divert. 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.
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2016-07-08 22:00 +0200 |
| Message-ID | <rSK6m-JU-13@gated-at.bofh.it> |
| In reply to | #169892 |
On Fri 08 Jul 2016 at 15:08:21 -0400, Gary Dale wrote:
> On 08/07/16 02:19 PM, 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.
> >
> Let's see then. You can edit a grub template file or grub.cfg. You make the
No. You edit or devise a grub,cfg. GRUB template files are not involved.
They are irrelevant. You can ignore them because you are doing you own
thing. You have decided what *you* want, not what /etc/grub.d wants to
give you.
If you have some way of easily adjusting files in /etc/grub.d to the
needs of a user I wish you would say.
> 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).
> 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.
[toc] | [prev] | [next] | [standalone]
| From | Gary Dale <garydale@torfree.net> |
|---|---|
| Date | 2016-07-09 00:20 +0200 |
| Message-ID | <rSMhP-2tk-1@gated-at.bofh.it> |
| In reply to | #169896 |
On 08/07/16 03:51 PM, Brian wrote:
> On Fri 08 Jul 2016 at 15:08:21 -0400, Gary Dale wrote:
>
>> On 08/07/16 02:19 PM, 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.
>>>
>> Let's see then. You can edit a grub template file or grub.cfg. You make the
> No. You edit or devise a grub,cfg. GRUB template files are not involved.
> They are irrelevant. You can ignore them because you are doing you own
> thing. You have decided what *you* want, not what /etc/grub.d wants to
> give you.
>
> 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
>
>> 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.
>
>> 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.
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2016-07-09 01:10 +0200 |
| Message-ID | <rSN4d-318-3@gated-at.bofh.it> |
| In reply to | #169899 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Gary Dale <garydale@torfree.net> |
|---|---|
| Date | 2016-07-09 05:30 +0200 |
| Message-ID | <rSR7P-5HH-5@gated-at.bofh.it> |
| In reply to | #169901 |
On 08/07/16 07:06 PM, Brian wrote:
> 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'. :)
True enough, but it shows how much good information there is out there.
As for altering the correct files, it is just as easy and unstressful.
>
>>>> 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.
Same is true for altering any file.
>
>>>> 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.
>
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2016-07-08 21:30 +0200 |
| Message-ID | <rSJDj-zx-3@gated-at.bofh.it> |
| In reply to | #169887 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2016-07-08 22:20 +0200 |
| Message-ID | <rSKpI-181-11@gated-at.bofh.it> |
| In reply to | #169894 |
On Fri 08 Jul 2016 at 14:23:01 -0500, David Wright wrote: > 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. Was that a rant? If so, It has nothing whatsoever to do with GRUB legacy. If you want GRUB to do what you want you write your own grub,cfg. Stop moaning. Do it or file file a bug, Then stop moaning and do it.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2016-07-09 00:10 +0200 |
| Message-ID | <rSM89-2pR-17@gated-at.bofh.it> |
| In reply to | #169897 |
On Fri 08 Jul 2016 at 21:16:00 (+0100), Brian wrote: > On Fri 08 Jul 2016 at 14:23:01 -0500, David Wright wrote: > > 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. > > Was that a rant? If so, It has nothing whatsoever to do with GRUB > legacy. I was referring to the threads which started Thu, 7 Jul 2016 14:39:51 -0400 as quoted above. In them, I have argued against the view that something "fell by the wayside" in Grub2 wrt the legacy version. Sorry if you thought that I was accusing yourself of ranting. > If you want GRUB to do what you want you write your own grub,cfg. I do; unconventionally, but it suits me. > Stop moaning. Do it or file file a bug, Then stop moaning and do it. I'm the person without a complaint about Grub2, not the one moaning. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2016-07-09 00:30 +0200 |
| Message-ID | <rSMrv-2wN-3@gated-at.bofh.it> |
| In reply to | #169898 |
On Fri 08 Jul 2016 at 16:57:30 -0500, David Wright wrote: > On Fri 08 Jul 2016 at 21:16:00 (+0100), Brian wrote: > > > Stop moaning. Do it or file file a bug, Then stop moaning and do it. > > I'm the person without a complaint about Grub2, not the one moaning. Apologies. I was intending to talk in general but it looks as though my remark was directed solely at you. That wasn't my intent but I can see how it looks that way. Time to avoid controversy and try to stick to technical points. :)
[toc] | [prev] | [next] | [standalone]
| From | Michael Milliman <michael.e.milliman@gmail.com> |
|---|---|
| Date | 2016-07-07 21:40 +0200 |
| Message-ID | <rSnjs-2Pm-25@gated-at.bofh.it> |
| In reply to | #169846 |
On 07/07/2016 01: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. With LILO any time you change the configuration, you have to re-install the LILO boot loader for those changes to take effect. With Grub, you make a change to the configuration file and it is immediately available on the next boot without having to re-install the Grub boot loader. Grub understands the file systems and so can read the configuration directly, whereas LILO does not understand the file system, and so the configuration must be provided as data directly in the loader itself (hence the re-install step). > >> It also has a "rescue shell" that I've never been able to do >> anything useful with. When grub fails, I boot from a rescue cd >> instead. That way I get a real working environment. > Horses for courses. > > Cheers, > David. > -- 73's Mike, WB5VQX
[toc] | [prev] | [next] | [standalone]
| From | rhkramer@gmail.com |
|---|---|
| Date | 2016-07-08 00:50 +0200 |
| Message-ID | <rSqhk-4FB-47@gated-at.bofh.it> |
| In reply to | #169851 |
I'll take advantage of this thread to ask a question / express my frustration with grub: The thing that always frustrated me about grub is that, iirc, they counted disks / partitions different than lilo and the rest of Linux--they start counting at 1 (like Windows, iirc), and lilo and Linux start counting at 0--is that still the case? OTOH, I haven't touched either lilo or grub in a long time--I don't even know which I'm using--I installed whatever Debian 7 offered, and, since it is a single boot system, (and I haven't booted in ~85 days), I don't really have an issue. On Thursday, July 07, 2016 03:37:12 PM Michael Milliman wrote: > On 07/07/2016 01:55 PM, David Wright wrote: > > On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote:
[toc] | [prev] | [next] | [standalone]
| From | Michael Milliman <michael.e.milliman@gmail.com> |
|---|---|
| Date | 2016-07-08 02:00 +0200 |
| Message-ID | <rSrn3-5jw-1@gated-at.bofh.it> |
| In reply to | #169857 |
On 07/07/2016 05:47 PM, rhkramer@gmail.com wrote: > I'll take advantage of this thread to ask a question / express my frustration > with grub: > > The thing that always frustrated me about grub is that, iirc, they counted > disks / partitions different than lilo and the rest of Linux--they start > counting at 1 (like Windows, iirc), and lilo and Linux start counting at 0--is > that still the case? > > OTOH, I haven't touched either lilo or grub in a long time--I don't even know > which I'm using--I installed whatever Debian 7 offered, and, since it is a > single boot system, (and I haven't booted in ~85 days), I don't really have an > issue. Yes, the partitions are counted differently, and that can be a little frustrating. However, with Grub, you can refer to the partitions by label or by UUID (Grub usually defaults to using UUID) rather than drive/partition numbers, which makes it a little easier. Lilo cannot refer to the partitions in this way, so you must know what drive/partition you are referring to. This is not a big deal in many installations, however, in situations where the drive/partition number may change (e.g. usb sticks that on one boot may be /dev/sdb on one boot and /dev/sdc on another depending on how/when the bios enumerates them) this comes in very handy, as you don't have to know which drive/partition will be the root partition, you only have to know either the UUID of the partition or a label you have assigned to it, and these things don't change regardless of how/where a usb device is enumerated. > > On Thursday, July 07, 2016 03:37:12 PM Michael Milliman wrote: >> On 07/07/2016 01:55 PM, David Wright wrote: >>> On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote: -- 73's Mike, WB5VQX
[toc] | [prev] | [next] | [standalone]
| From | Michael Milliman <michael.e.milliman@gmail.com> |
|---|---|
| Date | 2016-07-08 02:00 +0200 |
| Message-ID | <rSrn4-5jw-11@gated-at.bofh.it> |
| In reply to | #169857 |
On 07/07/2016 05:47 PM, rhkramer@gmail.com wrote: > I'll take advantage of this thread to ask a question / express my frustration > with grub: > > The thing that always frustrated me about grub is that, iirc, they counted > disks / partitions different than lilo and the rest of Linux--they start > counting at 1 (like Windows, iirc), and lilo and Linux start counting at 0--is > that still the case? > > OTOH, I haven't touched either lilo or grub in a long time--I don't even know > which I'm using--I installed whatever Debian 7 offered, and, since it is a > single boot system, (and I haven't booted in ~85 days), I don't really have an > issue. Yes, the partitions are counted differently, and that can be a little frustrating. However, with Grub, you can refer to the partitions by label or by UUID (Grub usually defaults to using UUID) rather than drive/partition numbers, which makes it a little easier. Lilo cannot refer to the partitions in this way, so you must know what drive/partition you are referring to. This is not a big deal in many installations, however, in situations where the drive/partition number may change (e.g. usb sticks that on one boot may be /dev/sdb on one boot and /dev/sdc on another depending on how/when the bios enumerates them) this comes in very handy, as you don't have to know which drive/partition will be the root partition, you only have to know either the UUID of the partition or a label you have assigned to it, and these things don't change regardless of how/where a usb device is enumerated. > > On Thursday, July 07, 2016 03:37:12 PM Michael Milliman wrote: >> On 07/07/2016 01:55 PM, David Wright wrote: >>> On Thu 07 Jul 2016 at 14:39:51 (-0400), Gary Dale wrote: -- 73's Mike, WB5VQX
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2016-07-08 02:10 +0200 |
| Subject | Re: enumerating with Grub* (was: reasons to ditch LILO before...) |
| Message-ID | <rSrwJ-5BS-1@gated-at.bofh.it> |
| In reply to | #169857 |
rhkramer@gmail.com composed on 2016-07-07 18:47 (UTC-0400): > The thing that always frustrated me about grub is that, iirc, they counted > disks / partitions different than lilo and the rest of Linux--they start > counting at 1 (like Windows, iirc), and lilo and Linux start counting at 0--is > that still the case? Grub and Grub2 count drives starting with 0 (as a BIOS does). Grub also counts partitions starting with 0. Grub2 inexplicably counts partitions starting with 1. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2016-07-08 03:10 +0200 |
| Subject | Re: enumerating with Grub* (was: reasons to ditch LILO before...) |
| Message-ID | <rSssN-6bs-5@gated-at.bofh.it> |
| In reply to | #169861 |
> rhkramer@gmail.com composed on 2016-07-07 18:47 (UTC-0400): > >The thing that always frustrated me about grub is that, iirc, they counted > >disks / partitions different than lilo and the rest of Linux--they start > >counting at 1 (like Windows, iirc), and lilo and Linux start counting at 0--is > >that still the case? I'm sorry that this causes perpetual frustration to you, particularly as you say you really don't have an issue with grub. I'm not sure whether the answer below will please you or not... On Thu 07 Jul 2016 at 20:03:46 (-0400), Felix Miata wrote: > Grub and Grub2 count drives starting with 0 (as a BIOS does). > > Grub also counts partitions starting with 0. > > Grub2 inexplicably counts partitions starting with 1. I'm afraid I can't go back further than 1996 with Debian (but that was the first release, 1.1 or buzz). At that time, Debian counted partitions from 1, as did lilo. The old Grub definitely stood out in starting from 0, which is why they spelled it out so carefully in the docs, eg: https://www.gnu.org/software/grub/manual/legacy/Naming-convention.html#Naming-convention Now they have fallen into line, the Grub manual has to make sure you realise it has been changed, eg https://www.gnu.org/software/grub/manual/grub.html#Naming-convention The most modern fdisk program I have is gdisk (for GPT disks) and it counts partitions from 1. Is there some newfangled disk subsystem that's passed me by which starts counting at zero? Cheers, David.
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | linux.debian.user
csiph-web