Re: [gentoo-user] Re: A tiny titillating taste of grub2

[Dale]

walt wrote:
> On 01/09/2011 04:10 AM, Alan McKinnon wrote:
>> Apparently, though unproven, at 02:44 on Sunday 09 January 2011, Dale
>> did
>> opine thusly:
>>
>>> I have not tried grub2 yet but I did fine these:
>>>
>>> https://help.ubuntu.com/community/Grub2
>>> http://en.gentoo-wiki.com/wiki/Grub2
>>> http://grub.enbug.org/grub.cfg
>
> Thanks Dale, the ubuntu link may be what I need.
>
>> I don't quite agree with Volker's viewpoint but don't totally
>> disagree with
>> him either. grub2 has a whole whack of bloat all of it's own.
>
> Indeed it does, except for grub.info, which is not nearly complete.
>
>> Methinks a modular build system is in order here. Why should I build
>> support
>> for sparc when I know for a fact I'm building an x86 installer?
>
> Here is how I do that manually, FWIW. (I've not run the grub2 install
> scripts
> because I haven't read them yet, which makes me nervous in a boot
> loader :)
>
> $cd ~/src        #in my home directory, so I don't need root
> $tar -xvzf /usr/portage/distfiles/grub-1.98.tar.gz
> $cd grub-1.98
> $./configure --prefix=$HOME --disable-werror
> $make all install
>
> At this point grub2 has merely saved some files in your home
> directory, it
> has *not* messed with your boot sector or touched legacy grub in any way.
>
> $ls ~/bin/grub*
> /home/wa1ter/bin/grub-bin2h       /home/wa1ter/bin/grub-mkisofs
> /home/wa1ter/bin/grub-editenv     /home/wa1ter/bin/grub-mkpasswd-pbkdf2
> /home/wa1ter/bin/grub-fstest      /home/wa1ter/bin/grub-mkrelpath
> /home/wa1ter/bin/grub-mkelfimage  /home/wa1ter/bin/grub-mkrescue
> /home/wa1ter/bin/grub-mkfont      /home/wa1ter/bin/grub-script-check
> /home/wa1ter/bin/grub-mkimage
>
> $ls ~/lib/grub/i386-pc/
> acpi.mod       font.mod      linux16.mod        reboot.mod
> affs.mod       fs.lst        lnxboot.img        reiserfs.mod
> afs.mod        fshelp.mod    loadenv.mod        relocator.mod
> <dozens more grub2 modules snipped for brevity>
>
> That's where the bloat comes from, as you pointed out.  There are tons
> of those *.mod files you won't need, so the trick is to compile a list
> of them you *do* need, and then feed the list to grub-mkimage as
> described
> below.
>
> NOTE: I can't recall exactly why but the ata* modules conflict with some
> other modules, so *don't use them* unless you know what you are doing.
>
> Create a list of all grub2 modules:
>
> $ls ~/lib/grub/i386pc/*.mod > /tmp/modlist
>
> Now edit that file and delete any modules you know you don't need, e.g.
> I deleted reiserfs.mod and ntfs.mod and the raid*.mod because I don't
> use those items.  Don't touch anything you don't clearly recognize, but
> *do* delete ata.mod and ata_pthru.mod.
>
> Now it's time to build the grub2 binary executable:
>
> $~/bin/grub-mkimage -o /tmp/grub2bin `cat /tmp/modlist`
>
> Your file grub2bin is actually formatted as a tiny pseudo kernel, which
> your legacy grub can boot using the usual grub sytax:
>
> title try grub2
> root (hdX,X)
> kernel /tmp/grub2bin  (or wherever else you want to put it. NOTE: so far
>                        I've done nothing requiring root privileges :)
>
> That menu item will start a grub2 running so you can experiment with
> it all you want, but still use legacy grub to boot as you always do.
> (You won't yet have a menu file for grub2, so you will see only the
> usual grub command prompt instead of a menu.)
>
> The grub2 shell is a bit different, so you might want to type "set" to
> see what variables you can change, "ls" to see your disks, and of course
> hit the tab key when you don't know what else to type.
>
> Type "help search" for the real excitement.
>
> A few more grub2 differences: the 'linux' command replaces 'kernel' to
> load your (linux) kernel. 'multiboot' is used to load any true multiboot
> kernel e.g. NetBSD.  Not sure, but I think you still need to chainload
> the Windows booter -- sadly, I can't test it anymore :D
>
> One problem I encountered on my old amd32 machine is that I had to remove
> the USB-related grub2 modules or grub2 would crash while probing for
> disks.
> The newer amd64 machine works fine with the USB stuff included.  Dunno
> why.
>
> NOTE: if grub2 names your disks (ataN,N) instead of (hdN,N) that means
> you are using the ata* grub2 modules -- I haven't figured out how to make
> that configuration work yet.
>

This sounds about as complicated as lilo.  Is this going to end up like 
hal?  You know, so complicated that no one can use the thing and they 
have to start over again?

Dale

:-)  :-)