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. >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'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. *) The tools/toolchains to prepare a clean disk to be able to boot EFI on x86 do not exist or are highly experimental *) 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. *) 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. *) The Lenny D-I will automatically use GPT partitioning when confronted with block devices >= 2TB. *) 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. I understand your reasoning behind the original behaviour, 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 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. > "GNU parted" also wipes out MBR when editting 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 ;). best regards, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
