[gentoo-dev] rfc: the demise of grub:0

[gentoo-dev] rfc: the demise of grub:0

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]

All,

I want to look into removing grub:0 from the tree; here are my thoughts
on why it should go.

- the handbook doesn't document grub:0; we officially only support
  grub:2.

- There are multiple bugs open against grub:0 (15 at my last count). A
  number of these as I understand it are because of custom patches we
  apply.

- grub:0 can't boot a nomultilib system, so we have to maintain a
  separate package (grub-static) specifically for that setup.

- Removing grub:0 from the tree doesn't stop you from using  it. If people
  really want it I will place it in the graveyard overlay.

  - We have custom patches for grub:0, which will never go upstream.

- grub:0 is dead upstream. They have not done any work on it in years.

- The only real problem with grub:2 has to do with pperception. Yes,
  their documentation has a strong preference toward using their
  configuration script (grub-mkconfig) to generate  your grub.cfg, but
  this is not required.

So, I want to make a plan to lastrite grub:0 and grub-static.

I'm thinking, in about a week,  p.mask grub:0 along with grub-static and
send out a lastrites msg with a 30 day removal notice.

If there any technical objections to this, let me know what they are.

Thanks,

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-dev] rfc: the demise of grub:0

[Matthias Maier]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]


On Mon, Oct  3, 2016, at 16:59 CDT, William Hubbs <williamh@gentoo.org> wrote:

> All,
>
> I want to look into removing grub:0 from the tree; here are my thoughts
> on why it should go.
>
> - the handbook doesn't document grub:0; we officially only support
>   grub:2.
>
> - Removing grub:0 from the tree doesn't stop you from using  it. If people
>   really want it I will place it in the graveyard overlay.
>
> - grub:0 is dead upstream. They have not done any work on it in years.

+1

Yes, let's lastrite it and put it into ::graveyard as well. People that
insist on using it can find it there then.

> - The only real problem with grub:2 has to do with pperception. Yes,
>   their documentation has a strong preference toward using their
>   configuration script (grub-mkconfig) to generate  your grub.cfg, but
>   this is not required.

On modern systems with UEFI and efi payloads we have the following
alternatives as well:

  sys-boot/refind
  sys-boot/systemd-boot (aka gummiboot) (alternatively sys-apps/systemd)
  - direct efi stub loading

I don't see any compelling argument that grub:0 would be the only
alternative if one tries to avoid grub:2.

Best,
Matthias

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: [gentoo-dev] rfc: the demise of grub:0

[Michael Orlitzky]

On 10/03/2016 05:59 PM, William Hubbs wrote:
> 
> - The only real problem with grub:2 has to do with pperception. Yes,
>   their documentation has a strong preference toward using their
>   configuration script (grub-mkconfig) to generate  your grub.cfg, but
>   this is not required.
> 

Migration is not always as smooth as the guides make it out to be. I had
to repartition several servers (which meant taking them offline for half
an hour) to make extra space at the beginning of the drive for grub2 to
install its mp3 player and angry birds and whatever else it needs to do
exactly what grub1 was already doing for years.

But that's not a good enough reason to keep grub1 around. If migration
fails, you can just do nothing. Uninstalling grub1 won't break anything
as far as I know. And new installations should use grub2 from the start,
so we can totally kill it.

[gentoo-dev] Re: rfc: the demise of grub:0

[Jörg Schaible]

-1

I'd love to move to grub2 for all of my machines, but it does simply not 
work for one of my servers. I can install grub2 and it tells me that 
installation and anything else went fine, but when I try to boot with it, it 
stops and reports me that it found some conflicting area in my bios why it 
cannot work (sorry, I tell this from my memory, I've tried it quite some 
time ago). Mr. Google says that this may happen for some hardware, but has 
no solution to it.

So, what are my options (or other people's options with such incompatible 
hardware) without grub 1? Lilo?

- Jörg


William Hubbs wrote:

> All,
> 
> I want to look into removing grub:0 from the tree; here are my thoughts
> on why it should go.
> 
> - the handbook doesn't document grub:0; we officially only support
>   grub:2.
> 
> - There are multiple bugs open against grub:0 (15 at my last count). A
>   number of these as I understand it are because of custom patches we
>   apply.
> 
> - grub:0 can't boot a nomultilib system, so we have to maintain a
>   separate package (grub-static) specifically for that setup.
> 
> - Removing grub:0 from the tree doesn't stop you from using  it. If people
>   really want it I will place it in the graveyard overlay.
> 
>   - We have custom patches for grub:0, which will never go upstream.
> 
> - grub:0 is dead upstream. They have not done any work on it in years.
> 
> - The only real problem with grub:2 has to do with pperception. Yes,
>   their documentation has a strong preference toward using their
>   configuration script (grub-mkconfig) to generate  your grub.cfg, but
>   this is not required.
> 
> So, I want to make a plan to lastrite grub:0 and grub-static.
> 
> I'm thinking, in about a week,  p.mask grub:0 along with grub-static and
> send out a lastrites msg with a 30 day removal notice.
> 
> If there any technical objections to this, let me know what they are.
> 
> Thanks,
> 
> William

