Description of problem: I have windows 10 pre-installed on my 750GB Sata Hard disk with three partitions of 52GB, 300GB & 316GB. The Hard disk is a MBR disk.It's not formatted as a GPT disk. whenever i try to install mageia6stable 64 bit dvd iso through live usb after creating swap, root (/) and encrypted home (/home) the installer shows errors. First, the installer notifies that there must be a BIOS boot partition and don't let you continue any further. Then if you try to rerun the whole process of mageia partitioning again, it shows that mount point of your encrypted /home partition is set to /var and if you change it to /home again this time it formats the partition again and this time it prints: "An error occured mounting opartition UUID=4210A9AC10A9A77F in directory /mnt/install/media/win_c failed." And here i'm stuck. Although i have tried to install in UEFI mode by creating another extra 500MB fat32 partition mounted at /boot/EFI , this time the installer didn't report any error and it completed the installation flawlessly but during grub installation grub didn't find windows boot partition and after the installation i wasn't able to boot the installed mageia system; whenever i turned on my pc it directly boot into windows 10 as if there is no mageia installed and the whole booting process is done by windows boot manager there is no sign of grub. But when i had tried the same steps with Mageia 5.1 x86_64 bit live dvd it was a complete success. Even with a MBR paartitioned disk i was able to dual boot windows10 and mageia side by side without creating any extra EFI partition. This time The used partitions for mageia 5.1 x86_64 bit are swap, root(/), encrypted home (/home). So, it is clearly a bug with mageia6 stable x86_64 bit and i hope, you'll make it go away soon. Version-Release number of selected component (if applicable): 1.mga How reproducible: I have windows 10 pre-installed on my 750GB Sata Hard disk with three partitions of 52GB, 300GB & 316GB. The Hard disk is a MBR disk.It's not formatted as a GPT disk. whenever i try to install mageia6stable 64 bit dvd iso through live usb after creating swap, root (/) and encrypted home (/home) the installer shows errors. First, the installer notifies that there must be a BIOS boot partition and don't let you continue any further. Then if you try to rerun the whole process of mageia partitioning again, it shows that mount point of your encrypted /home partition is set to /var and if you change it to /home again this time it formats the partition again and this time it prints: "An error occured mounting opartition UUID=4210A9AC10A9A77F in directory /mnt/install/media/win_c failed." And here i'm stuck. Although i have tried to install in UEFI mode by creating another extra 500MB fat32 partition mounted at /boot/EFI , this time the installer didn't report any error and it completed the installation flawlessly but during grub installation grub didn't find windows boot partition and after the installation i wasn't able to boot the installed mageia system; whenever i turned on my pc it directly boot into windows 10 as if there is no mageia installed and the whole booting process is done by windows boot manager there is no sign of grub. But when i had tried the same steps with Mageia 5.1 x86_64 bit live dvd it was a complete success. Even with a MBR paartitioned disk i was able to dual boot windows10 and mageia side by side without creating any extra EFI partition. This time The used partitions for mageia 5.1 x86_64 bit are swap, root(/), encrypted home (/home). So, it is clearly a bug with mageia6 stable x86_64 bit and i hope, you'll make it go away soon. Steps to Reproduce: I have windows 10 pre-installed on my 750GB Sata Hard disk with three partitions of 52GB, 300GB & 316GB. The Hard disk is a MBR disk.It's not formatted as a GPT disk. whenever i try to install mageia6stable 64 bit dvd iso through live usb after creating swap, root (/) and encrypted home (/home) the installer shows errors. First, the installer notifies that there must be a BIOS boot partition and don't let you continue any further. Then if you try to rerun the whole process of mageia partitioning again, it shows that mount point of your encrypted /home partition is set to /var and if you change it to /home again this time it formats the partition again and this time it prints: "An error occured mounting opartition UUID=4210A9AC10A9A77F in directory /mnt/install/media/win_c failed." And here i'm stuck. Although i have tried to install in UEFI mode by creating another extra 500MB fat32 partition mounted at /boot/EFI , this time the installer didn't report any error and it completed the installation flawlessly but during grub installation grub didn't find windows boot partition and after the installation i wasn't able to boot the installed mageia system; whenever i turned on my pc it directly boot into windows 10 as if there is no mageia installed and the whole booting process is done by windows boot manager there is no sign of grub. But when i had tried the same steps with Mageia 5.1 x86_64 bit live dvd it was a complete success. Even with a MBR paartitioned disk i was able to dual boot windows10 and mageia side by side without creating any extra EFI partition. This time The used partitions for mageia 5.1 x86_64 bit are swap, root(/), encrypted home (/home). So, it is clearly a bug with mageia6 stable x86_64 bit and i hope, you'll make it go away soon.
Sorry, i forgot to mention the release version of the package. It is draklive-install-2.7-1.mga
Priority: Normal => HighTarget Milestone: --- => Mageia 6
I think the needless request for a BIOS boot partition was mentioned, too, in the "Keeping things easy" thread on QA-discuss ml Can you reproduce getting the request for a BIOS boot partition? If so, then please switch to a different VT, e.g. with ctrl+alt+F5, login with user name "live", and then do: su and journalctl -ab > journal.txt And attach journal.txt to this bug report. I don't know whether the 2nd issue needs a separate bug report, or whether it's better to wait until the first issue gets solved (maybe some corruption occurred when you had to quit the first install attempt?). The 3rd issue is invalid: UEFI installs require a GPT disk. Btw, writing one time what you want to tell is enough ;-)
CC: (none) => marja11Component: Installer => RPM PackagesAssignee: bugsquad => mageiatoolsSummary: mageia 6 dual boot with win10 on MBR disk (not GPT) => mageia 6 dual boot install with win10 on MBR disk (not GPT) requests BIOS boot partition
Created attachment 8765 [details] journalctl Here, is the output of "journalctl -ab" command.
(In reply to jyoti ban from comment #3) > Created attachment 8765 [details] > journalctl > > Here, is the output of "journalctl -ab" command. Thanks :-) The partition table type was correctly identified Dec 13 18:06:10 localhost draklive-install[2743]: found a dos partition table on /dev/sda at sector 0 Dec 13 18:06:10 localhost draklive-install[2743]: found a dos partition table on /dev/sdb at sector 0 Dec 13 18:06:12 localhost draklive-install[2743]: found a dos partition table on /dev/sda at sector 0 Dec 13 18:06:13 localhost draklive-install[2743]: found a dos partition table on /dev/sdb at sector 0 However, I do not see that you're told to create a BIOS boot partition. Is that because that error didn't reoccur, or did you see it again, but was it just not logged?
Yes, this time too i was told to create a BIOS boot partition and the installer looped back to the partition creation page again. Unfortunately, i wasn't able to take a screenshot of the screen at that time since, capturing the screen through "PrtScn" button wasn't functioning in the live environment. There is no doubt it is a bug and it is probably the fifth time i faced it. Although i don't know why it isn't logged. I have already spent enough time for this stupid bug but decided not to bother with cauldron any more. They are simply not going to work without problems.
FYI, my system uses AMD APU A4-5300.
(In reply to jyoti ban from comment #5) > Yes, this time too i was told to create a BIOS boot partition and the > installer looped back to the partition creation page again. Thanks a lot for the feedback and the logs! Btw, there is a chance that you can do a successful install if you partition and reboot before you start installing, see Pete's comment at the end of below quotes. (Quoting instead of linking to the ml archive, because I get a server error for ml.mageia.org now) From the QA-discuss ml: Op 13-12-16 01:47 CET Charles A Edwards wrote: > It cam also depend upon the file system you use. > If / is btrfs you will need a boot_bios partition or the grub2 > installation will fail even on a disk with msdos partition table. > > If / is xfs you will need a separate ext4 /boot > > > Charles And: On 13-12-16 05:04 CET Pete Larson wrote: > > > On 12/12/2016 07:43 PM, Dick Gevers wrote: >> On Mon, 12 Dec 2016 19:07:42 -0600, Bit Twister wrote about Re: >> [qa-discuss] Keeping things easy: >> >>>> So it seems Fedora is wrong needing a biosboot partition... >>> As I misunderstand it, grub2 requires a bios boot partition. >> :)) >> >> Okay, but if that is so, it should be needed by M6sta2 as well, but >> various Mageia installs succeed without creating new partitions. I use >> existing ext4 partitions and merely format those that M6 is going to be >> written to with diskdrake (the installer) and they remain ext4. >> >> Cheers, >> >> dvg >> > > > I do the same. If the partitions are already made, you don't get the > message that you have to create a BIOS boot partition. It came up for > me when I was trying to create additional partitions using Custom > Partitioning in the install. If you are saying this happened when you > installed Fedora, then it evidently isn't a Mageia problem but something > more widespread. I'm going to delete a couple partitions and test this > again. > > Pete
CC: (none) => pterjanSource RPM: draklive-install-2.7-1.mga6 => drakxtools
Madam, I followed your advice three times simultaneously and each time after the reboot when i used the previously created root (/) and home (/home) partition for the installation i was greeted with this error each time : "An error occured mounting of partition UUID=4210A9AC10A9A77F in directory /mnt/install/media/win_c failed." Now, I am convinced that it is not worth trying anymore. Thank you very much for your time and advice.
As Marja quoted me above, there is no problem seen if partitions are made before the install. The error occurs when using Custom Partitioning within the install. The new partitions do get written to the disk but then there is the message that you can't continue unless you create a BIOS boot partition. I believe I've gotten the error even when I HAD previously made a BIOS boot partition. Selecting that partition and designating it as BIOS boot partition allows the sequence to continue back into the install. I will retest this point. Of course it is easy enough to just create a new BIOS boot partition of a couple MB and set the type and continue. Still, it should be fixed so it isn't discouraging new users. It seems there is code that just gives the error message no matter what the disk partition type, dos or gpt. If in fact it is necessary to have a BIOS boot partition for overflow writing area for grub 2, then the text should state that instead of seeming to misidentify a dos partition as gpt.
CC: (none) => petel123123
Priority: High => release_blocker
I just verified this bug shows up regardless if a BIOS Boot partition has been previously made. It seems the "can't continue" message is coded to pop up every time Custom Partitioning is used in drakdisk in the installer. There also is no option to back up to the previous partition options page to maybe select to use existing partitions.
I have another option you can try that I just used yesterday for an i586 boot.iso install. You will need to have access to a full featured partitioning program such as gparted. Use that to create and format partitions to be used by / and /home. Once that is applied and completed select the partition to be used as / and add the flag 'boot'. In gparted that is done by "Manage Flags' and select 'boot' from the drop down menu and you are done. You can verify by looking to the far right of the gparted window under Flags and you will see boot on the line showing /. You can now run the Mga6 install. At the partition stage select "use existing partition" select the mount points and it should sale through to pkg selection. If you choose Custom partitioning select your mount points but Make No Changes To the / Partition, you can change /home or even add partitions just leave / alone. Click done and it should proceed to mounting your partitions and pkg selection.
CC: (none) => cae
Created attachment 8798 [details] partitioning step part of ddebug.log I just hit this with a 32bit install, using the QA pretesting traditional iso of December 16. I had used custom partitioning with the exact same iso on the exact same hardware before, but this was the first time I resized a partition and created a new one. Attaching the relevant part of the ddebug.log.
Hardware: x86_64 => All
Summary: mageia 6 dual boot install with win10 on MBR disk (not GPT) requests BIOS boot partition => Custom disk partitioning requests BIOS boot partition on non-GPT disk
Hmm, I should not have chosen to create a Bios boot partition and continue. After reboot, booting into any partition is impossible. When I try to solve it by installing again, I get an error that the partition table of sda is too corrupted to read :-(
When I run sfdisk -d on that disk, I get an error about the extended partition not starting at a cylinder boundary.
I hit this same destruction of my partition table in exactly the same way last night. I first thought maybe it was because I was using a hard disk that had sat idle for some months. I had previously already thought my newly created partitions were not reported correctly after making them and looking at them again later. Not only that but I create new partitions as ext4 but then I saw that after the fact they were ext2 and actually Gparted showed them as "unknown type". So, last night I wiped the drive and created a new msdos partition table and did a new install of M6-64 classical on partitions made with Gparted. I just raised the severity to major. This is a serious blocker. It seems to have come along with changes to transition more into EFI usage.
Severity: normal => major
Comment 14 showed up as I wes typing 15. Yes, it does seem there is genuine damage being done to partition boundaries. In Gparted, it looks like a mess.
Summary: Custom disk partitioning requests BIOS boot partition on non-GPT disk => Custom disk partitioning requests BIOS boot partition on non-GPT disk, creating one and continuing leads to a corrupted partition table and thus unusable disk.
Severity: major => critical
*If* the corrupted partition table has the same cause as the "You need a BIOS boot partition" message, then 6sta1 users risk borking their disk, too. The journal logs of the reporter of bug 19935 shows: Dec 13 22:26:26 localhost kernel: Linux version 4.6.3-desktop-1.mga6 (iurt@rabbit.mageia.org) (gcc version 5.4.0 (GCC) ) #1 SMP Sat Jun 25 11:20:38 UTC 2016 Dec 13 22:26:26 localhost kernel: Command line: automatic=method:cdrom initrd=/boot/cdrom/initrd.gz root=mgalive:LABEL=Mageia-6-PLASMA5-LiveDVD splash quiet noiswmd rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 vga=788 Does anyone know whether it is likely to be one and the same issue, or whether it is better to file a separate report for the borked partition table?
CC: (none) => ennael1
s/bug 19935/this bug/ ;-)
Created attachment 8804 [details] GParted's view of the disk and its partitions I managed to start a LiveGnome6sta2 DVD on that laptop, and have a look with GParted. (My previous look was with a Mageia 1 CD) It doesn't match "fdisk -l", which is still the same as "fdisk after" during install (for reference pasted below): fdisk after: Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 6184079 6182032 3G b W95 FAT32 /dev/sda2 6186978 78140159 71953182 34.3G 5 Extended /dev/sda5 6187008 6199199 12192 6M 0 Empty /dev/sda6 6217728 12458879 6241152 3G 83 Linux /dev/sda7 12462080 22740479 10278400 4.9G 83 Linux /dev/sda8 49430528 52345439 2914912 1.4G 82 Linux swap / Solaris /dev/sda9 22743040 49427279 26684240 12.7G 83 Linux /dev/sda10 52348928 78140159 25791232 12.3G 83 Linux In Gparted, the Bios boot partition, sda5 in "fdisk -l" is _missing_, the other partitions were renumbered and there is no sda10. Many partitions are wrongly identified, e.g. what "fdisk after" saw as: /dev/sda9 22743040 49427279 26684240 12.7G 83 Linux /dev/sda10 52348928 78140159 25791232 12.3G 83 Linux is now seen as swap partitions Attaching a screenshot I suppose no more information is needed, so that I can either try to fix the partition table, or wipe the entire disk?
(In reply to Marja van Waes from comment #19) > /dev/sda5 6187008 6199199 12192 6M 0 Empty I suggest to you that after creating the partition, you should have set the bios boot flag. fdisk -l /dev/sda result example from my system Device Start End Sectors Size Type /dev/sda10 1471924224 1472983039 1058816 517M BIOS boot Using gdisk -l /dev/sda would show Number Start (sector) End (sector) Size Code Name 10 1471924224 1472983039 517.0 MiB EF02
CC: (none) => bittwister2
(In reply to Bit Twister from comment #20) > > I suggest to you that after creating the partition, you should have set the > bios boot flag. > I chose "Bios boot" or whatever it's exactly called, from the drop down list in diskdrake in installer. That would have taken care of that flag if this were a GPT partitioned disk.
(In reply to Bit Twister from comment #20) > (In reply to Marja van Waes from comment #19) > > > /dev/sda5 6187008 6199199 12192 6M 0 Empty > > I suggest to you that after creating the partition, you should have set the > bios boot flag. > > fdisk -l /dev/sda result example from my system > Device Start End Sectors Size Type > /dev/sda10 1471924224 1472983039 1058816 517M BIOS boot > > Using gdisk -l /dev/sda would show > Number Start (sector) End (sector) Size Code Name > 10 1471924224 1472983039 517.0 MiB EF02 We need to keep the distinction clear here. BIOS boot partition seems to only be good for a GPT disk. The BIOS boot flag seems to be what is causing a msdos partitioned disk to lose its structure and sanity. I'm thinking that for dos table disks we want a couple MB of empty space before the first partition as extra room for Grub 2 and nothing else (based on what I'm reading about Grub2 and still unclear to me). Definitely not a BIOS Boot partition for msdos disks.
@ tmb In reply to your question in the QA-team meeting: 2016:12:22:21:20 < lewyssmith> tmb: The disc corruption thing is a bit deadly to let out to the public. I have forgotten what platforms it happens on. 2016:12:22:21:20 < tmb> lewyssmith, what disc corruption ? Disc corruption that happens on *msdos* partitioned disks, on both 32- and 64-bits systems. When using the "Custom partitioning" option and creating one or more partitions, when you try to continue there's a message that a BIOS boot partition is needed. It is impossible to continue without creating one. However, if you do create one, by freeing up some MBs of space and selecting BIOS boot from the dropdown list in diskdrake in installer, then it is impossible to reboot into any partition after install. fdisk shows the BIOS boot partition as /dev/sda5 6187008 6199199 12192 6M 0 Empty and gparted and fdisk disagree about the number of available partitions It happens both with Live and with classical installs. Sorry for not having CC'ed the isobuild group before
CC: (none) => isobuild, tmb
(In reply to Marja van Waes from comment #23) > > It happens both with Live and with classical installs. > "It" = "Getting told to create a BIOS boot partion on an msdos partitioned disk". I'm not sure anyone actually tried doing that during a Live install, instead of aborting the install.
Adding bug 19888 (Autopartitioner doesn't account for required BIOS boot partition for GPT MBR disks) to the "See Also:", because that bug will probably need to be fixed at the same time as this one.
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=19888
Created attachment 8830 [details] Miscellaneous debug output It looks like we have two or three separate bugs here: - incorrectly requiring a BIOS boot partition on a non-GPT disk - failing to correctly identify or mount partitions after creating a BIOS boot partition - generating an invalid partition table after creating a BIOS boot partition The second and third items may well have the same root cause. I've reproduced at least some of this in VirtualBox, using the 6sta2 64-bit Live GNOME ISO and a 20GB virtual disk drive. I started by creating a 3GB FAT32 primary partition: Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 6329609 6327562 3G b W95 FAT32 I then ran draklive-install, selected custom partitioning, and created a ~3GB swap partition followed by a ~17GB ext4 root partition, filling the remaining space. This resulted in the message You must have a BIOS boot partition for non-UEFI GPT-partitioned disks. As can be seen in the attached file, this is not a GPT partitioned disk. I then deleted the swap partition and created a 7MB BIOS boot partition followed by a ~3GB swap partition in the freed space. draklive-install proceeded to format the root partition, then halted with the message INTERNAL ERROR: unknown device sda7 (followed by trace information, which can be seen in the attached file). fdisk shows Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 6329609 6327562 3G b W95 FAT32 /dev/sda2 6332382 41929649 35597268 17G 5 Extended /dev/sda5 6332416 6345674 13259 6.5M 0 Empty /dev/sda6 12871680 41929649 29057970 13.9G 83 Linux /dev/sda7 6348800 12868064 6519265 3.1G 82 Linux swap / Solaris but checking /sys/block/sda shows start size sda1 2048 6327562 sda2 6332382 2 sda5 12679168 29250482 sda6 6348800 6326485 which is clearly wrong. Looking in the journal, for the 2nd partitioning attempt I see tell kernel del (sda 5 ) force_reboot= rebootNeeded= tell kernel del (sda 6 ) force_reboot= rebootNeeded= tell kernel add (sda 5 12871680 29057970) force_reboot= rebootNeeded= tell kernel add (sda 5 6332416 13259) force_reboot=1 rebootNeeded= tell kernel del (sda 5 ) force_reboot=1 rebootNeeded= tell kernel add (sda 6 12871680 29057970) force_reboot=1 rebootNeeded= tell kernel add (sda 7 6348800 6519265) force_reboot=1 rebootNeeded= running: udevadm control --start-exec-queue tell kernel force_reboot (sda), rebootNeeded= running: udevadm settle inotify_add_watch(9, /dev/sda7, 10) failed: No such file or directory It looks like the problem is that when I deleted the swap partition, sda6 was renumbered sda5, then when I added the BIOS boot partition, sda5 was renumbered back to sda6, but only after the BIOS boot partition was added as sda5. I guess the kernel got confused by having two sda5 partitions.
CC: (none) => mageia
Created attachment 8833 [details] Patch to fix ordering when telling kernel to add/delete partitions It appears the kernel can handle the out-of-order partition add/delete requests. I guess it keeps a list of partitions, and doesn't check for duplicates. But if you want to fix this anyway, the attached patch does the job. The real problem is that the BIOS boot partition is given the Empty partition type. In some places Empty partitions are assigned partition numbers, in other places they aren't, so the drakx view of partition numbers gets out of step with the kernel. This doesn't just apply to drakx; when booting or when using the partx command to reload the kernel partition table, Empty partitions get assigned partition numbers, but when using the partprobe command to reload the kernel partition table, they don't. @tmb, I'm guessing this is a change in the kernel behaviour and that partprobe is lagging behind. Is there a searchable archive of kernel change logs somewhere, so I could check this.
Created attachment 8834 [details] Patch to fix detection of whether a BIOS boot partition is required This fixes the bug that causes a BIOS boot partition to be required when using custom partitioning on a non-GPT disk. This will of course just mask the partition table corruption bug, not fix it.
Keywords: (none) => PATCH
(In reply to Martin Whitaker from comment #28) > Created attachment 8834 [details] > Patch to fix detection of whether a BIOS boot partition is required > > This fixes the bug that causes a BIOS boot partition to be required when > using custom partitioning on a non-GPT disk. This will of course just mask > the partition table corruption bug, not fix it. Great, thanks Martin :-) (In reply to Martin Whitaker from comment #27) > Created attachment 8833 [details] > Patch to fix ordering when telling kernel to add/delete partitions > > It appears the kernel can handle the out-of-order partition add/delete > requests. I guess it keeps a list of partitions, and doesn't check for > duplicates. But if you want to fix this anyway, the attached patch does the > job. I don't understand exactly what that patch does. Would it renumber a "restore partition" sda3 at the end of a disk, if more than 3 partitions are present? > > The real problem is that the BIOS boot partition is given the Empty > partition type. In some places Empty partitions are assigned partition > numbers, in other places they aren't, so the drakx view of partition numbers > gets out of step with the kernel. @ papoteur Had you just created an empty partition when you hit partition table corruption after _not_ creating a BIOS boot partition?
(In reply to Marja van Waes from comment #29) > I don't understand exactly what that patch does. Would it renumber a > "restore partition" sda3 at the end of a disk, if more than 3 partitions are > present? First, just to be clear, this renumbering only changes how the kernel assigns device names to the partitions (e.g. sda5, sda6, etc.) - it does not change the disk partition table in any way. And it only applies to the logical partitions within an extended partition. When the kernel initially reads the partition table, it assigns the device names in sequence to the logical partitions as they appear in the extended partition table. So say you start with two logical partitions, assigned to sda5, sda6. If you now split sda5 into two partitions, when the kernel next reads the partition table it will find three partitions and assign them to sda5, sda6, sda7. Rather than tell the kernel to reread the entire partition table, the drakx tools issue a sequence of partition add/delete commands. So after making the above change, the following sequence would be emitted: add sda6 - this is the new sda6 del sda6 - this is the old sda6 add sda7 I thought the partition table corruption was being caused by adding the new sda6 before deleting the old one, so my patch changes the sequence to del sda6 - this is the old sda6 add sda7 add sda6 - this is the new sda6 It turns out this wasn't the problem, but it might protect against future kernel changes.
Thanks for the explanation, Martin. That takes away the doubt I had :-) Now really CC'ing papoteur, and reasking the question > @ papoteur > Had you just created an empty partition when you hit partition table corruption > after _not_ creating a BIOS boot partition? (We'll need to clone this report for the partition table corruption, anyway, regardless of whether you remember.... will do so asap, if no one beats me to it.)
CC: (none) => yves.brungard_mageia
Comment on attachment 8833 [details] Patch to fix ordering when telling kernel to add/delete partitions This is breaking the calls to will_tell_kernel() without the optional $o_delay parameter. See 'delay_del' & 'delay_add' in that same file I think will_tell_kernel() should keep sg like this at its end: if (!$o_delay) { will_tell_kernel_delayed($hd); } Also you might want to describe more the change in the commit log
CC: (none) => thierry.vignaud
@Pascal: WDYT?
(In reply to Thierry Vignaud from comment #32) > Comment on attachment 8833 [details] > Patch to fix ordering when telling kernel to add/delete partitions > > This is breaking the calls to will_tell_kernel() without the optional > $o_delay parameter. I don't think so (and I have tested it ;-) ). What currently happens is that calls to will_tell_kernel() with a $o_delay parameter put their delete or add operations in the temporary lists $hd->{will_tell_kerneldelay_del} or $hd->{will_tell_kerneldelay_add}. The next call to will_tell_kernel() without a $o_delay parameter moves the contents of these temporary lists to the end of the $hd->{will_tell_kernel} list. Calls to will_tell_kernel() without a $o_delay parameter put their operation directly in the $hd->{will_tell_kernel} list, so don't need a call to will_tell_kernel_delayed(). We could do it a different way. Change will_tell_kernel() to: - add all delayed delete operations to $hd->{will_tell_kernel} - add requested operation to $hd->{will_tell_kernel} - add all delayed add operations to $hd->{will_tell_kernel} That's a bit simpler and should achieve the same thing.
@marja I encountered a similar problem years ago, but didn't know how to explore it without crashing again the disk. Thus, I never reported it. I don't remember if I used empty partition. For what I remember, it was something like replacing one partition in the extended by two.
@ papoteur Thx for replying. I hadn't understood you hit that years ago. @ all I've created a separate report for the partition table corruption issue, bug 20074
Summary: Custom disk partitioning requests BIOS boot partition on non-GPT disk, creating one and continuing leads to a corrupted partition table and thus unusable disk. => Custom disk partitioning requests BIOS boot partition on non-GPT disk
Note that my second patch only fixes the request for a BIOS boot partition when using custom partitioning. When automatic partitioning is used, an unnecessary BIOS boot partition is still created.
(In reply to Martin Whitaker from comment #37) > Note that my second patch only fixes the request for a BIOS boot partition > when using custom partitioning. When automatic partitioning is used, an > unnecessary BIOS boot partition is still created. No one reported partition table corruption after automatic partitioning, afaik. Which Type does the unnecessary BIOS boot partition get, there?
(In reply to Marja van Waes from comment #38) > No one reported partition table corruption after automatic partitioning, > afaik. Which Type does the unnecessary BIOS boot partition get, there? It gets the same "Empty" type. But in the tests I've done, drakx's view of the partitions stayed in sync with the kernel, so wouldn't cause corruption. My guess is that it is going back and inserting a BIOS boot partition that triggers that particular problem.
(In reply to Martin Whitaker from comment #27) > > @tmb, I'm guessing this is a change in the kernel behaviour and that > partprobe is lagging behind. Is there a searchable archive of kernel change > logs somewhere, so I could check this. If it's a kernel change that has introduced this, it's easy to check. boot with mga5 or mga5.1 boot.iso, but point it to load stage2 from cauldron. that gives either a 3.19.8 or a 4.4.30 kernel loaded before stage2 partitoning loads up...
(In reply to Thomas Backlund from comment #40) > If it's a kernel change that has introduced this, it's easy to check. > > boot with mga5 or mga5.1 boot.iso, but point it to load stage2 from cauldron. > > that gives either a 3.19.8 or a 4.4.30 kernel loaded before stage2 > partitoning loads up... OK, if it's a kernel change, it's a very old one. I went back to mga2, and for [root@localhost live]# fdisk -l /dev/sda ... Device Boot Start End Blocks Id System /dev/sda1 * 2048 4225094 2111523+ b W95 FAT32 /dev/sda2 4229064 41929649 18850293 5 Extended /dev/sda5 4229120 4241159 6020 0 Empty /dev/sda6 4243456 36178379 15967462 83 Linux /dev/sda7 36182016 41929649 2873817 82 Linux swap / Solaris on boot the kernel creates all 5 sda devices, but running partprobe reduces it to 4 (skipping the empty partition) and before running partprobe, diskdrake gets the partition->device allocation wrong.
commit 4f939b68055c7c3e3b9ee50bbd79f6d0c415f235 Author: Martin Whitaker <mageia@...> Date: Wed Jan 4 11:43:26 2017 +0000 Fix bug in detecting whether a BIOS boot partition is required (mga#19935). --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=4f939b68055c7c3e3b9ee50bbd79f6d0c415f235
Thanks for the patches I applied one, looking at the ordering one now
(In reply to Pascal Terjan from comment #43) > Thanks for the patches > I applied one, looking at the ordering one now May not be worth spending too much time on that one. I think I may have found a way to fix bug 20074, which involves leaving the kernel to automatically rescan the partitions rather than trying to tell it what's changed.
That code is really not clear :( So currently when deleting an extended partition it does: assign_device_numbers($hd); will_tell_kernel($hd, del => $part); assign_device_numbers enqueues the changes for everything renumbered into delay_del/delay_add will_tell_kernel then tells the kernel to delete the one we want to delete, then to delete the renumbered ones and then add them again So for example if we have sda5, sda6, sda7 and delete sda5 it will tell: del sda5 del sda6 del sda7 add sda5 (old sda6) add sda6 (old sda7) This looks correct Now when adding an extended partition it does: assign_device_numbers($hd); will_tell_kernel($hd, add => $part); So if we add a partition between sda5 and sda6 it will tell: (resizing sda5) del sda5 add sda5 (adding new sda6) add sda6 (but there is already an sda6 with different limits, I guess this is ignored? or fails? or corrupts things?) del sda6 del sda7 add sda7 (old sda6) add sda8 (old sda7) So yes this looks quite wrong
(In reply to Martin Whitaker from comment #34) > We could do it a different way. Change will_tell_kernel() to: > > - add all delayed delete operations to $hd->{will_tell_kernel} > - add requested operation to $hd->{will_tell_kernel} > - add all delayed add operations to $hd->{will_tell_kernel} > > That's a bit simpler and should achieve the same thing. After understanding the code, that's what I thought of doing :)
(In reply to Pascal Terjan from comment #46) > (In reply to Martin Whitaker from comment #34) > > We could do it a different way. Change will_tell_kernel() to: > > > > - add all delayed delete operations to $hd->{will_tell_kernel} > > - add requested operation to $hd->{will_tell_kernel} > > - add all delayed add operations to $hd->{will_tell_kernel} > > > > That's a bit simpler and should achieve the same thing. > > After understanding the code, that's what I thought of doing :) Hmm actually no, reading again what I thought was quite different: doing the requested delete before the delayed ones, like now doing the requested add after the delayed ones instead of before
And reading your patch that's what it does :)
commit 480b568b1a5dac5bcab2590d81fdcad0a9f6f4f4 Author: Martin Whitaker <mageia@...> Date: Wed Jan 4 11:31:45 2017 +0000 Renumber existing partitions before adding a new one (mga#19935). --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=480b568b1a5dac5bcab2590d81fdcad0a9f6f4f4
(In reply to Mageia Robot from comment #49) > > Renumber existing partitions before adding a new one (mga#19935). Hope there is a nice errata write up about that renumbering for the multi-boot users with /dev/sdaX in their /etc/fstab(s).
(In reply to Bit Twister from comment #50) > (In reply to Mageia Robot from comment #49) > > > > Renumber existing partitions before adding a new one (mga#19935). > > Hope there is a nice errata write up about that renumbering for the > multi-boot users with /dev/sdaX in their /etc/fstab(s). Added FOR_ERRATA6 keyword so that we don't forget.
Keywords: (none) => FOR_ERRATA6
(In reply to Samuel Verschelde from comment #51) > (In reply to Bit Twister from comment #50) > > (In reply to Mageia Robot from comment #49) > > > > > > Renumber existing partitions before adding a new one (mga#19935). > > > > Hope there is a nice errata write up about that renumbering for the > > multi-boot users with /dev/sdaX in their /etc/fstab(s). > > Added FOR_ERRATA6 keyword so that we don't forget. I don't think there is a change compared to how DrakX worked before. The renaming is the same, it's just the timing which was changed.
Yeah, partition renumering has always happened if you delete partitions "in the middle". That happends in every OS. so no errata needed
Keywords: FOR_ERRATA6 => (none)
> there is no problem seen if partitions are made before the install. > The error occurs when using Custom Partitioning within the install. In my routine use of Custom Partitioning I have never come across this 'BIOS boot partition' problem - but then I never asked Custom Partitioning to create any new partitions (as I create them before the install). That leads me to suspect that the problem arises as a result of CP's creation of new partitions. N.B. I do also have Windows 7 installed, and its 'boot' partition is /dev/sda1, which gparted reports as: Filesystem=ntfs Label=System Reserved Size=100MiB Used=24.15MiB Flag=boot
CC: (none) => maurice
Grub2 need bios boot partition grub-legacy/grub don't need it at all. That's why you have not faced it never as Mageia used long time by default grub-legacy.
CC: (none) => otto.leipala
But Mageia-6 uses Grub2, and on my MBR/non-GPT desktop the 'classic' installer does NOT throw up the 'BIOS boot partition' problem. When I said 'never seen it' I meant on the several Mageia-6 installs I have done.
On true MBR disks, GRUB 2 does not require a BIOS boot partition. Instead, it writes a stage1 stub to the MBR, a stage 1.5 loader in sectors between the MBR and the first partition (there's some empty space there), and then the stage 2 loader (the actual bootloader) is written to /boot.
CC: (none) => ngompa13
(In reply to Maurice Batey from comment #56) > But Mageia-6 uses Grub2, and on my MBR/non-GPT desktop the 'classic' > installer does NOT throw up the 'BIOS boot partition' problem. > > When I said 'never seen it' I meant on the several Mageia-6 installs I have > done. Maybe your drive already contains the desired 3 meg partition from an early Mga6 install and you will not see the error until you wipe your drive, re-install win7 and then Mga6. Then install mga5.1 and PCLinuxOS. It is easy to see if you have a free unknown 3meg partition. Download the latest 490M systemrescuecd from http://www.sysresccd.org/Download. Burn it to cd or usb, site has usb instructions. Boot it, hit enter, enter, startx, click third icon from bottom left and see if there is a unused/free ~3 Mib partition. If so, my guess is that is what keeps you from seeing the error. Do not do anything else. Just exit gparted, and leave, bottom right leave/exit icon.
> It is easy to see if you have a free unknown 3meg partition. You have already seen the layout of my partitions! As I keep saying, I *do* have a small 'noot' partition - it's the Win7 boot partition /dev/sda1.
The odd thing bout this problem seems to be that the BIOS Boot Partition problem only occurs when Custom Partitioning is used AND new partitions are created.
> Neal Gompa 2017-01-21 15:56:23 CET > On true MBR disks, GRUB 2 does not require a BIOS boot partition. Perhaps I have a 'true MBR disk!
(In reply to Maurice Batey from comment #61) > > Neal Gompa 2017-01-21 15:56:23 CET > > On true MBR disks, GRUB 2 does not require a BIOS boot partition. > > Perhaps I have a 'true MBR disk! If your disk is smaller than 2 TiB, it's possible. Otherwise, it's a hybrid GPT/MBR disk and needs a BIOS boot partition.
> If your disk is smaller than 2 TiB i/4 that size.
As noted by Mageia Robot in Comment 42, the patch which should fix this was committed on 2017-01-18. I don't know which version current isos include, but the patch was included in DrakX 17.71.
(In reply to Bit Twister from comment #58) > (In reply to Maurice Batey from comment #56) > > But Mageia-6 uses Grub2, and on my MBR/non-GPT desktop the 'classic' > > installer does NOT throw up the 'BIOS boot partition' problem. > > > > When I said 'never seen it' I meant on the several Mageia-6 installs I have > > done. > > Maybe your drive already contains the desired 3 meg partition from an early > Mga6 install and you will not see the error until you wipe your drive, > re-install win7 and then Mga6. Then install mga5.1 and PCLinuxOS. > > It is easy to see if you have a free unknown 3meg partition. Download the > latest 490M systemrescuecd from http://www.sysresccd.org/Download. > > Burn it to cd or usb, site has usb instructions. > > Boot it, hit enter, enter, startx, click third icon from bottom left and see > if there is a unused/free ~3 Mib partition. If so, my guess is that is what > keeps you from seeing the error. > > Do not do anything else. Just exit gparted, and leave, bottom right > leave/exit icon. You should not refer to unused space between MBR and partition 1 as "a partition". It is just unallocated space that Grub2 needs because Grub2 writes more than will fit in just the MBR. And, Maurice doesn't need Gparted on a separate CD to view his partition table using Gparted, although it's a good idea to have such a rescue disk on hand.
(In reply to Pascal Terjan from comment #64) > As noted by Mageia Robot in Comment 42, the patch which should fix this was > committed on 2017-01-18. > I don't know which version current isos include, but the patch was included > in DrakX 17.71. The report.bug.xz that was attached to bug 20111 shows the 64bit Classical iso now has that version: [marja@localhost Downloads]$ xzcat 20111report.bug.xz |grep DrakX * second stage install running (DrakX v17.71) [marja@localhost Downloads]$ Martin had already fixed the Live isos before. However, Peter Larson reported still seeing the issue with a draklive install, and Martin asked him to file a bug report about it https://ml.mageia.org/l/arc/qa-discuss/2017-01/msg00392.html So I suggest keeping this report open until there is more clarity about when this issue still pops up, and whether the new report is enough for the remaining issue.
I did see the bug again when installing from the desktop of a Plasma Live 64 session. I created new partitions in Custom Partitioning and got the message that I needed to make a BIOS Boot partition. I was able to back out of that and continue the install using Existing Partitions (the ones I'd just made) I also had made two extra ext4 partitions while I was at it and these then showed as "unknown" type when viewed in Gparted. During that Custom Partitioning process I also got a message that I didn't have a swap partition (I did) (Continue anyway? Yes). I'm just reiterating this for now and later this evening I hope to wipe the disk and reproduce all of this. Even though I have not created any "BIOS Boot" partition on this disk, it seems to have a partition table problem. (Gparted will not let me make any more logical partitions but Drake will let me make more "extended" partitions. (Why doesn't harddrake follow the conventional terminology of one extended partition to hold many logical partitions??) I will be redoing this disk and creating partitions in several different ways. These should all be compatible but I have some doubts.
We would need the full debug logs. Please: - try the installer until you hit the bug. - then plug a USB key - go to tty2 (alt+ctrl+F2) - run the "bug" command Once it has completed, attach (not paste) the report.bug file you'll find on this USB key to this bug report
Keywords: (none) => NEEDINFO
Everything looks fine with the Mageia-6-sta2-i586-DVD.iso of Thu Jan 19 16:47:56 CET 2017 I've just deleted some linux partititions, resized the windows partition and then created new partitions while leaving some empty space. What I haven't tried since this issue was fixed, is: delete some partitions in custom mode and then let DrakX decide how to fill the just freed up space @ Martin Is that what you meant when you said: (In reply to Martin Whitaker from comment #37) > Note that my second patch only fixes the request for a BIOS boot partition > when using custom partitioning. When automatic partitioning is used, an > unnecessary BIOS boot partition is still created. Or was that about e.g. "Use free space" in this screen: http://doc.mageia.org/installer/5/en/content/images/dx2-doPartitionDisks.png ?
(In reply to Marja van Waes from comment #69) > What I haven't tried since this issue was fixed, is: delete some partitions > in custom mode and then let DrakX decide how to fill the just freed up space > > @ Martin > > Is that what you meant when you said: > > (In reply to Martin Whitaker from comment #37) > > Note that my second patch only fixes the request for a BIOS boot partition > > when using custom partitioning. When automatic partitioning is used, an > > unnecessary BIOS boot partition is still created. Yes. > Or was that about e.g. "Use free space" in this screen: > http://doc.mageia.org/installer/5/en/content/images/dx2-doPartitionDisks.png But I would expect it to happen there too. See my latest comment (#12) on bug 20074 for more details. Should we start a separate bug for this?
(In reply to Martin Whitaker from comment #70) > (In reply to Marja van Waes from comment #69) > > What I haven't tried since this issue was fixed, is: delete some partitions > > in custom mode and then let DrakX decide how to fill the just freed up space > > > > @ Martin > > > > Is that what you meant when you said: > > > > (In reply to Martin Whitaker from comment #37) > > > Note that my second patch only fixes the request for a BIOS boot partition > > > when using custom partitioning. When automatic partitioning is used, an > > > unnecessary BIOS boot partition is still created. > > Yes. > > > Or was that about e.g. "Use free space" in this screen: > > http://doc.mageia.org/installer/5/en/content/images/dx2-doPartitionDisks.png > > But I would expect it to happen there too. indeed, just tried that and "fdisk after" shows: /dev/sda9 38514688 38525759 11072 5.4M 0 Empty > > See my latest comment (#12) on bug 20074 for more details. Should we start a > separate bug for this? Just done, created bug 20161 for it.
Pete fell ill, but told on QA ml: Op 22-01-17 om 14:40 schreef Pete Larson: > I did do > 3 more installs using Custom Partitioning. I didn't see a recurrence > of the bug 19935 but I did the message that I had no swap partition > each time. So closing this report. The remaining issue, for the "BIOS boot" partition with Empty type that's needlessly created when diskdrake does the partitioning is handled in bug 20161. The "Empty" partition type corrupting the partition table is handled bug 20074 Peter, when you're better and up to it, it would be nice to get a separate bug report for the message about a missing swap partition. (+ attached logs as Thierry explained in comment 68 ) Take care!
Status: NEW => RESOLVEDResolution: (none) => FIXED