Description of problem: Grub install fail. See attached "bug" Translating the message: grub2-install: Warning: Trying to install GRUB on a disk with several partition labels. This is not supported yet.. grub2-install: Warning: Embedding is not possible. GRUB can only be installed in this form by using block lists. Block lists are however UNRELIABLE and the use of them discouraged.. grub2-install: error: do not proceed without block lists. Attempted to do conventional install to USB stick. Installer 8beta2 official, 64 bit, on another USB stick Machine: Thinkpad T400. No internal disk. Partitioning: Ext4 /boot FAT16 /boot/EFI swap F2FS / FAT32 no LVM, no LUKS. If i remember correctly
Created attachment 12101 [details] 8beta2 installer grub fail: several partition labels
Created attachment 12102 [details] Same fault with default partitioning Identical error when using default partitioning "use whole disk" Is it the lack of a conventional storage of disk or SSD type in this computer that makes it fail somehow?
There is an iso9660 file system on sda and one on sdb, which makes things hard to follow in the bug report, and may be triggering the problem. Try erasing the usb stick the installation is going to "dd if=/dev/zero of=/dev/sd? bs=1M count=1" and then starting again. Replace sd? with the correct device.
CC: (none) => davidwhodgins
(In reply to Morgan Leijström from comment #2) > Is it the lack of a conventional storage of disk or SSD type in this > computer that makes it fail somehow? Nope, it did not help to plug in a SATA spinner containing a working dualboot. (in addition to try install on a USB stick) (In reply to Dave Hodgins from comment #3) "dd if=/dev/zero> of=/dev/sd? bs=1M count=1" YES - That did help! More specifically i did not test installper comment 0, but the more complicated in bug 27863 and that works perfectly. So the problem here is our tool diskdrake and installer stumble on our own Mageia Live!
*** Bug 27863 has been marked as a duplicate of this bug. ***
I think this is an unwanted side effect of enabling diskdrake to edit the partition table on our hybrid ISOs. Previously the installer wouldn't have allowed you to install onto that USB stick because it would have identified it as a CD/DVD.
CC: (none) => mageia
* This make reuse of storages that had Mageia Live loaded harder * Maybe diskdrake could detect it and suggest MBR wipe. Also, the button to clear the disk should clear MBR. (i dont remember if i tried that this time) May be related: Bug 27862 - Diskdrake fail to create more than four partitions on a Live storage.
Priority: Normal => HighSummary: 8beta2 grub2-install: Warning: Trying to install GRUB on a disk with several partition labels. => Mageia 8b2: Our tool diskdrake and installer stumble on MBR of our own Mageia Live!
Summary: Mageia 8b2: Our tool diskdrake and installer stumble on MBR of our own Mageia Live! => Mageia 8 beta 2 diskdrake and installer stumble on MBR of our own Mageia Live
I think we should also test live installer from booted live storage to overwrite a storage containing live.
I think for now, we should simply warn people (wiki/errata?) that after using a usb stick with an iso image on it, they will need to erase the mbr before trying to reuse the stick with newly created partition(s) on it, and close this bug. And then open a new enhancement bug (referring to this one) requesting a change to diskdrake to be able to overwrite the mbr (zero the first MB).
Yes, unless easy to fix for RC, lets not delay Mageia 8. dd is too dangerous for common users. What formatting tools really do wipe MBR reliably? Do Isodumper?
I meant "What newbie friendly" tools For errata 8, and possibly also note on relevant pages, i.e Isodumper and coming https://wiki.mageia.org/en/User:Morgano/Install_to_removable_device , https://wiki.mageia.org/en/User:Morgano/Persistent_live_systems
Keywords: (none) => FOR_ERRATA8
I've never needed to do it, so will have to experiment later.
After doing some experimentation... It's not the MBR (sector 0) that needs to be wiped, but the iso9660 volume descriptor signature (5 bytes starting at offset 32769 for the first volume descriptor). There's a command line program called wipefs which will display all the filesystem signatures it can find and allow you to selectively wipe them. A bit safer than dd! I can modify diskdrake and the installer to wipe the iso9660 signature if you select the "Clear all" option. The tools already detect that a disk contains one of our hybrid ISOs (a combination of a DOS partition table and an iso9660 filesystem on the base device), and I think it's fairly safe to wipe those 5 bytes if you are about to replace the entire partition table. But if you think it's too risky, I can save that for Mageia 9.
Good find, and thanks for the tip on wipefs. 1) Installer should not need user to know to press "Clear all". 2) I also experienced the problem when i did not use custom partitioning, but just opted to use all disk, so that button do not come visible. Can the installer automatically wipefs iso9660 (or clear whole MBR plus that before writing new MBR and filesystem) when needed? I think it could be done unconditionally as soon user decides to use the disk, either when he selects to use whole disk (diskdrake never visible) or at first time changes to disk are written anyway because of user selections in custom partitioning.
If you opt to use the entire disk, the installer presses "Clear all" for you :-) For custom partitioning, you can't be certain the iso9660 signature isn't something the user wants to keep unless they clear everything. I don't know how the system validates the signature, but it's likely false positives can happen, even if the probability is low.
Right. Hm. What about: if diskdrake do not find to display any iso9660 (it did not) then assume user do not want it, so clear that bits?
Comment 13 along with comment 15 makes the change sound safe to me. I'd prefer to have the change included by time we create the next iso images for Mageia 8.
Created attachment 12120 [details] journal from failed boot menu install Encountered the bug again. Rebooted the live (after increasing the ram) to access the journal from the install. The lightdm error is not present in that journal or the /root/drakx/draklive-install.log but there are enough errors in the journal to show that drakx-installer-xsetup is failing due to lack of space, triggering a cascade of errors. That space is in the temporary ram drive being used, not the disk space the install is going to. There is a 3GB swap partition in this install, so I'm not sure why it's running out of space. I'm surprised that the installer is using more ram than a running xfce live system.
It added the swap at Dec 19 11:55:42 kernel: Adding 3178964k swap on /dev/sda5. Priority:-2 extents:1 across:3178964k FS The first running out of space message is ... Dec 19 11:55:59 drakx-installer-xsetup[4606]: Failed to write file “/usr/share/glib-2.0/schemas/gschemas.compiled.3STFV0”: write() failed: No space left on device The df command shows ... Filesystem Size Used Avail Use% Mounted on /dev/sda1 17G 5.1G 11G 32% /a1 I'm not clear on why it is running out of space.
If you run draklive-install from the command line in Xfce, you'll see it's running out of space there too. I think it's just chance whether or not it breaks the install in a visible way. I don't know for sure, but I'm guessing the size limit for the tmpfs is set when it is created, and not updated when you add swap. Maybe there's a mount option to alter that.
Sorry, the space comments were for bug 27872. Marking them as obsolete here.
(In reply to Morgan Leijström from comment #16) > What about: if diskdrake do not find to display any iso9660 (it did not) > then assume user do not want it, so clear that bits? It could be data in different filesystem that just happened to match the iso9660 signature (plus anything else the system checks to decide it really is an iso9660 filesystem). I guess we could also wipe the signature if the user deletes the partition that covers those bytes, but at least for now I'd rather stick to something simple and clearly safe.
Status: NEW => ASSIGNEDStatus comment: (none) => fixed in gitAssignee: bugsquad => mageia
OK So we should write somewhere that a storage that have been used for Live, need be cleared this way (or other) Not sure where to note that. Release notes?
Keywords: FOR_ERRATA8 => FOR_RELEASENOTES8
If the changes are made to diskdrake, no need for an errata item. It's a bugfix, so not really important enough to include in release notes either. If the change isn't made then it's an errata item.
I meant note about Live. Not sure all tools handle reuse of them due to the unusual MBR. And diskdrake even when fixed need users to press the Clear all button if custom partitioning is used. I personally i often click partition(s) and remove them, instead of using the Clear all button.
Documented at https://wiki.mageia.org/mw-en/index.php?title=User%3AMorgano%2FPersistent_live_systems&type=revision&diff=49351&oldid=49348 When that page is moved official, I will update errata to point to it.
Corrected: https://wiki.mageia.org/en/User:Morgano/Persistent_live_systems#Reformatting_.28reusing.29_a_Live_system