Re: [gentoo-dev] Re: rfc: the demise of grub:0

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]

On Tue, 04 Oct 2016 09:45:35 +0200
Jörg Schaible <joerg.schaible@bpm-inspire.com> wrote:

> -1
> 
> I'd love to move to grub2 for all of my machines, but it does simply not 
> work for one of my servers. I can install grub2 and it tells me that 
> installation and anything else went fine, but when I try to boot with it, it 
> stops and reports me that it found some conflicting area in my bios why it 
> cannot work (sorry, I tell this from my memory, I've tried it quite some 
> time ago). Mr. Google says that this may happen for some hardware, but has 
> no solution to it.
> 
> So, what are my options (or other people's options with such incompatible 
> hardware) without grub 1? Lilo?

Just FYI, I'm using lilo successfully for years and never seen a reason
to install another operating system in my boot sector. However, lilo is
obviously less fool-proof, and you certainly want a simple filesystem
for /boot (like ext2).

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

Re: [gentoo-dev] Re: rfc: the demise of grub:0

[James Le Cuirot]

On Tue, 04 Oct 2016 09:45:35 +0200
Jörg Schaible <joerg.schaible@bpm-inspire.com> wrote:

> So, what are my options (or other people's options with such
> incompatible hardware) without grub 1? Lilo?

How about syslinux?

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

Re: [gentoo-dev] Re: rfc: the demise of grub:0

[Nick Vinson]

[-- Attachment #1.1: Type: text/plain, Size: 2358 bytes --]

On 10/04/2016 12:45 AM, Jörg Schaible wrote:
> -1
> 
> I'd love to move to grub2 for all of my machines, but it does simply not 
> work for one of my servers. I can install grub2 and it tells me that 
> installation and anything else went fine, but when I try to boot with it, it 
> stops and reports me that it found some conflicting area in my bios why it 
> cannot work (sorry, I tell this from my memory, I've tried it quite some 
> time ago). Mr. Google says that this may happen for some hardware, but has 
> no solution to it.

Was this ever reported in bugs.gentoo.org?

> 
> So, what are my options (or other people's options with such incompatible 
> hardware) without grub 1? Lilo?

Grub could also be an option depending on what version you tried.  If
you only tested against the stable versions, a second check would be in
order as 2.02_beta3-r1 went stable recently.

-Nick

> 
> - Jörg
> 
> 
> William Hubbs wrote:
> 
>> All,
>>
>> I want to look into removing grub:0 from the tree; here are my thoughts
>> on why it should go.
>>
>> - the handbook doesn't document grub:0; we officially only support
>>   grub:2.
>>
>> - There are multiple bugs open against grub:0 (15 at my last count). A
>>   number of these as I understand it are because of custom patches we
>>   apply.
>>
>> - grub:0 can't boot a nomultilib system, so we have to maintain a
>>   separate package (grub-static) specifically for that setup.
>>
>> - Removing grub:0 from the tree doesn't stop you from using  it. If people
>>   really want it I will place it in the graveyard overlay.
>>
>>   - We have custom patches for grub:0, which will never go upstream.
>>
>> - grub:0 is dead upstream. They have not done any work on it in years.
>>
>> - The only real problem with grub:2 has to do with pperception. Yes,
>>   their documentation has a strong preference toward using their
>>   configuration script (grub-mkconfig) to generate  your grub.cfg, but
>>   this is not required.
>>
>> So, I want to make a plan to lastrite grub:0 and grub-static.
>>
>> I'm thinking, in about a week,  p.mask grub:0 along with grub-static and
>> send out a lastrites msg with a 30 day removal notice.
>>
>> If there any technical objections to this, let me know what they are.
>>
>> Thanks,
>>
>> William
> 
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[gentoo-dev] Re: rfc: the demise of grub:0

[Duncan]

William Hubbs posted on Mon, 03 Oct 2016 16:59:33 -0500 as excerpted:

> I want to look into removing grub:0 from the tree; here are my thoughts
> on why it should go.

I don't disagree with the thought, but have some niggles on the 
individual points.  Note that I'm not nearly as negative on the idea in 
general as the comments on the individual points may suggest on their own.

> - the handbook doesn't document grub:0; we officially only support
>   grub:2.

That's not a reason to remove grub:0 from the tree.  If it was, there's 
many other alternative boot managers that would need removed as well.  
Thankfully, gentoo tends to emphasize choice. =:^)

