[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Low-level documentation
From: |
Andrey Borzenkov |
Subject: |
Re: Low-level documentation |
Date: |
Mon, 14 Apr 2014 07:39:54 +0400 |
В Sun, 13 Apr 2014 20:02:12 +0200 (CEST)
Fredrik Tolf <address@hidden> пишет:
> On Sat, 12 Apr 2014, Andrey Borzenkov wrote:
> >> Grub 2, on the other hand, seems to try to go the "user-friendly" way,
> >> with `grub-install' wanting to do all the work for me. This is fine, I
> >> guess, so long as the circumstances aren't too strange for it to work.
> >>
> >
> > Could you describe your configuration where grub-install fails?
>
> I can't say I have any case readily handy, or in fresh memory, but it has
> usually been in cases where I'm repairing a broken system. Things like,
> you know, having only one leg of a broken 0.9-metadata md mirror mounted
> raw, or moving a disk from a broken system to another system with the
> intention of moving it back, or having the device order out-of-whack due
> to bootable USB sticks being mounted, or using unusual filesystems or
> device remapping layers, or the like. Sometimes when the system is broken,
> I just don't want grub-install to go scanning devices.
>
grub-install does not scan devices.
I do not expect grub-install to fail in any of the above cases.
> More importantly, however, I'd just generally like to know what is going
> on. It is not very seldom that I find myself doing unusual things, like
> experimenting with the boot structure, or setting up systems in unusual
> ways due to various restrictions, or repartition disks later on, moving
> partitions around; and I'd like to be able to know and control just what
> happens.
>
> For instance, as you write about grub-bios-setup:
>
> > It tries to embed core.img into either post-MBR gap or reserved area on
> > partition if filesystem is known to have one. It the worst case it
> > gives you a rope to use file on filesystem directly. In all cases it
> > installs boot block (MBR or PBR) which points to the installed
> > core.img. That's all.
>
> To me, this raises such questions as:
>
> * How do I know whether and where it embeds core.img?
Based on device name you used when calling it.
> * How can I control the same?
> * How can I tell it which device to address?
You pass device name to grub-install.
> * The Texinfo manual tells me that boot.img merely loads the first sector
> of core.img. Does this mean that boot.img and core.img are both patched
> with their own sets of block lists and device numbers?
Boot block only knows first sector where core.img is located (may be a
couple more, do not remember). First part of core.img is disk loader
which reads the rest. So yes, in this sense they both are patched to
contain actual location.
> * What does the "--allow-floppy" option do, more precisely?
It modifies boot.img to accept floppy as boot device when it gets from
BIOS.
> * Maybe I'm just blind, but I still haven't found how core.img actually
> finds the configuration file once it boots.
In most general case - by executing small script embedded in core.img on
grub startup which searches for filesystem that contains configuration.
There is shortcut when grub-install knows that core.img is located on
the same physical disk - then it just records partition number.
> * Is there any more detailed information on exactly what the various
> choices for the --format option to grub-mkimage actually do?
>
Probably not in the form you expect it.
> If you're up for simply answering those questions, that's great. The thing
> is that I never really needed to ask them with grub-legacy, however.
The only thing you need to know about grub2 is grub-install (or
probably grub-mknetdir). It figures out everything you need
automatically and hides all gory details from you. It is there exactly
to avoid need for every user to become grub and boot expert.
> Is
> there no documentation available other than reading through the source
> code?
>
Do you volunteer to write and maintain this documentation?