| Summary: | Unable to install Mageia 6 sta2 UEFI. Mounting partition failed and unable to copy files to new root | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | André DESMOTTES <lebarhon> |
| Component: | Release (media or process) | Assignee: | ISO building group <isobuild> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | Normal | CC: | mageia, marja11, sysadmin-bugs |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Attachments: |
LC_ALL=C fdisk -l /dev/sda > fdisk.txt
journalctl -ab > journal.txt |
||
|
Description
André DESMOTTES
2016-12-13 15:31:46 CET
Created attachment 8766 [details]
LC_ALL=C fdisk -l /dev/sda > fdisk.txt
Created attachment 8767 [details]
journalctl -ab > journal.txt
There's a suspicious error message in the journal at the end of the processing of removing unwanted hardware support & locales: Dec 13 15:02:29 localhost kernel: urpme[3832]: segfault at 20 ip 00007efed1310d14 sp 00007ffd8a00e1a0 error 6 in libc-2.22.so[7efed1294000+1a9000] Although draklive-install logs a few more actions after that, it dies shortly afterwards. Could you try again, unchecking both boxes when asked if you want to remove unnecessary hardware support and locales, to see if this is the root of the problem, or just a red herring. CC:
(none) =>
mageia the message: "Mounting partition /dev/sda4 in directory /mnt/install/media/windows failed" show up before the boxes to uncheck, so it is always there. Although the second message show up after the boxes, it is always there as well and a click on OK makes the computer to reboot.
Marja Van Waes
2016-12-14 19:49:14 CET
CC:
(none) =>
marja11
Marja Van Waes
2016-12-14 19:49:33 CET
CC:
(none) =>
sysadmin-bugs This looks like two separate bugs to me. Unfortunately I can't reproduce either of them. 1) Mounting of Windows partition If you type mount /dev/sda4 /mnt as root in a terminal window, does that also fail? If not, what does mount | grep sda4 show. Do you have a working up-to-date cauldron installation on this machine? If so, are you able to mount and access the Windows partition in that? 2) Failure when starting to copy files I can't see any explanation for this. Do you have another USB stick you could try using, just to rule out a bad copy? (In reply to Martin Whitaker from comment #5) > This looks like two separate bugs to me. Unfortunately I can't reproduce > either of them. > > 1) Mounting of Windows partition > > If you type > > mount /dev/sda4 /mnt > > as root in a terminal window, does that also fail? If not, what does > > mount | grep sda4 > > show. > > Do you have a working up-to-date cauldron installation on this machine? If > so, are you able to mount and access the Windows partition in that? Bingo, It is a UEFI computer and can't install Mga6sta2 on it, sta1 was OK at its time but I deleted it for 5.1 and deleted it to try 6sta2. However, Fedora 24 and Ubuntu 16-04 are installed on this computer and they can't mount sda4, they say nothing during the boot, so I didn't noticed, but sda4 is not mounted. If I use mount in a console, the answer is "Windows is hibernated, refuse to mount ... mount the volume read-only..." With mount -r, I can mount and read sda4. FYI, Windows is not hibernated, it is a Win 10 technical preview I installed for free in the sole intention of writing and screenshoting the Mageia documentation about dual boot with Windows. Time limit of Technical preview is now over for a long time and it doesn't boot any longer, but so far it was still detected and correctly mounted by Grub and displayed by MCC. It was all I needed for my screenshots. What is strange, is that Fedora, LinuxMint, Mageia6sta1, Mageia5.1 didn't complain, only Mageia6sta2 Live, whereas Windows never rebooted between these tests. Will try Mageia6sta2 classical when a new one is released (doesn't boot on UEFI mode). > > 2) Failure when starting to copy files > > I can't see any explanation for this. Do you have another USB stick you > could try using, just to rule out a bad copy? It is the same USB stick that the one who succeeded to install Mageia6sta2 on another computer (Legacy mode) (In reply to André DESMOTTES from comment #6) > If I use mount in a console, the answer is "Windows is > hibernated, refuse to mount ... mount the volume read-only..." With mount > -r, I can mount and read sda4. Interesting. I thought about suggesting that, but when I tested it on my machine, there was a useful message in the journal at the point where it failed to mount, saying it was hibernated. > What is strange, is that Fedora, LinuxMint, Mageia6sta1, Mageia5.1 didn't > complain, only Mageia6sta2 Live, whereas Windows never rebooted between > these tests. Will try Mageia6sta2 classical when a new one is released > (doesn't boot on UEFI mode). Clearly something has changed, and we should try to fix the installer to cope with it. I'd expect you to see the same error with the classical installer (as it shares the same code for this step). > > 2) Failure when starting to copy files > > > > I can't see any explanation for this. Do you have another USB stick you > > could try using, just to rule out a bad copy? > > It is the same USB stick that the one who succeeded to install Mageia6sta2 > on another computer (Legacy mode) You can get a bad copy onto a USB stick (particularly as it gets older), just like you can get a bad burn on a CD/DVD. So I think it's worth another try. I can't think of anything else to suggest. I redid the installation taking the initiative to unmount Windows (sda4) at the partitioning step. This time, no error message and the installation went fine. What is strange is that we haven't the same result by unmounting sda4 after the first error message. Both problems were connected. Done with the same USB stick, I wanted a last try before changing it. Bug is resolved but not explained. Status:
NEW =>
RESOLVED Again, that's odd. I wondered whether there was a problem with going round the partitioning loop twice, so tried to test it on my machine by setting my Windows partition to hibernate, and then running the Live installer. That failed on mounting the Windows partition (although with a useful message in the journal), but on the second time round (after removing the Windows mount point), completed installation without any problem. So yes, definitely not explained :-( If you get the same problem with the Windows partition in the classic installer, I suggest opening a new bug for that - we should try to fix it. |