Bug 10489

Summary: 3Tb boot disk partitioning M3 x86_64 classical DVD new install
Product: Mageia Reporter: Tony Blackwell <tablackwell>
Component: InstallerAssignee: Thierry Vignaud <thierry.vignaud>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: Normal CC: andr999
Version: 3   
Target Milestone: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Source RPM: CVE:
Status comment:
Attachments: report.bug

Description Tony Blackwell 2013-06-11 11:03:06 CEST
Description of problem:I've previously used gdisk to partition additional 3Tb hard drives.

Installing M3 x86_64 on a new system with only a 3Tb drive, I don't find gdisk or anything else I recognise on the (classical) DVD to step aside and do the partitioning.  The usual graphical installer seems not to correctly manage this yet.
I've had some more tries.  I went into rescue mode on the install DVD, mounted a
> memory stick containing the gdisk binary and used it to partition the
> 3Gb drive (into 4 x 50Gb partitions, a small swap partition at the end
> and the rest a big space for future encryption).  Classic DVD install
> failed; corrupt reading of disk space.  Did same again; this time also
> formatted the destination partition from the rescue prompt.  Tried the
> install again, chose 'use existing partitions' and selected sda2 which
> I'd just formatted in the step above.  Chose not to format it again. 
> Install crashed immediately after 'looking at packages already
> installed', with the identical message: "Your system does not have
> enough space left for installation or upgrade (697 MB > -22 MB)"



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.


Reproducible: 

Steps to Reproduce:
Comment 1 Tony Blackwell 2013-06-11 11:12:21 CEST
Created attachment 4127 [details]
report.bug
Comment 2 Tony Blackwell 2013-06-11 11:21:31 CEST
I didn't see much of note in report.bug (attached) but note when generating it (from Ctrl-alt-F2) the following:

WARNING: GPT (GUID Partition Table) detected on /dev/sda'!  The util fdisk doesn't support GPT.  Use GNU Parted.

This was unexpected: I've had no trouble adding additional 3Tb disks to another mageia system using gdisk, but then went on to encrypt the single partition occupying whole of disk, so not the same as here.

I remember from other use of gdisk there was something about hybrid MBR/GPT.  I'm not sure where the current disk is in this regard - relevant??
Manuel Hiebel 2013-06-11 20:12:23 CEST

Assignee: bugsquad => thierry.vignaud

Comment 3 andré blais 2013-06-12 09:07:13 CEST
The initial error message indicates that sda2 wasn't properly formatted.
I always use the custom partitioning option, which lets me look at all the partitions available and ensure that they are mounted where I want.
I've never had problems reformatting an existing gpt partition for /
(starting with mdv, up to mga2.  Haven't tried mga3 yet.)
I don't usually format other partitions on install.

Please note :
1) gdisk writes/updates a gpt partition table on a disk, and not the more traditional mbr table as done by fdisk.
gdisk and fdisk do *not* format any partitions.

2) To format partitions, use a tool like gparted, which can also write/update a partition table, using gdisk (or fdisk) behind the scenes.

2a) There is an excellent cd called SysRescueCD, which can facilite preparing your disk, as well as recovering if Mageia doesn't quite work.
It contains gparted and gdisk and a number of other utilities, with man pages for most. 
Available at http://www.sysresccd.org/
It is dual 32/64 bit, writable to CD or USB key.

3) The error message in comment 2 indicates that the utility used was using fdisk instead of gdisk to create partitions.
Maybe because gdisk wasn't available, maybe because it didn't try to use gdisk.
There might have been some sort of mbr partition table defined ?

4) gdisk can create a "hybrid" gpt table, which simulates an mbr partition table for a few partitions.
This allows a non-gpt aware operating system, such as 32-bit ms-windows, to run on a dual-boot system.
If you don't want to dual-boot with a non-gpt aware operating system, there is no point in creating a "hybrid" table, which is non-standard, and risks being over-written by various utilities.  Mageia will only recognize the gpt table on such disks.
(The actual format of the partitions is not related to mbr/gpt.)

gdisk can also convert an existing mbr partition table to gpt (as long as there is enought free space at the end of the disk for the backup gpt table.)

hope this helps :)

CC: (none) => andre999mga

Comment 4 Tony Blackwell 2013-06-13 20:16:08 CEST
Appreciate the time and care taken in giving the above detailed answer.

Note that this install is on a brand-new Gigabyte (Haswell chip) UEFI system, with secure boot turned off.

Issue now fixed, but the elements in fixing it are worth going over.  In passing re your point 3, I note that the classical DVD installer always uses fdisk; it does not currently provide any other way and this needs fixing for Mageia4.

I finally did it all with gdisk.  I'm not sure but suspect my problems came from not having GPT partitions all aligned on 2048 boundaries???  GPT tries to do this, when I was making several 50Gb partitions, a 2.7 Tb partition then a bit of space for swap, I had previously ended the big partition on an arbitrary number.  

Now re-doing it all, I mounted a memstick with gdisk in install-disk rescue mode. I created a first tiny 1Mb partition, starting 1 Mb into the disk, then 4 50Gb partitions, a 2.7 Tb partition then swap.  when I created the last (swap) partition it adjusted the start to fit 2048 boundaries.  I then deleted and re-created the big prior partition, adjusting it's ending to just fit, so it too honored the 2048 boundary.

The secret in making it work was to stay right away from doing anything graphically in Mageia.  I created filesystems on my 50Gb partitions with 'mke2fs -j /dev/sda3' and so on, plus a first NTFS-3G partition using mkfs.ntfs.  To do anything with the partitions through MCC risks corrupting them but tends to fail anyway.  

Re-booting and doing the install, I selected 'Use existing partitions' and unchecked formatting the install partition to prevent overwriting my prior command-line formatting.  Install proceeded normally.  I took a gamble and used lilo on /dev/sda, expecting it to fail, but reboot worked almost perfectly; crashed the first time as lilo didn't like an fstab entry re the empty NTFS filesystem, but deleting this resulted in normal boot.  I had the impression that only Grub2 was going to be able to cope with UEFI but was pleasantly surprised that lilo could cope.  (enabling secure boot may change this?)

Remaining issue: fix all of this for M4.  Do I need to create a new bug?

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Comment 5 andré blais 2013-06-14 06:23:31 CEST
(In reply to Tony Blackwell from comment #4)
> Appreciate the time and care taken in giving the above detailed answer.

Thanks for your detailed feedback.  It will help me, particularly in installing mga3 for a friend on a new UEFI system.  (Who wants dual-boot, but prefers Mageia most of the time.)


> Note that this install is on a brand-new Gigabyte (Haswell chip) UEFI
> system, with secure boot turned off.
> 
> Issue now fixed, but the elements in fixing it are worth going over.  In
> passing re your point 3, I note that the classical DVD installer always uses
> fdisk; it does not currently provide any other way and this needs fixing for
> Mageia4.
> 
> I finally did it all with gdisk.  I'm not sure but suspect my problems came
> from not having GPT partitions all aligned on 2048 boundaries??? 

That shouldn't make any difference.  Linux doesn't care about alignement, and neither do mechanical disks.
(I understand that SSD disks can be affected, due to erase-before-write.)

...

> The secret in making it work was to stay right away from doing anything
> graphically in Mageia.  I created filesystems on my 50Gb partitions with
> 'mke2fs -j /dev/sda3' and so on, plus a first NTFS-3G partition using
> mkfs.ntfs.  To do anything with the partitions through MCC risks corrupting
> them but tends to fail anyway.  

The SysRescueCD I suggested works nicely as well.  It is Gentoo-based, comes with a convenient xfce graphical interface, as well as the command line, and all the partitioning/formatting tools required.
This lets using gparted to do all the partitioning and formatting (ext2/3/4, btfs, ntfs, etc).  
It defaults aligning to 1 MiB boundaries.
I have used the text tools directly as well.

> 
> Re-booting and doing the install, I selected 'Use existing partitions' and
> unchecked formatting the install partition to prevent overwriting my prior
> command-line formatting.  Install proceeded normally.  I took a gamble and
> used lilo on /dev/sda, expecting it to fail, but reboot worked almost
> perfectly; crashed the first time as lilo didn't like an fstab entry re the
> empty NTFS filesystem, but deleting this resulted in normal boot.  I had the
> impression that only Grub2 was going to be able to cope with UEFI but was
> pleasantly surprised that lilo could cope.  (enabling secure boot may change
> this?)

Nice to know.  I'll try lilo as well.  I think that grub2 is overkill.
I suspect that secure boot wouldn't work.  And don't think that it adds any significant protection, for Linux or dual-boot systems.

> 
> Remaining issue: fix all of this for M4.  Do I need to create a new bug?

Your call, but I would favour creating a new bug (enhancement) for that, with reference to this bug.
Also milestone mageia 4, when that becomes available.

Maybe propose that as a feature for Mageia 4 ?
That is one of the examples of an acceptable feature in the features policy page :
https://wiki.mageia.org/en/Features_policy
Comment 6 Tony Blackwell 2013-06-14 13:00:48 CEST
One thing I haven't achieved is encrypting the big partition on this disk.  Using cryptsetup.sh which relies on dm_crypt fails, with 'mount' reporting filesystem errors.  Haven't looked at this in detail yet.  Are there acccepted ways of encrypting partitions in a 3Tb disk?  

I've had no problems in the past encrypting a single partition occupying the _whole_ of a 3Tb disk using:
"
modprobe dm-mod
/usr/local/bin/cryptsetup.sh -c aes -h ripemd160 -y -b `blockdev --getsize /dev/
sdb1` create cryptvol1 /dev/sdb1
mount /dev/mapper/cryptvol1 /mnt/crypt1
"

(after building and installing hashalot-0.3)
but this crashes if I try to encrypt a _partition_ in the 3Tb disk

My need is for better encryption that will work on a partition.
Comment 7 Tony Blackwell 2013-06-15 21:21:55 CEST
I spoke too soon.  The error messages I get on first running the above script, before creating the encrypted drive, are different than in earlier Mageia versions, but if after running the above script I then go ahead and run 'mke2fs -j /dev/mapper/cryptvol1' it all works and re-running the above script mounts the encrypted partition.

It's pretty weak encryption by today's standards - I must look into stronger encryption.

This issue is resolved and closed.