> - There are multiple bugs open against grub:0 (15 at my last count). A
>   number of these as I understand it are because of custom patches we
>   apply.

+1

> - grub:0 can't boot a nomultilib system, so we have to maintain a
>   separate package (grub-static) specifically for that setup.

Grub:0 can _boot_ a no-multilib system just fine.  AFAIK the problem is 
at build time -- a no-multilib system can't *build* grub:0.

FWIW I run no-multilib myself, but as I switched from a multilib system 
and still had its grub:0 installed and booting when I first went no-
multilib, I know it /boots/ just fine.

And AFAIK that's actually what grub-static is, a pre-built grub:0 tarball 
with an installer that installs the prebuilt pieces in all the right 
places, originally developed IIRC by the gentoo/amd64 folks precisely to 
solve the amd64 no-multilib build problem.

> - Removing grub:0 from the tree doesn't stop you from using  it. If
>   people really want it I will place it in the graveyard overlay.

Another alternative would be simply hard-masking it, but leaving it in 
place for those who want it.  It does still work, and I see no evidence 
we're removing it due to security issues or breakage.

> - We have custom patches for grub:0, which will never go upstream.
> 
> - grub:0 is dead upstream. They have not done any work on it in years.

Both valid points.

But I'll make the same point here as I did on a different proposed 
package removal thread recently.  General gentoo policy is that a dead 
upstream (and lack of a gentoo maintainer) isn't sufficient reason to 
remove a package if it still works.  As long as it's not broken or a 
security issue, the general policy is to leave it in the tree for anyone 
that needs it.

So is grub:0 so broken it justifies removal from the tree, despite 
potentially many users still having it installed and working just fine?

> - The only real problem with grub:2 has to do with pperception. Yes,
>   their documentation has a strong preference toward using their
>   configuration script (grub-mkconfig) to generate  your grub.cfg, but
>   this is not required.

+100.  Good gentoo documentation on properly creating and managing your 
own grub.cfg without their config script would go a long way here.  (This 
may already exist, I switched to grub2 while the documentation remained 
quite raw.)

An alternative would be a pointer to quality Arch documentation, or the 
like.  Obviously we're unlikely to ever get it from upstream, tho they do 
provide generally reasonable manpage style (tho not specifically manpage) 
documentation, just not anything really user level.

> So, I want to make a plan to lastrite grub:0 and grub-static.
> 
> I'm thinking, in about a week,  p.mask grub:0 along with grub-static and
> send out a lastrites msg with a 30 day removal notice.

I'd suggest that this is a sufficiently huge change (comparable in level 
to the openrc upgrade you handled a few years back, tho obviously not as 
wide ranging in terms of other packages affected) for anyone still on 
grub:0 that a far longer warning and removal period is justified.

I'd suggest something more like six months, with a news item beginning 
the period, and the traditional 30-day package-masking five months later, 
to encourage the laggerts.


And again, is grub:0 really more broken than say lilo?  I believe it 
remains more flexible, even if not as flexible as grub:2.  If it's not 
more broken, what justifies removal from the tree when lilo and various 
other similar boot manager packages remain?

That said, as I said at the beginning, I'm not entirely opposed, either.  
Primarily, I simply don't see the sense in removing grub:0 and grub-
static if lilo and etc remain, and it seems to me that if we're actually 
going to be removing grub:0 and grub-static, we should be considering 
removal of the others as well, because in practice, grub:0 isn't really 
more limiting or more broken than they are.  And removal of all those 
/would/ be a shame, as well as arguably an abrogation of the emphasis on 
choice that gentoo is known for.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: rfc: the demise of grub:0

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 6150 bytes --]

On Tue, Oct 04, 2016 at 08:44:05PM +0000, Duncan wrote:
> William Hubbs posted on Mon, 03 Oct 2016 16:59:33 -0500 as excerpted:
> 
> > I want to look into removing grub:0 from the tree; here are my thoughts
> > on why it should go.
> 
> I don't disagree with the thought, but have some niggles on the 
> individual points.  Note that I'm not nearly as negative on the idea in 
> general as the comments on the individual points may suggest on their own.
 
 Why bring them up then?  ;-)

> > - the handbook doesn't document grub:0; we officially only support
> >   grub:2.
> 
> That's not a reason to remove grub:0 from the tree.  If it was, there's 
> many other alternative boot managers that would need removed as well.  
> Thankfully, gentoo tends to emphasize choice. =:^)
 
 I'm talking about removing the old, obsoleted version of grub, not all
 of sys-boot/grub. Technically all of grub should have slot 0, but we
 made grub 2 have slot 2 so people could take longer to migrate. grub 2
 has been stable in the tree for over a year.

> > - grub:0 can't boot a nomultilib system, so we have to maintain a
> >   separate package (grub-static) specifically for that setup.
> 
> Grub:0 can _boot_ a no-multilib system just fine.  AFAIK the problem is 
> at build time -- a no-multilib system can't *build* grub:0.
> 
> FWIW I run no-multilib myself, but as I switched from a multilib system 
> and still had its grub:0 installed and booting when I first went no-
> multilib, I know it /boots/ just fine.
> 
> And AFAIK that's actually what grub-static is, a pre-built grub:0 tarball 
> with an installer that installs the prebuilt pieces in all the right 
> places, originally developed IIRC by the gentoo/amd64 folks precisely to 
> solve the amd64 no-multilib build problem.
 
 This would actually be another reason to get rid of grub-0, if it can't
 build on one of our profiles, it will more than likely never be fixed
 upstream because they are now focused on grub-2.x.

> > - Removing grub:0 from the tree doesn't stop you from using  it. If
> >   people really want it I will place it in the graveyard overlay.
> 
> Another alternative would be simply hard-masking it, but leaving it in 
> place for those who want it.  It does still work, and I see no evidence 
> we're removing it due to security issues or breakage.

We are removing it because upstream has a new version of the software
and has moved on from this one. For most packages, if foo-1.0 is
stable, then foo-2.0 comes to stable, after some point we remove foo-1.0
from the tree.

> > - We have custom patches for grub:0, which will never go upstream.
> > 
> > - grub:0 is dead upstream. They have not done any work on it in years.
> 
> Both valid points.
> 
> But I'll make the same point here as I did on a different proposed 
> package removal thread recently.  General gentoo policy is that a dead 
> upstream (and lack of a gentoo maintainer) isn't sufficient reason to 
> remove a package if it still works.  As long as it's not broken or a 
> security issue, the general policy is to leave it in the tree for anyone 
> that needs it.
 
 As I said above, I'm not removing sys-boot/grub, just the obsoleted version.

> So is grub:0 so broken it justifies removal from the tree, despite 
> potentially many users still having it installed and working just fine?

Think of this as being like module-init-tools vs kmod. Upstream
module-init-tools stopped development and told everyone to move to kmod,
so we did. This is similar. grub-2.x is now the official version of grub
where upstream development happens. grub-0.x is abandoned.

> > - The only real problem with grub:2 has to do with pperception. Yes,
> >   their documentation has a strong preference toward using their
> >   configuration script (grub-mkconfig) to generate  your grub.cfg, but
> >   this is not required.
> 
> +100.  Good gentoo documentation on properly creating and managing your 
> own grub.cfg without their config script would go a long way here.  (This 
> may already exist, I switched to grub2 while the documentation remained 
> quite raw.)
 
The problem is that it would be next to impossible to document what a
grub.cfg should look like, because that depends so much on how you
install your kernels, initramfs, etc. The grub info pages explain all of
what can go in grub.cfg.

> > So, I want to make a plan to lastrite grub:0 and grub-static.
> > 
> > I'm thinking, in about a week,  p.mask grub:0 along with grub-static and
> > send out a lastrites msg with a 30 day removal notice.
> 
> I'd suggest that this is a sufficiently huge change (comparable in level 
> to the openrc upgrade you handled a few years back, tho obviously not as 
> wide ranging in terms of other packages affected) for anyone still on 
> grub:0 that a far longer warning and removal period is justified.
>
> I'd suggest something more like six months, with a news item beginning 
> the period, and the traditional 30-day package-masking five months later, 
> to encourage the laggerts.

I don't agree with a news item then no action after that for 5 months
because people will read the newsitem and not take any action, then they
will forget and we'll be back to having this discussion when the
traditional lastrites happens.

I also don't agree with a really long time like this for the removal for
the same reason; people will forget then wonder what happened when
things are removed.

Another thing to consider is, upgrading the grub package doesn't change how your
system boots. That change doesn't happen until you run grub-install from
the newer version of grub.

> And again, is grub:0 really more broken than say lilo?  I believe it 
> remains more flexible, even if not as flexible as grub:2.  If it's not 
> more broken, what justifies removal from the tree when lilo and various 
> other similar boot manager packages remain?
 
 Again, I'm not removing sys-boot/grub, so comparing this to removing
 sys-boot/syslinux, sys-boot/lilo etc does not feel right to me.

 William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-dev] Re: rfc: the demise of grub:0

