Bug 17796 - [GPT] Some UEFI installations end up with Bad geometry error on /dev/sda4
Summary: [GPT] Some UEFI installations end up with Bad geometry error on /dev/sda4
Status: REOPENED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
: High critical
Target Milestone: ---
Assignee: Mageia tools maintainers
QA Contact:
URL:
Whiteboard: (MGA5)
Keywords: NEEDINFO
Depends on:
Blocks:
 
Reported: 2016-02-19 19:22 CET by Kristoffer Grundström
Modified: 2017-01-07 10:45 CET (History)
4 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments
Here's the report.bug.xz from a fresh installation (357.20 KB, application/x-xz)
2016-02-26 02:01 CET, Kristoffer Grundström
Details

Description Kristoffer Grundström 2016-02-19 19:22:21 CET
The drakx-installer-stage2 for the UEFI installation seems to not being able to mount /dev/sda4 as EXT4 if you don't zero the disk between reinstallation attempts.

Apparently when you click Clear to delete all partitions on /dev/sda it doesn't always manage to zero the disk completely.

I used the following fix that's supposed to be working for this kind of error:

$fdisk /dev/sda

Command (m for help): d
Partition number (1-4): 4

Command (m for help): n
Partition type:
   p   primary (1 primary, 0 extended, 3 free)
   e   extended

Select (default p): p
Partition number (1-4, default 2): 2

Command (m for help): w

This is the step where it fails to write the changes.

I rebooted for the changes to apply, but I still end up with the same error.
Comment 1 Marja van Waes 2016-02-20 10:39:49 CET
changing version to cauldron, because this is an installer issue

adding (MGA5) on the whiteboard, because the issue was last seen in MGA5

@ Kristoffer

For bug reports about traditional installer, we do _always_ need installer logs
https://wiki.mageia.org/en/Triage_guide#Traditional_installer

If you can revert to the original state of your disk when you started installing, then please try to reproduce the problem in the same order as you did before.

When you get stuck before partitions are mounted for installation, the log you need to attach is  /tmp/ddebug.log
Please attach the logs in chronological order and, when attaching a log, tell exactly what you did before you got stuck there.

If you manage to get past diskdrake step, then you need 
/root/drakx/report.bug.xz after install, or, still during install, you can write report.bug to a USB-stick with the "bug" command as explained in the link above.
Comment 2 Kristoffer Grundström 2016-02-21 23:56:38 CET
Couldn't add the install.log as an attachment so I pasted the content at my pastebin account.

