[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] ntldr support

From: Michal Suchanek
Subject: Re: [PATCH] ntldr support
Date: Fri, 7 Aug 2009 13:17:30 +0200

2009/8/7 Robert Millan <address@hidden>:
> On Wed, Aug 05, 2009 at 07:35:32AM +0200, Christian Franke wrote:
>> Vladimir 'phcoder' Serbinenko wrote:
>>> On Tue, Aug 4, 2009 at 9:27 PM, Robert Millan<...> wrote:
>>>> After thinking a bit about this, I don't think we want this command in
>>>> its current form.
>>>> The problem is it is misleading.  It leads the user to think it can load
>>>> ntldr as a standalone file, but in fact it is reading the PBR behind the
>>>> scenes.
>>> I don't think it's of any problem since ntldr uses this PBR only as
>>> superblock to identify the partition. As such I would rather consider
>>> this loading as a special case of passing $root, just the form of it
>>> is a bit weird
>> Agree.
>> A 'ntldr' or 'chainloader --ntldr' command is not mandatory. But it is
>> 'nice to have' because it allows to boot even if the boot code (6
>> sectors) in the area behind the PBR is not present for whatever reason.
>> See my previsions mail with the test case.
> Ok.  Should we settle with 'ntldr' or 'chainloader --ntldr'?  In either case,
> we should try making them share the code (with ifdef trick if necessary), but
> I'm not completely sure.  Will users be confused if they put ntldr in an
> unrelated partition and try to boot their Windows using it?  If ntldr may
> hang or crash because of it, then I would go for 'chainloader --ntldr' and
> if it fails with a nice error then 'ntldr'.
> Thoughts?

ntldr is a boot loader like any other and it needs its configuration
and support files to work. Without them it fails (not sure how) but
that is not unexpected.

The Microsoft code for loading ntldr is broken wrt disk geometry so
replacing the MS loader with a grub chainloader option might allow
booting a disk taken from a system where the BIOS interprets the disk
geometry differently. This needs some testing, though.



reply via email to

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