[Fernando Rodriguez]

On 10/04/2016 06:24 PM, William Hubbs wrote:
>  
>  This would actually be another reason to get rid of grub-0, if it can't
>  build on one of our profiles, it will more than likely never be fixed
>  upstream because they are now focused on grub-2.x.

grub-0 is 32-bit software. You could build it without multilib but you need
the dependencies like any other package (and link them statically). And there
are other packages on the tree that don't build on all profiles.

>> Another alternative would be simply hard-masking it, but leaving it in 
>> place for those who want it.  It does still work, and I see no evidence 
>> we're removing it due to security issues or breakage.
> 
> We are removing it because upstream has a new version of the software
> and has moved on from this one. For most packages, if foo-1.0 is
> stable, then foo-2.0 comes to stable, after some point we remove foo-1.0
> from the tree.

Grub2 is not really a new version, it's a different product with different
use cases. I don't use grub-0 to boot any of my gentoo boxes but I use it for
some embedded x86 projects so it's convenient to be able build it off the
tree. I remember trying grub2 on one of them a while back and IIRC it more
than doubled the size of the image.

Just my 2 cents worth.

-- 

Fernando Rodriguez

Re: [gentoo-dev] Re: rfc: the demise of grub:0

[Raymond Jennings]

[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]

On Thu, Oct 13, 2016 at 7:01 AM, Fernando Rodriguez <cyklonite@gmail.com>
wrote:

> On 10/04/2016 06:24 PM, William Hubbs wrote:
> >
> >  This would actually be another reason to get rid of grub-0, if it can't
> >  build on one of our profiles, it will more than likely never be fixed
> >  upstream because they are now focused on grub-2.x.
>
> grub-0 is 32-bit software. You could build it without multilib but you need
> the dependencies like any other package (and link them statically). And
> there
> are other packages on the tree that don't build on all profiles.
>

USE="abi_x86_32"

?

>> Another alternative would be simply hard-masking it, but leaving it in
> >> place for those who want it.  It does still work, and I see no evidence
> >> we're removing it due to security issues or breakage.
> >
> > We are removing it because upstream has a new version of the software
> > and has moved on from this one. For most packages, if foo-1.0 is
> > stable, then foo-2.0 comes to stable, after some point we remove foo-1.0
> > from the tree.
>
> Grub2 is not really a new version, it's a different product with different
> use cases. I don't use grub-0 to boot any of my gentoo boxes but I use it
> for
> some embedded x86 projects so it's convenient to be able build it off the
> tree. I remember trying grub2 on one of them a while back and IIRC it more
> than doubled the size of the image.
>
> Just my 2 cents worth.
>
> --
>
> Fernando Rodriguez
>
>

[-- Attachment #2: Type: text/html, Size: 2201 bytes --]

Re: [gentoo-dev] Re: rfc: the demise of grub:0

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 1022 bytes --]

On 13/10/16 10:13 AM, Raymond Jennings wrote:
> On Thu, Oct 13, 2016 at 7:01 AM, Fernando Rodriguez
> <cyklonite@gmail.com <mailto:cyklonite@gmail.com>> wrote:
> 
>     On 10/04/2016 06:24 PM, William Hubbs wrote:
>     >
>     >  This would actually be another reason to get rid of grub-0, if it can't
>     >  build on one of our profiles, it will more than likely never be fixed
>     >  upstream because they are now focused on grub-2.x.
> 
>     grub-0 is 32-bit software. You could build it without multilib but
>     you need
>     the dependencies like any other package (and link them
>     statically). And there
>     are other packages on the tree that don't build on all profiles.
> 
> 
> USE="abi_x86_32"
> 
> ?

Yes, that's how it's supported on multilib.  Note though it still
needs a multilib profile in order to have an abi_x86_32 libc;
grub-static exists to support systems where there is no abi_x86_32
libc installed, such as those systems using the no-multilib profile.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: [gentoo-dev] Re: rfc: the demise of grub:0

[Fernando Rodriguez]

On 10/13/2016 10:21 AM, Ian Stakenvicius wrote:
> On 13/10/16 10:13 AM, Raymond Jennings wrote:
>> On Thu, Oct 13, 2016 at 7:01 AM, Fernando Rodriguez
>> <cyklonite@gmail.com <mailto:cyklonite@gmail.com>> wrote:
>>
>>     On 10/04/2016 06:24 PM, William Hubbs wrote:
>>     >
>>     >  This would actually be another reason to get rid of grub-0, if it can't
>>     >  build on one of our profiles, it will more than likely never be fixed
>>     >  upstream because they are now focused on grub-2.x.
>>
>>     grub-0 is 32-bit software. You could build it without multilib but
>>     you need
>>     the dependencies like any other package (and link them
>>     statically). And there
>>     are other packages on the tree that don't build on all profiles.
>>
>>
>> USE="abi_x86_32"
>>
>> ?
> 
> Yes, that's how it's supported on multilib.  Note though it still
> needs a multilib profile in order to have an abi_x86_32 libc;
> grub-static exists to support systems where there is no abi_x86_32
> libc installed, such as those systems using the no-multilib profile.

