does the chainloader command ever return?

does the chainloader command ever return?

[Loving, Kent]

[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

In all the grub config files I've scanned, chainloader is always the last command, which makes sense. But if there is an error in starting the chain load, does chainloader return with some error code?

I want a dual-boot system (windows XP/linux) that normally boots the windows XP partition, but if that partition is not yet loaded or horribly corrupted, I want grub to automatically boot the other (linux) partition.


Kent Loving
425-315-3043 (cell)
206-544-8038 (desk)

[-- Attachment #2: Type: text/html, Size: 2825 bytes --]

Re: does the chainloader command ever return?

[Colin Watson]

On Tue, Dec 06, 2011 at 08:47:55AM -0800, Loving, Kent wrote:
>    In all the grub config files I’ve scanned, chainloader is always the last
>    command, which makes sense. But if there is an error in starting the chain
>    load, does chainloader return with some error code?

The 'chainloader' command itself only loads the image into memory and
doesn't actually boot it (it will return an error if that fails).  The
thing that actually boots the image is the 'boot' command, which is
implicit at the end of a menu entry.  That will return an error if there
is some error that GRUB is capable of catching, which basically boils
down to memory handling errors.  If something goes wrong after GRUB has
handed over control, you're out of luck.

>    I want a dual-boot system (windows XP/linux) that normally boots the
>    windows XP partition, but if that partition is not yet loaded or horribly
>    corrupted, I want grub to automatically boot the other (linux) partition.

If 'chainloader' is unable to load the sector(s) you ask for from the
disk, then you can catch that in your configuration file and do
something else instead.  However, I rather suspect that this failure
mode is unlikely compared to the possibility that GRUB would be able to
load the sector but that it contains garbage, and in that case what will
probably happen is that GRUB will transfer control to garbage which will
do nothing sensible and hopefully halt the machine.  There isn't a whole
lot we can do about this; chainloading is a rather primitive boot
protocol with very little in the way of available error checking.

I suppose it might be possible to come up with some other way to check
the integrity of the Windows XP boot sector.  It might involve a custom
GRUB module.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: does the chainloader command ever return?

[Vladimir 'φ-coder/phcoder' Serbinenko]

>>     I want a dual-boot system (windows XP/linux) that normally boots the
>>     windows XP partition, but if that partition is not yet loaded or horribly
>>     corrupted, I want grub to automatically boot the other (linux) partition.
> I suppose it might be possible to come up with some other way to check
> the integrity of the Windows XP boot sector.  It might involve a custom
> GRUB module.
>
For the case of Windows we can do better than that: we can skip boot 
sector altogether and load ntldr/bootmgr directly thus bootsector 
problems other the ones which make partition unreadable (in which case 
you'll get an FS error) are irrelevant. ntldr/bootmgr isn't thoroughly 
checked and may be corrupted in which case we're back to running 
garbage. However it's much less likely for the file with given name on 
apparently intact FS to be corrupted than the sector 0 of a partition 
with unknown FS status. This problem isn't unique to ntldr/bootmgr but 
other payloads are affected as well to various degrees.
Whether doing more checks is warranted is unclear. Even perfectly 
correct image can fail because of corruption in other files or hw 
issues. While it's theoretically possible to simulate the whole boot to 
see if it fails, it's not practicable due to effort and boot time 
needed. Some simple checks would be good provided that they are fast and 
don't result in false negatives but are unlikely to make difference. 
Checksums and signatures are another story but unless it's maintained 
together with or inside the image, it's likely to fail on updates. We 
could check checksum and signatures on following payloads:
-Linux (CRC32)
-Solaris (ELF signature)
Something else?
However signature checking increases the dependencies of loader modules 
but it's probably small price to pay compared to the risk of loading and 
running damaged kernel.
Bottom line is: you can't check for sure that something will boot, at 
most you can check that it wasn't damaged after compilation.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko