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.
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.
CC: (none) => marja11Version: 5 => CauldronWhiteboard: (none) => (MGA5)
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
Here's the link to the ddebug.log file: http://pastebin.ubuntu.com/15166371/
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.
I should also mention that I don't experience this issue in Ubuntu 15.10 if that matters somehow.
(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.
Status: NEW => UNCONFIRMEDEver confirmed: 1 => 0
Created attachment 7492 [details] Here's the report.bug.xz from a fresh installation
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.
I should also mention that I used boot-nonfree.iso to install Mageia 5 with.
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
CC: (none) => Wayne
Looks like bug #18666
CC: (none) => thierry.vignaudSee Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=18666
Summary: Some UEFI installations end up with Bad geometry error on /dev/sda4 => [GPT] Some UEFI installations end up with Bad geometry error on /dev/sda4
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
Keywords: (none) => NEEDINFO
Priority: Normal => HighSeverity: major => critical
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!
CC: (none) => max.augsburg
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
Closing
Status: UNCONFIRMED => NEWEver confirmed: 0 => 1
Really closing
Status: NEW => RESOLVEDResolution: (none) => FIXED
Using fdisk to delete the /home and /swap partitions and then make new ones does NOT make this issue go away.
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
I was looking for the ddebug.log in /tmp but it just doesn't exist.
(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.
Assignee: bugsquad => mageiatools
With the latest Mageia release I cannot reproduce my own bugreport so I'm therefore suggesting that this should be closed as RESOLVED FIXED. Anyone objecting to this?
Sounds good.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED