Re: [gentoo-user] grub-0.97-r16 and profile 17.0 change

[Kai Peter <kp@lists.openqmail.org>]

On 2017-12-07 15:22, Peter Humphrey wrote:
> On Thursday, 7 December 2017 12:04:08 GMT Kai Peter wrote:
>> On 2017-12-06 13:28, Peter Humphrey wrote:
>> > On Sunday, 3 December 2017 15:12:21 GMT Mick wrote:
>> >> On 03-12-2017 ,10:57:33, Peter Humphrey wrote:
> 
> --->8
> 
>> > Sys-boot/grub-0.97-r17 compiled and installed all right, as a package,
>> > but when I went to install it to the MBR I got an error complaining of a
>> > mismatch or corruption in stage X. The wording was something like that,
>> > and I forget the value of X. There was no mention of disk space, and the
>> > boot partition is 2GB, so I think it's something else.
>> >
>> > Installing sys-boot/grub-static-0.97-r12 instead went smoothly, so I've
>> > left it like that for the moment.
>> >
>> > Does the team think I should go back to grub-0.97-r17, take proper
>> > records and file a bug report?
>> 
>> I question if this makes sense for a masked ebuild.
> 
> Masked? Not here, it isn't.
In the meaning of 'keyworded':
KEYWORDS="~amd64 ~x86 ~x86-fbsd"
(Why i did know that this will be misunderstood?)

Anyway, it's your choice to file a bug.
> 
>> I'm curious about what was discussed until now. The issue seems to be
>> quite simple to solve.
>> 
>> The build fails but portage/gcc does give clear info in this case: the
>> option "-nopie" have to be changed to "-no-pie". This option is set in
>> 860_all_grub-0.97-pie.patch. Here is a diff:
> 
> --->8
> 
> Yes, this has been made clear already, but it's not the problem I had.
Didn't find it in this thread - my fault. Btw. kernels haven't to be 
stored in /boot necessarily - related to the posts of the size of the 
boot partition. And maybe related to your problem: the r17 ebuild 
differs by the use of patches heavily.
> 
>> Maybe the easiest way is to create a new grub-patches package, but 
>> there
>> are other ways to change this too. I'm expected the upstream will 
>> change
>> this soon - within the remaining 5 weeks ;-).
>> 
>> Another thing is I question that grub-legacy have to be rebuild at 
>> all.
>> I'm pretty sure it is save to remove it from the world file or comment
>> it out.
> 
> Then the first emerge -c will remove it from the system.
Does anybody run emerge -c blindly w/o reviewing the packages before? If 
yes compile it outside of portage. Or backup the required files, do 
emerge -c and restore the backup'd files afterwards. Or ...
> 
>> Anyhow, upgrading to grub2 is IMHO the right way. There are some
>> examples given in parallel threads how to write a grub.cfg by hand - 
>> and
>> keep it simple :-). Then nothing else then the grub2 binary and
>> grub2-install is required usually.
> 
> Long-standing readers may remember that I have reasons for avoiding 
> grub-2.
> I still think it's a monstrosity and I'd much prefer never to have to
> wrestle with it again.
Now, AFAIK, grub2 wants to be a universal boot loader for different 
architectures against grub-legacy is for PC's only. If you still want to 
rely on grub-legacy it would be the best solution to take over the 
project or fork it.
> 
> On the other hand, I suppose I could have another go at writing my own
> grub.cfg, just for the one little Atom box, if only for a quiet life.

-- 
Sent with eQmail-1.10