I didn't mean it's supported by gentoo but that is possible to build it
without a 32-bit *system* libc. Just bundle it and link it statically like
firefox does with it's deps. grub-static probably makes more sense (that's
a binary package right?). I just meant that this is not a sign that the
package it's broken upstream as the comment implied.


-- 

Fernando Rodriguez

Re: [gentoo-dev] Re: rfc: the demise of grub:0

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 2006 bytes --]

On 14/10/16 10:22 AM, Fernando Rodriguez wrote:
> On 10/13/2016 10:21 AM, Ian Stakenvicius wrote:
>> On 13/10/16 10:13 AM, Raymond Jennings wrote:
>>> On Thu, Oct 13, 2016 at 7:01 AM, Fernando Rodriguez
>>> <cyklonite@gmail.com <mailto:cyklonite@gmail.com>> wrote:
>>>
>>>     On 10/04/2016 06:24 PM, William Hubbs wrote:
>>>     >
>>>     >  This would actually be another reason to get rid of grub-0, if it can't
>>>     >  build on one of our profiles, it will more than likely never be fixed
>>>     >  upstream because they are now focused on grub-2.x.
>>>
>>>     grub-0 is 32-bit software. You could build it without multilib but
>>>     you need
>>>     the dependencies like any other package (and link them
>>>     statically). And there
>>>     are other packages on the tree that don't build on all profiles.
>>>
>>>
>>> USE="abi_x86_32"
>>>
>>> ?
>>
>> Yes, that's how it's supported on multilib.  Note though it still
>> needs a multilib profile in order to have an abi_x86_32 libc;
>> grub-static exists to support systems where there is no abi_x86_32
>> libc installed, such as those systems using the no-multilib profile.
> 
> I didn't mean it's supported by gentoo but that is possible to build it
> without a 32-bit *system* libc. Just bundle it and link it statically like
> firefox does with it's deps. grub-static probably makes more sense (that's
> a binary package right?). I just meant that this is not a sign that the
> package it's broken upstream as the comment implied.
> 
> 

Ahh, ok.  So you're just confirming what cyklonite mentioned.  I
didn't get that the first time around.

To the specifics though, no it doesn't make sense to bundle a copy of
glibc so that it can be built 32bit in order to support linking grub:0
to it; if anyone -really- wants to build grub:0 on a pure64 platform
then they can use a 32bit crossdev to do it, just like they'd have to
do to build anything else that's 32bit only on a pure64 install.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: [gentoo-dev] rfc: the demise of grub:0

[Dan Douglas]

I'm not against removing grub1, but why are the only versions of grub
in the tree betas? They don't have a proper release cycle?

Also grub2-mkconfig is disgusting. I wonder if anybody is interested
in making something better because I doubt it would be much work for
someone that knows grub well. 90% of what it does is generate
boilerplate code that few people understand.

Re: [gentoo-dev] rfc: the demise of grub:0

[Mike Gilbert]

On Tue, Oct 4, 2016 at 6:04 PM, Dan Douglas <ormaaj@gmail.com> wrote:
> I'm not against removing grub1, but why are the only versions of grub
> in the tree betas? They don't have a proper release cycle?

The upstream grub maintainer has been too busy to work on a release.
He has recently recruited some people to help him, so hopefully we
should see a real release soon(ish).

http://lists.gnu.org/archive/html/grub-devel/2016-08/msg00063.html

Re: [gentoo-dev] rfc: the demise of grub:0

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

On Tue, Oct 04, 2016 at 05:04:12PM -0500, Dan Douglas wrote:
> Also grub2-mkconfig is disgusting. I wonder if anybody is interested
> in making something better because I doubt it would be much work for
> someone that knows grub well. 90% of what it does is generate
> boilerplate code that few people understand.

If you know grub well, you can hand write a grub.cfg without
using grub-mkconfig at all. There is a  perception that you need
grub-mkconfig, but this is not true.

William



[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-dev] rfc: the demise of grub:0

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

On Tue, 4 Oct 2016 17:28:55 -0500
William Hubbs <williamh@gentoo.org> wrote:

> If you know grub well, you can hand write a grub.cfg without
> using grub-mkconfig at all. There is a  perception that you need
> grub-mkconfig, but this is not true.

I guess the problem is neither knowing "grub well" or liking mkconfig.

So you start with mkconfig, thinking it making things simpler, and then
landing you with a config file you have no show in hell of fixing or
understanding with your limited grub knowledge.

This leaves you with a need to configure your system, but without the tools
or understanding to configure your system, and the "learn up" curve is
appreciably steep for something that is so basic and yet seldomly
changed once created.

Hence, a more sensible default instead of mkconfig that emits a config
file that mortals can sensibly edit ( including relevant inline comments
describing what is done ) would be a smart move that would go a long
way.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [gentoo-dev] rfc: the demise of grub:0

[Rich Freeman]

On Tue, Oct 4, 2016 at 9:29 PM, Kent Fredric <kentnl@gentoo.org> wrote:
>
> Hence, a more sensible default instead of mkconfig that emits a config
> file that mortals can sensibly edit ( including relevant inline comments
> describing what is done ) would be a smart move that would go a long
> way.
>

How do you generate your grub-0 config files?

You can just use the same method to generate the grub-2 ones...

-- 
Rich

Re: [gentoo-dev] rfc: the demise of grub:0

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

On Tue, 4 Oct 2016 22:22:12 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> How do you generate your grub-0 config files?

I didn't, it came as a stock example file with comments which I edited
in a minimal fashion until it worked.

> 
> You can just use the same method to generate the grub-2 ones...

No, I regenerated it with mkconfig, replacing the file.

The new file has a whole lot of stuff I don't understand, and direct
editing of it terrifies me to an extent because there's no clear
explanation of what half of it does.

Hence, my exposition.

I am thus mostly just relying on mkconfig now and crossing my fingers.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [gentoo-dev] rfc: the demise of grub:0

[Rich Freeman]

On Tue, Oct 4, 2016 at 9:57 PM, Kent Fredric <kentnl@gentoo.org> wrote:
> On Tue, 4 Oct 2016 22:22:12 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>
>> How do you generate your grub-0 config files?
>
> I didn't, it came as a stock example file with comments which I edited
> in a minimal fashion until it worked.
>

Not a surprise, that is how most did it.

>>
>> You can just use the same method to generate the grub-2 ones...
>
> No, I regenerated it with mkconfig, replacing the file.

And that is my point.

In the past you were given a template file and some instructions and
simply edited it.

Now you're given a fancy file-generator tool which you don't like.
So, instead of a template file you ask for another simpler
file-generator tool, which I think is the wrong approach.

What you really want is another template file.

I'm happy with mkconfig, but I did hand-roll my config files before
that.  The docs are out there.  However, for whatever reason, it is
very hard to find examples of simple config files online.  The
official docs try to point you in the direction of mkconfig, and since
99% of linux users don't configure their own grub there isn't much
alternative documentation (and when a distro's solution does break the
solution usually is based on mkconfig anyway).

Unfortunately, I deleted the last copy of my manually-generated config
files eons ago, otherwise I'd happily post one.  The syntax is ALMOST
identical to grub-0, but not quite.  The syntax is documented though,
and you can get a sense for how it works in the mkconfig-generated
ones, but I'll go ahead and point out that 99% of the stuff in those
is unnecessary.  The essential elements are basically the same as they
were before.

-- 
Rich

Re: [gentoo-dev] rfc: the demise of grub:0

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 984 bytes --]

On Wed, 5 Oct 2016 06:04:38 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> What you really want is another template file.

I'd be happy with that. See the other thread with "grub-2" In the title.

> I'm happy with mkconfig, but I did hand-roll my config files before
> that.  The docs are out there.  However, for whatever reason, it is
> very hard to find examples of simple config files online.  The
> official docs try to point you in the direction of mkconfig, and since
> 99% of linux users don't configure their own grub there isn't much
> alternative documentation (and when a distro's solution does break the
> solution usually is based on mkconfig anyway).

Yeah, the only reason I suggested "a tool" instead of "a template" is
that perhaps there could be a handful of easily detectable things that
generate a more optimal "initial" template.

Particularly with regards to getting the hard-drive numbers and stuff
right, that's what always concerns me.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [gentoo-dev] rfc: the demise of grub:0

[Patrick McLean]

[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]

On Thu, 6 Oct 2016 01:54:51 +1300
Kent Fredric <kentnl@gentoo.org> wrote:

