Hi Michael, You are quick :-) Please understand I am all for removing this package.
FYI: creating grub-cd using image found in grub-rescue-pc package should save you in bad days. I merely presented facts. (I am not a maintainer of this package and have no control over this package.) On Sat, Dec 06, 2008 at 03:15:10AM +0100, Michael Renner wrote: > Osamu Aoki wrote: > > > At least this bug should be important (or wishlist) severity bug if we > > consider only the bug reported here. But I am happy to keep this as RC. > > Here is the situation: > > > > Although some of the way gnu-fdisk works (bug#504099) is not something I > > like, this Bug #504747 behavior of gnu-fdisk is normal and expected. > > Expected? By someone who is a systems developer with reference to EFI or > a HPUX/IA64 Windows administrator, maybe. I am a user on MacBook (Intel Macs) without fancy RAID things and with mere 80 GB. I am not an HPUX/IA64 user. > >From the users perspective (and I guess that i386 and amd64 are combined > well over 95% of the Debian installations out there) your statement is > of laughable ignorance. I am one of 95%. > I'll present some facts, please correct me if I'm wrong. > > *) As of now (12/2008) the amount of x86 commodity hardware which is > able to boot EFI is close to nil. commodity ... nil maybe but there are some Intel based MacBooks out there. It may not be a commodity white box but quite popular consumer product. > *) The tools/toolchains to prepare a clean disk to be able to boot EFI > on x86 do not exist or are highly experimental True. I use chain-loading from MacOS X partition having rEFIt as described in http://wiki.debian.org/MacBook/DebianInstallTutorial > *) Partitioning disks with MBR/MS-DOS Style partitioning isn't feasible > for RAID-Devices with 2 or more disks already due to it's 2TB addressing > limit and will become unfeasible for single Disks in 2009, with > Multi-Terabyte drives around the corner. You certainly have no commodity device and are expert admin using RAID. > *) Using the Code Area of the Legacy MBR of a GPT to load the second > stage of a bootloader is perfectly fine in the scenarios outlined above. For different reason, we MacBook user use Legacy MBR data to boot system using grub-pc (legacy MBR bootloader) since EFI does not work well per: http://wiki.debian.org/MacBook * grub-efi is in sid but it doesn't work as of 18 October 2008 (Bug: bug 429695 bug 427492). * elilo does not work (Bug: #376002) > *) The Lenny D-I will automatically use GPT partitioning when confronted > with block devices >= 2TB. I see. This is installer issue. Basically, you need to do similar thing as what we do on MacBook to workaround issues. Since partition happens before bootloader installation, I think issues of installer is not running gptsync to create hybrid partition. (See http://wiki.debian.org/MacBook/DebianInstallTutorial how we do we work around problem.) You have to do it manually. Basically, you are installing Debian to an hardware where Debian installer support is not perfect. This only affects very limited people. It is not RC in theory. (Again, I am for removing this package since it does not display GPT information properly and gives false sense.) > *) gnu-fdisk is a tool which is an alternative to fdisk, closely > imitating it's interface, not hinting on any fundamental differences > between it's predecessor or GPT. But when we are dealing with different beast such as GPT, we should not fake its situation almost as MBR. This is the thing most bad about gnu-fdisk. > I understand your reasoning behind the original behavior, but the > industry (and thusly the community) failed to pick up on EFI support. By > now time has caught up with us and we do have to do something about it. > Ignoring the situation won't make it go away. If your issue is with installer, please put it there. Please note important bug is not RC. | important: a bug which has a major effect on the usability of a package, | without rendering it completely unusable to everyone. Hybrid partition isuues are reported to partman-installer for MacBooks but I see no RAID issue. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475908 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=430011 > If you want to avoid a lot of unhappy users during the Lenny lifecycle > I'd suggest that you take this issue seriously and think about the > actual use case. People use your software, not reference > implementations. I'd be happy if there were any feasible alternatives, > but from what I've seen so far it seems as if we're all alone out in the > cold on this one. I guess if this problem is clearly identified as installer issue (partman?) then we should address this in release note so people with larger than 2TB RAID or already functioning MacOS X+Windows on MacBook. Also I think this is not just Debian problem. If you know other distro doing it right, please point it out. They may be using some patch to the libraries used by gnu-fdisk/parted. I general, new hardwares (be it huge disk space or new design), causes issues. They are not RC but quite annoying. > > "GNU parted" also wipes out MBR when editing GPT. Basically, running > > GPT managing software will reset and clean MBR record to the GPT used by > > EFI. > > So it fails identically for this use case ;). I do not know exactly what to expect on RAID case. I know it wipes MBR on MacBook. It only affects limited machine, at highest it is important bug. I hope these bug reports should save people with problem on lenny :-) Osamu PS: Lenny is in freeze. I do not expect such intrusive fix to address demands of extreme system to happen. There are other problem using grub-pc which seems to be left out from grub-install: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502446 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
