| 1 |
On 2017-12-07 15:22, Peter Humphrey wrote: |
| 2 |
> On Thursday, 7 December 2017 12:04:08 GMT Kai Peter wrote: |
| 3 |
>> On 2017-12-06 13:28, Peter Humphrey wrote: |
| 4 |
>> > On Sunday, 3 December 2017 15:12:21 GMT Mick wrote: |
| 5 |
>> >> On 03-12-2017 ,10:57:33, Peter Humphrey wrote: |
| 6 |
> |
| 7 |
> --->8 |
| 8 |
> |
| 9 |
>> > Sys-boot/grub-0.97-r17 compiled and installed all right, as a package, |
| 10 |
>> > but when I went to install it to the MBR I got an error complaining of a |
| 11 |
>> > mismatch or corruption in stage X. The wording was something like that, |
| 12 |
>> > and I forget the value of X. There was no mention of disk space, and the |
| 13 |
>> > boot partition is 2GB, so I think it's something else. |
| 14 |
>> > |
| 15 |
>> > Installing sys-boot/grub-static-0.97-r12 instead went smoothly, so I've |
| 16 |
>> > left it like that for the moment. |
| 17 |
>> > |
| 18 |
>> > Does the team think I should go back to grub-0.97-r17, take proper |
| 19 |
>> > records and file a bug report? |
| 20 |
>> |
| 21 |
>> I question if this makes sense for a masked ebuild. |
| 22 |
> |
| 23 |
> Masked? Not here, it isn't. |
| 24 |
In the meaning of 'keyworded': |
| 25 |
KEYWORDS="~amd64 ~x86 ~x86-fbsd" |
| 26 |
(Why i did know that this will be misunderstood?) |
| 27 |
|
| 28 |
Anyway, it's your choice to file a bug. |
| 29 |
> |
| 30 |
>> I'm curious about what was discussed until now. The issue seems to be |
| 31 |
>> quite simple to solve. |
| 32 |
>> |
| 33 |
>> The build fails but portage/gcc does give clear info in this case: the |
| 34 |
>> option "-nopie" have to be changed to "-no-pie". This option is set in |
| 35 |
>> 860_all_grub-0.97-pie.patch. Here is a diff: |
| 36 |
> |
| 37 |
> --->8 |
| 38 |
> |
| 39 |
> Yes, this has been made clear already, but it's not the problem I had. |
| 40 |
Didn't find it in this thread - my fault. Btw. kernels haven't to be |
| 41 |
stored in /boot necessarily - related to the posts of the size of the |
| 42 |
boot partition. And maybe related to your problem: the r17 ebuild |
| 43 |
differs by the use of patches heavily. |
| 44 |
> |
| 45 |
>> Maybe the easiest way is to create a new grub-patches package, but |
| 46 |
>> there |
| 47 |
>> are other ways to change this too. I'm expected the upstream will |
| 48 |
>> change |
| 49 |
>> this soon - within the remaining 5 weeks ;-). |
| 50 |
>> |
| 51 |
>> Another thing is I question that grub-legacy have to be rebuild at |
| 52 |
>> all. |
| 53 |
>> I'm pretty sure it is save to remove it from the world file or comment |
| 54 |
>> it out. |
| 55 |
> |
| 56 |
> Then the first emerge -c will remove it from the system. |
| 57 |
Does anybody run emerge -c blindly w/o reviewing the packages before? If |
| 58 |
yes compile it outside of portage. Or backup the required files, do |
| 59 |
emerge -c and restore the backup'd files afterwards. Or ... |
| 60 |
> |
| 61 |
>> Anyhow, upgrading to grub2 is IMHO the right way. There are some |
| 62 |
>> examples given in parallel threads how to write a grub.cfg by hand - |
| 63 |
>> and |
| 64 |
>> keep it simple :-). Then nothing else then the grub2 binary and |
| 65 |
>> grub2-install is required usually. |
| 66 |
> |
| 67 |
> Long-standing readers may remember that I have reasons for avoiding |
| 68 |
> grub-2. |
| 69 |
> I still think it's a monstrosity and I'd much prefer never to have to |
| 70 |
> wrestle with it again. |
| 71 |
Now, AFAIK, grub2 wants to be a universal boot loader for different |
| 72 |
architectures against grub-legacy is for PC's only. If you still want to |
| 73 |
rely on grub-legacy it would be the best solution to take over the |
| 74 |
project or fork it. |
| 75 |
> |
| 76 |
> On the other hand, I suppose I could have another go at writing my own |
| 77 |
> grub.cfg, just for the one little Atom box, if only for a quiet life. |
| 78 |
|
| 79 |
-- |
| 80 |
Sent with eQmail-1.10 |
Archives