> On Wed, 5 Oct 2016 06:04:38 -0500
> Rich Freeman <rich0@gentoo.org> wrote:
> 
> > What you really want is another template file.  
> 
> I'd be happy with that. See the other thread with "grub-2" In the
> title.
> 
> > I'm happy with mkconfig, but I did hand-roll my config files before
> > that.  The docs are out there.  However, for whatever reason, it is
> > very hard to find examples of simple config files online.  The
> > official docs try to point you in the direction of mkconfig, and
> > since 99% of linux users don't configure their own grub there isn't
> > much alternative documentation (and when a distro's solution does
> > break the solution usually is based on mkconfig anyway).  
> 
> Yeah, the only reason I suggested "a tool" instead of "a template" is
> that perhaps there could be a handful of easily detectable things that
> generate a more optimal "initial" template.
> 
> Particularly with regards to getting the hard-drive numbers and stuff
> right, that's what always concerns me.

I have attached a somewhat cleaned up and commented version of the
hand-written grub config I use at home. Feel free to use as an example
for your machines, add it to the wiki and/or the handbook, or make the
ebuild install it to /usr/share etc.

One of the nice things about grub2 is that you no longer need to know
or care about the BIOS disk numbers, you can simply use the UUID of the
filesystem (and/or the PARTUUID for the kernel).

[-- Attachment #2: grub.cfg --]
[-- Type: application/octet-stream, Size: 3085 bytes --]

# /boot/grub/grub.cfg
# Grub configuration file
#
# Author: Patrick McLean <chutzpah@gentoo.org>
#

# The UUID of the Linux boot filesystem (and where grub lives)
# blkid to find the UUID of the /boot filesystem
# blkid <device>
set boot_uuid=""

# The PARTUUID of the Linux root filesystem, use blkid to find this
set root_partuuid=""

# the partuuid of the filesystem containing windoes (if applicable)
#set win_partuuid=""

# we must have some default, set it to the first menu entry for now
set default=0

# this is a function definition to save the default to the selected
# menu option (this can be used below)
function savedefault {
	if [ -z "${boot_once}" ]; then
		if [ -n "${1}" ]; then
			saved_entry="${1}"
		else
			saved_entry="${chosen}"
		fi
		save_env saved_entry
	fi
}

# load graphics drivers if we are on UEFI
if [ ${grub_platform} = efi ]; then
	insmod efi_gop
	insmod efi_uga
fi

terminal_input console
terminal_output console

# disable the timeout if shift is being held
if keystatus --shift; then
	set timeout=-1
else
	set timeout=30
fi

set superusers="root"
# use grub-mkpasswd-pbkdf2 to generate a password here
password_pbkdf2 root PASSWORD

# find the root filesystem with the bootloader files
# uncomment the appropiate module for your partition table here
insmod part_gpt
insmod part_msdos

# uncomment the appropiate module for the filesystem that /boot is formatted
# as with here, use your root filesystem if it's the same partition

# use ext2 for ext{2,3,4}
insmod ext2
#insmod btrfs
#insmod jfs
#insmod xfs
#insmod zfs

# uncomment the module for the compression used for your kernel
insmod gzio
insmod xzio
insmod lzopio

# this tells grub to search for the /boot filesystem so it can load kernels
# and other data from said filesystem
search --no-floppy --fs-uuid --set=root ${boot_uuid}

# menu entries, uncomment "savedefault" to save the entry as the default
# after it has been selected, 
menuentry 'Gentoo Linux' --class="gentoo" --unrestricted --hotkey="l" {
	linux	(${root})/boot/vmlinuz root=PARTUUID=${root_partuuid} ro
	#savedefault
}

# menu entry to load windows, works for all recent versions of windows
#menuentry 'Windows 10' --class="windows" --unrestricted --hotkey="w" {
#    insmod ntldr
#    insmod ntfs
#    search --no-floppy --fs-uuid --set=root ${win_partuuid}
#    ntldr (${root})/bootmgr
#    savedefault
#}

menuentry 'Gentoo Linux (Old Kernel)' --class "gentoo" --unrestricted --hotkey=="o" {
	linux	(${root})/boot/vmlinuz.old root=PARTUUID=${root_partuuid} ro
}

menuentry 'Gentoo Linux (Single User Mode)' --class "gentoo" {
	linux	(${root})/boot/vmlinuz single root=PARTUUID=${root_partuuid} ro
}

menuentry 'Gentoo Linux (Recovery Mode)' --class "gentoo" --users root {
	linux	(${root})/boot/vmlinuz single root=PARTUUID=${root_partuuid} ro init=/bin/bb
}

menuentry 'Memtest86' --class="memtest" --unrestricted --hotkey="l" {
	linux16	(${root})/boot/memtest86/memtest
	#savedefault
}

menuentry "Memtest86+" --unrestricted --class "memtest" {
	linux16 (${root})/boot/memtest86plus/memtest.bin
	#savedefault 0
}