[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Fix grub-probe partition naming on FreeBSD
From: |
Grégoire Sutre |
Subject: |
Re: [PATCH] Fix grub-probe partition naming on FreeBSD |
Date: |
Sun, 13 Jun 2010 17:53:30 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100515 Icedove/3.0.4 |
Hi Colin,
The following patch is aimed at fixing this Debian bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585068
I've tested it on Debian GNU/kFreeBSD and it seems to be producing sensible
output now.
In another thread [1], it was observed that offsets are not absolute in
FreeBSD disklabels, whereas they are absolute in NetBSD disklabels.
I believe that find_partition_start is supposed to return absolute
offsets. Does DIOCGDINFO convert the on-disk label into absolute
offsets on FreeBSD?
The one glitch is that if you ask it to probe /dev/ad0s1a, it returns
(hd0,msdos1) rather than (hd0,msdos1,bsd1): this is because both /dev/ad0s1
and /dev/ad0s1a have the same start sector, and it just uses the first one
it finds. When I set prefix to (hd0,msdos1)/boot/grub, GRUB can read from
that perfectly well, so can I ignore this glitch on the basis that it
doesn't cause a practical problem?
We get a similar behavior on NetBSD. As I mentioned in [2], this may
have an impact when the kernel is (a) loaded with the multiboot
protocol, and (b) relies on the MBI boot_device field to find its
root -- which it shouldn't anyway, so it's not a big deal. I am not
aware of other impacts.
I know that hybrid msdos+gpt are not recommended, but, for the record,
I guess that another glitch could happen if /dev/ad0s1X (msdos) and
/dev/ad0p1Y (gpt) are actually the same partition: grub-probe would
return the same answer for both, thus ignoring the user's desire to use
a specific partitioning scheme. I believe that such a partitioning is
supported by FreeBSD, but I may be wrong (please tell me if so), I did
not test this myself.
Grégoire
[1] http://lists.gnu.org/archive/html/grub-devel/2010-05/msg00065.html
[2] http://lists.gnu.org/archive/html/grub-devel/2010-06/msg00075.html