grub-devel
[Top][All Lists]
Advanced

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

Re: grub-probe fails to find PC partition due to Apple disklabel


From: Robert Millan
Subject: Re: grub-probe fails to find PC partition due to Apple disklabel
Date: Mon, 14 Apr 2008 14:07:42 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

On Sun, Apr 13, 2008 at 05:34:50PM -0400, Chris Knadle wrote:
> Greetings.
> 
>    I've run into an interesting problem on a PC running Debian Sid (Linux) 
> where grub-probe fails to find partitions on the first hard disk because it 
> finds an Apple disklabel, causing the 'update-grub' program to fail and thus 
> not allow installing a new Linux kernel.  [The drive may at one time been in 
> an Apple or in an external drive enclosure used by both Apple and PC's 
> running Linux.]  The latest grub on Debian Sid now uses grub2 code for the 
> grub-common package, so even though the bug report is for grub 0.97-36, it's 
> using grub2 code.
> 
>       http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475718
> 
>    As far as I can tell, (and forgive me if my terminology is slightly off), 
> this boils down to the question of how to handle the situation where a disk 
> has multiple disklabels / partition maps from different architectures but 
> only has allocated partitions in one of the partition maps.
> 
>    Is there, or can we think of, a good way of handling this?

Hi Chris,

Initially, all partmaps were arch-specific, so that "pc" arch had msdos
and gpt partmaps, etc.  This avoided the problem;  so maybe what we could do
is probe for "native" partmaps first, and then for all the rest?  I can think
of two ways of doing this:

  - Explicitly probe for native partmaps for each arch (#ifdef MACHINE_BIOS,
    etc), then probe for all.  This is ugly and also inefficient (some partmaps
    are probed twice).
  - Change the partmap order in partmap.lst (can be complicated because of the
    build system), and make the prober follow the order in that file.  But, uhm,
    how would we access the file in the first place, before partmaps are probed?
    How does it work _now_ actually?

another way would be to add sanity checks in the prober, so that a partmap is
never identified as "good" when one of its partitions are out of bounds or so.
But then again:

  - Failing completely for an otherwise perfectly-sane partmap just because one
    partition is out of bounds sounds like a bad idea.
  - It doesn't completely fix the problem anyway.

Comments?

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)




reply via email to

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