[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]

On Tue, 04 Oct 2016 09:45:35 +0200
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.
> 
> 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



pgpevKuqpM8v6.pgp
Description: OpenPGP digital signature

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  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]

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
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: #wg-stable: Reservations about a "STABLE" & "NeedsStable" bugzilla keywords (re: [gentoo-dev] New Working Group established to evaluate the stable tree)

[Ian Stakenvicius]

On 20/08/16 08:30 PM, Daniel Campbell wrote:
> On 08/15/2016 12:42 PM, Rich Freeman wrote:
>> On Mon, Aug 15, 2016 at 3:30 PM, Andreas K. Hüttel  
>> wrote:
>>> 1) Stabilization is a simpler and much more formalized process compared to
>>> normal bug resolution.
>>> * There is one version to be stabilized.
>>> * One precise package version
>>
>> Can you clarify what this means?  Do you mean that at any time only
>> one version of any particular package/slot is marked stable?
>>
>> That seems like it would be problematic for ranged deps.  Granted,
>> those are problematic in and of themselves since they can create
>> conflicts that are hard to resolve.  However, this extends conflicts
>> between package you might not want to install at the same time to
>> situations where you don't even need both of the conflicting packages.
>>
> I believe he's just talking about a per-bug or per-stablereq basis. So
> each version gets its own opportunity to have bugs surface or
> stabilization issues instead of attempting to stabilize a bunch of
> versions at once.
> 
> (Correct me if I'm wrong; I don't see the value of a single stable
> version for each package and it would create a lot of noise in git log)
> 

Even though some projects (mozilla, for instance) do request
stabilizations of multiple packages and/or versions in a single go,
that doesn't mean we should and I have no issues changing our process
to something more atomic.

What should be noted here is that if we work towards adopting new
tools or methods here, we absolutely need to do so in a way that is
beneficial to the workflow of our AT's, especially those that perform
large numbers of stabilizations like ago.  If this new process doesn't
make things at least incrementally easier for them, it needs to be
re-thought.




signature.asc
Description: OpenPGP digital signature

[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

[gentoo-dev] [warning] the bug queue has 92 bugs

[Alex Alexander]

Our bug queue has 92 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

Re: [gentoo-dev] SRC_URI="gogdownloader://..."

[James Le Cuirot]

On Mon, 3 Oct 2016 21:28:48 +0100
James Le Cuirot  wrote:

> I'll also file a
> bug so we can further discuss which avenue to take.

Turns out there is already an old bug for this:
https://bugs.gentoo.org/show_bug.cgi?id=391439

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpfDo7QN0ug7.pgp
Description: OpenPGP digital signature

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  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] Re: rfc: the demise of grub:0

[William Hubbs]

On Tue, Oct 04, 2016 at 08:44:05PM +, 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 en

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

[William Hubbs]

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




signature.asc
Description: Digital signature

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

[Kent Fredric]

On Tue, 4 Oct 2016 17:28:55 -0500
William Hubbs  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.





pgpaP5W_eViVx.pgp
Description: OpenPGP digital signature

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

[Rich Freeman]

On Tue, Oct 4, 2016 at 9:29 PM, Kent Fredric  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]

On Tue, 4 Oct 2016 22:22:12 -0400
Rich Freeman  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.


pgpDCzWGKCMQB.pgp
Description: OpenPGP digital signature

[gentoo-dev] grub-2 configuration

[William Hubbs]

I broke the thread, because grub-2 configuration is an interesting
topic, but I think it deserves a separate thread from the removal of
grub-0 discussion.

On Wed, Oct 05, 2016 at 03:57:25PM +1300, Kent Fredric wrote:
> On Tue, 4 Oct 2016 22:22:12 -0400
> Rich Freeman  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.

That's what I've been doing, and it works pretty well.

I can tell you a bit of how it works. It uses the settings in
/etc/default/grub along with the templates in /etc/grub.d to generate
grub.cfg. You can tweak a lot of what gets generated by tweaking the
settings in /etc/default/grub.

You don't have to use grub-mkconfig. You can write /boot/grub/grub.cfg
by hand if you want, and it appears that the syntax is documented in the
grub info pages.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] grub-2 configuration

[Kent Fredric]

On Tue, 4 Oct 2016 22:34:11 -0500
William Hubbs  wrote:

> You don't have to use grub-mkconfig. You can write /boot/grub/grub.cfg
> by hand if you want, and it appears that the syntax is documented in the
> grub info pages.
> 
> William

Just saying, it would be really nice to have some documented example cases
ship with grub-2, like it did with grub:0 

grub:0 via http://www.portagefilelist.de

/usr/share/doc/grub-0.97-r17/grub.conf.gentoo.bz2   obj amd64, x86  
custom-cflags, ncurses, netboot
/usr/share/doc/grub-0.97-r17/grub.conf.gentoo.xzobj amd64   ncurses
/usr/share/doc/grub-0.97-r17/grub.conf.sample.bz2   obj amd64, x86  
custom-cflags, ncurses, netboot
/usr/share/doc/grub-0.97-r17/grub.conf.sample.xzobj amd64   ncurses

grub-2 via qlist grub | grep -i conf 

/usr/share/man/man8/grub-mkconfig.8.bz2
/usr/share/grub/grub-mkconfig_lib
/usr/sbin/grub-mkconfig
/usr/lib/grub/i386-pc/configfile.module
/usr/lib/grub/i386-pc/configfile.mod
/usr/lib/grub/i386-pc/config.h
/usr/lib/grub/i386-multiboot/configfile.module
/usr/lib/grub/i386-multiboot/configfile.mod
/usr/lib/grub/i386-multiboot/config.h
/usr/lib/grub/i386-qemu/configfile.module
/usr/lib/grub/i386-qemu/configfile.mod
/usr/lib/grub/i386-qemu/config.h

Its pretty clear which of these we're getting pushed to use.


pgpnt4UrVItFm.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] grub-2 configuration

[Kent Fredric]

On Wed, 5 Oct 2016 17:46:29 +1300
Kent Fredric  wrote:

> On Tue, 4 Oct 2016 22:34:11 -0500
> William Hubbs  wrote:
> 
> > You don't have to use grub-mkconfig. You can write /boot/grub/grub.cfg
> > by hand if you want, and it appears that the syntax is documented in the
> > grub info pages.
> > 
> > William  
> 
> Just saying, it would be really nice to have some documented example cases
> ship with grub-2, like it did with grub:0 
> 
> grub-2 via qlist grub | grep -i conf 
> 
> Its pretty clear which of these we're getting pushed to use.


There does however exist a /usr/portage/sys-boot/grub/files/grub.conf.gentoo on 
my system,
It just has to be 

a) Updated to stay relevant
b) Placed in a place I expect to find it
c) Be referenced in the grub-2 post-install messages or at very least, more 
prevalent in 
https://wiki.gentoo.org/wiki/GRUB2_Quick_Start 

Because encouraging everyone to use it the way that has clearly seen
resistance in gentoo doesn't seem to be helping.

Though I do see the documentation is better than it was when I
switched, the message that you can use a simpler configuration scheme
is not prevalent enough for people to be noticing it. 


pgpvxzvmDbapD.pgp
Description: OpenPGP digital signature