[Mageia-discuss] partitioning bug

[andre999]

blind Pete a écrit :
> andre999 wrote:
>
>    
>> blind Pete a écrit :
>>      
>>> andre999 wrote:
>>>
>>>
>>>        
>>>> blind Pete a écrit :
>>>>
>>>>          
>>>>> David W. Hodgins wrote:
>>>>>
>>>>>
>>>>>
>>>>>            
>>>>>> On Fri, 06 Jul 2012 04:03:34 -0400, blind Pete
>>>>>> <0123peter at gmail.com>    wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>              
>>>>>>> Morgan Leijström wrote:
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>>>> It would also be interesting to know what other tools say.
>>>>>>>> gparted?
>>>>>>>>
>>>>>>>>
>>>>>>>>                  
>>>>>>
>>>>>>              
>>>>>>> Gparted looks pretty.  As far as I can see, gparted agrees
>>>>>>> with what I think things should look like.  Gparted and
>>>>>>> fdisk agree about the number of sectors.  (More than you
>>>>>>> get by multiplying CxHxS.)
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>> Interesting.  I guess it would be best to use 'hdparm -i /dev/sda|grep
>>>>>> LBAsects" to find out the number of sectors.
>>>>>>
>>>>>> Regards, Dave Hodgins
>>>>>>
>>>>>>
>>>>>>              
>>>>> [root at live ~]# hdparm -i /dev/sda | grep LBA
>>>>>     CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=1953523055
>>>>> [root at live ~]#
>>>>>
>>>>> Same number of sectors as gparted and fdisk report.  Number of heads
>>>>> and sectors per cylinder are just, "it's a big disk".  _Posssibly_
>>>>> number of cylinders gives a clue about how big.  H can be 63 or 255,
>>>>> depending on mood, and CxHxS should be a little less than max LBA.
>>>>>
>>>>> The situation just got worse.  The latest work arround is to lie
>>>>> about how big a sector is.  That is called "advanced" formatting.
>>>>>
>>>>>
>>>>>            
>>      
>>>> BTW, with all those partitions, I would convert your disk to GPT tables
>>>> instead of MBR, using gdisk.
>>>> (gdisk is in core.)
>>>>
>>>>          
>>> OK I have installed gdisk and will look at it.  How would you rate
>>> it for maturity?  And what else can recognize a gpt disk?
>>>        
>> I would say very mature, even when I started using it (under mdv 2010.0
>> or 2010.1)
>> The developer says the "hybid" option which simulates MBR for Msw is
>> risky, but even that I found very stable and predictable
>>      
> I let it loose on my test machine.  It has Lilo on the mbr.  Mageia 1
> with Grub in its root partition, Mageia 2 with Grub in its root
> partition, and Ubuntu 10.04.4 with Grub 2 in its root partition.
>
> Converting to gpt confused Ubuntu's Grub 2.
>
> Experimenting with a hybrid system, converting a primary
> to a logical, adding a new primary, and renumbering confused
> lots of things.
>
> It was only the test computer.
>
>    
>>> Grub?
>>>
>>>        
>> Yes, since 1.97 patched for GPT, as used in mdv and fedora (at least)
>> when I started using GPT.
>> Mageia has always used this version.
>>      
>>> Grub2?
>>>
>>>        
>> Definitely
>>      
> I managed to confuse it.  Posibly by having it installed in the
> root partition.

It might be because you had your "extended" partition at the beginning 
of the disk, and MBR disk partitions are numbered with the "primary" 
partions 1-4 and "extended" 5+.
Gdisk would normally number in disk order, but I'm not sure because I 
have always numbered in disk order with the "extended" partition at the 
end of the disk.  With gdisk it is easy to extend an extended partition 
to the end of disk with gparted (using a live cd such as systemrescueCD).
You can easily check what partition ordering is with gdisk.  (From 
systemrescueCD if necessary.)
In any case, both grub and grub2 can get confused sometimes when 
partition numbering changes.
It is only necessary to go into rescue mode on boot (from any Mageia 
boot cd/dvd, or systemrescueCD), and invoke grub to find the designated 
boot partition.
It gives you a grub prompt.  grub has somewhat cryptic but useful help.
(This may have changed under grub2, but I don't think so.)
>
>    
>>> Lilo?
>>>
>>>        
>> Not sure.  I think newer versions do.
>>      
> Mostly works.  The mbr code just jumps to a hardcoded sector
> address and loads the real code from what is normally /etc/map.
>    

Good to know.
>    
>>> The Mageia installer?
>>>
>>>        
>> I didn't have a problem.  I did an upgrade install from mdv2010.2 to
>> mga1, and could read the other partitions to set up fstab.
>> Sometime before mga1 was available, I had a problem which corrupted my
>> system, and made it unbootable.  It took me a while to get around that,
>> as I didn't want to loose my uncorrupted partitions.  I ended up fixing
>> it with SystemRescueCD (it contains a partition recovery tool called
>> testdisk.)  I was able to reinstall mdv.  I may have formatted / with
>> SystemRescueCD.  At that point I had a "hybrid" format simulating MBR
>> for systems not aware of GPT.
>>      
> Is there any option in the installer to turn the disk into a gpt disk?

I highly doubt it, if you mean converting an MBR disk to gpt.
I think gdisk must be used.  (or some other similar application.)
And a live cd or dvd, since you can't be using the disk during conversion.

If you're talking about completely reformatting the disk during 
installation, it might work.
When I first tried gpt, I was able to newly format empty usb drives as 
gpt, but I don't remember if I used the systemrescueCD or Mandriva.  (If 
Mandriva, then that should still work with Mageia.)
But working with secondary drives after installation doesn't mean it 
would necessarily work with the boot drive during installation.  (But it 
would be nice if someone tested ;) )

>>> Other installers?
>>>
>>> Other operating systems?
>>>
>>>        
>> According to what I have read, most other major distros handle GPT
>> nicely.  The Linux kernel does.
>> Msw 32-bit does not, but can work with gdisks' "hybrid" format, which
>> puts an MBR table at the end of the first sector (a space not used by
>> GPT).  It is a little tricky to set up, but initially I had it working.
>> Recently I haven't been bothered to get it working again.
>> Msw 64-bit is GPT-aware, but I have read that it works only on EFT
>> hardware, which has a special BIOS.  (Incompatible with Msw 32-bit.)  It
>> may be just that it is the default installation.
>> MacOS handles GPT, but I'm not sure of the restrictions if any.  Is was
>> an early adopter.
>> *BSD systems should handle GPT just like Linux.
>>      
>>>> It will make your disk more stable.
>>>> It uses a 128 partition table,with a backup table at the end of the
>>>> drive. No such thing as "extended" partitions.
>>>> It takes less space than the ms-compatible MBR partition tables.
>>>> The only trick is that you need to leave space for the backup table (34
>>>> 512-byte sectors).
>>>> If you change your mind, you can convert back painlessly.
>>>> I've used GPT for over 2 years, including converting back and forth a
>>>> few times at first.
>>>>          

Note that if a disk is first formatted as gpt, it can't be converted to 
mbr unless it has 4 or less partitions, or every partition after 
partition 3 (that is, any that would be in the extended partition) has 
enough empty space before it.  With the default config for mbr, that 
means 63 unallocated sectors before each "logical" partition.
>>>> To convert, you'll have to boot to a live disk, preferably with gdisk.
>>>> I use systemRescueCD for that. http://www.sysresccd.org/
>>>> The latest stable version is 379 Mib, usable from CD or USB key.
>>>> I don't know if a Mageia live cd, or Mageia DVD in rescue mode might
>>>> work.
>>>>
>>>>          
>>> In Mageia 1 the installer pulled it from the net rather than from
>>> the local iso, so it was not prepackaged.
>>>        
>> I installed mga1 from DVD.  This upgrade went very smoothly.
>>
>> I did have a problem changing partition parameters with diskdrake under
>> mga1, not long after installing it, shortly after mga1 was released.
>> Luckily I was testing things, so I didn't loose anything important.  But
>> everything was lost on the partition in question.  I then tried
>> reformatting the partition with diskdrake, and it wouldn't work.  I had
>> to use SystemRescueCD (with gparted).
>> I strongly suspect it was due to my having a "hybrid" format.  I think
>> that at least at that point, diskdrake (or whatever it uses) would see
>> the MBR table, and classify the disk as MBR.  While still getting the
>> partition location parameters from the GPT table.  (The simulated MBR
>> table puts most partitions in a large "foreign" partition.  The
>> corrupted partition was not in the MBR table.  And no other partition
>> was affected.)
>>
>> Note that I have never had a problem simply accessing (read or write) a
>> GPT partition on mdv or mga.
>>
>> Also, initially I used gdisk to format usb drives (but no hybrid MBR
>> table), and have never had a problem on those disks with diskdrake or
>> any other mdv or mga tools.
>>
>> BTW, I installed gdisk from upstream on mdv, and first imported gdisk to
>> Mageia.
>>      
>>>> Just in case you might be interested
>>>>
>>>>          
>>> I'm interested.
>>>        
>> You will probably find this interesting :)
>> http://en.wikipedia.org/wiki/GUID_Partition_Table
>>      
> Thanks.
>
>    
A further thought.  If you don't need MBR access on a gpt disk (in other 
words, don't have msw installed), it is better not to have a "hybrid" 
format.
That is, use the default gdisk format which creates an mbr table with a 
non-ms partition occupying the entire disk.  (To discourage 
non-gpt-aware systems from corrupting your disk.)
The gdisk site has some info for using non-linux gpt-aware partitions, 
in case you have any.

Regards :)

-- 
André