Here's the link: http://pastebin.com/sQQjtDuS
Comment 3 Kristoffer Grundström 2016-02-21 23:59:46 CET
Here's the link to the ddebug.log file: http://pastebin.ubuntu.com/15166371/
Comment 4 Kristoffer Grundström 2016-02-22 00:02:58 CET
I'm sorry to say, but I didn't get the mount problem during the first bootup as I had problems with during the previous installations, but I think I saw the error being noted in any of the files.
Comment 5 Kristoffer Grundström 2016-02-22 00:04:08 CET
I should also mention that I don't experience this issue in Ubuntu 15.10 if that matters somehow.
Comment 6 Marja van Waes 2016-02-22 11:57:31 CET
(In reply to Kristoffer Grundström from comment #2)
> Couldn't add the install.log as an attachment so I pasted the content at my
> pastebin account.
> 
install.log wasn't asked for

(In reply to Kristoffer Grundström from comment #3)
> Here's the link to the ddebug.log file: http://pastebin.ubuntu.com/15166371/

(In reply to Marja van Waes from comment #1)

> https://wiki.mageia.org/en/Triage_guide#Traditional_installer
> 
> If you can revert to the original state of your disk when you started
> installing, then please try to reproduce the problem in the same order as
> you did before.
> 
> When you get stuck before partitions are mounted for installation, the log
> you need to attach is  /tmp/ddebug.log

It became too large because you took the ddebug.log from a successful complete install. In this case, you should have attached /root/drakx/report.bug.xz after rebooting into your fresh install. 

Going by your ddebug paste, mounting /dev/sda4 on /home wasn't  problem:
(That's probably what you meant when you said:
> I didn't get the mount problem during the first bootup as I had problems with
> during the previous installations, but I think I saw the error being noted in
> any of the files.

No errors here:

* mount_part: device=sda4 mntpoint=/home isMounted= real_mntpoint= device_UUID=90bddfcd-f24d-4024-9d7c-019bd743a2f0
* mounting UUID=90bddfcd-f24d-4024-9d7c-019bd743a2f0 on /mnt/home as type ext4, options noatime,acl
* ext4 already loaded
* running: mount -t ext4 UUID=90bddfcd-f24d-4024-9d7c-019bd743a2f0 /mnt/home -o noatime,acl

and install continues fine.

Kristoffer, what we need is output from when mounting /dev/sda4 is impossible.

(and please attach your logs next time!)

Setting Status to UNCONFIRMED for now.
Comment 7 Kristoffer Grundström 2016-02-26 02:01:20 CET
Created attachment 7492 [details]
Here's the report.bug.xz from a fresh installation
Comment 8 Kristoffer Grundström 2016-02-26 02:05:02 CET
I didn't get any error to load the kernel into kdm the first time, but after the reboot (I got no visible mouse cursor on the desktop so I had to reboot to see if the issue remains) grub rebooted back into grub again so I had to add modprobe.blacklist=nouveau to be able to boot into kdm.

I just thought this information is useful with the report archive from the new installation.
Comment 9 Kristoffer Grundström 2016-02-26 02:06:55 CET
I should also mention that I used boot-nonfree.iso to install Mageia 5 with.
Comment 10 Wayne Sallee 2016-03-09 20:24:20 CET
I've run into the same problem. Booted up after installation, and got:
EXT4-fs (sda2): bad geometry: block count 13623088 exceeds size of device (13623084 blocks)

I had problems installing as can be seen at:
https://bugs.mageia.org/show_bug.cgi?id=17926
This other bug may or may not be related.

Wayne Sallee
Wayne@WayneSallee.com
Comment 11 Thierry Vignaud 2016-06-17 14:11:54 CEST
Looks like bug #18666
Comment 12 Thierry Vignaud 2016-06-24 15:20:48 CEST
Can you try with drakx v17.45 when it lands on your favorite mirror?
You can do a net install using install/images/boot-nonfree.iso

You can check stage2 is up to date on your mirror by checking install/stage2/VERSION
eg:
http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/install/images/boot-nonfree.iso
http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/install/stage2/VERSION
Comment 13 Max Perl 2016-07-01 17:06:15 CEST
Hello all,
I got the same error with the new sta1 DVD and can confirm that the bug is still unsolved.
As a workaround I shrinked the home partition and did run fsck /dev/sda4 manually after installation. Since then everything works!
Comment 14 Mageia Robot 2016-07-05 16:42:10 CEST
commit 767048570e8c44061cb0d6faf689698d3313870c
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Tue Jul 5 16:25:28 2016 +0200

    prevent GPT partition to use the 33 last sectors
    
    Resolves: mga#18666, mga#17796
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=767048570e8c44061cb0d6faf689698d3313870c

 Bug links:
   Mageia
      https://bugs.mageia.org/18666
      https://bugs.mageia.org/17796
Comment 15 Thierry Vignaud 2016-07-05 16:43:49 CEST
Closing
Comment 16 Thierry Vignaud 2016-07-05 16:44:15 CEST
Really closing
Comment 17 Kristoffer Grundström 2016-12-18 07:46:08 CET
Using fdisk to delete the /home and /swap partitions and then make new ones does NOT make this issue go away.
Comment 18 Kristoffer Grundström 2016-12-18 07:49:50 CET
I was looking for the ddebug.log in /tmp but it just doesn't exist.
Comment 19 Marja van Waes 2017-01-07 10:45:54 CET
(In reply to Kristoffer Grundström from comment #17)
> Using fdisk to delete the /home and /swap partitions and then make new ones
> does NOT make this issue go away.

(In reply to Kristoffer Grundström from comment #18)
> I was looking for the ddebug.log in /tmp but it just doesn't exist.

Note You need to log in before you can comment on or make changes to this bug.