[Top][All Lists]

[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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]