Bug 27864 - Mageia 8 beta 2 diskdrake and installer stumble on MBR of our own Mageia Live
Summary: Mageia 8 beta 2 diskdrake and installer stumble on MBR of our own Mageia Live
Status: ASSIGNED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: High normal
Target Milestone: ---
Assignee: Martin Whitaker
QA Contact:
URL:
Whiteboard:
Keywords: FOR_RELEASENOTES8
: 27863 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-12-18 03:04 CET by Morgan Leijström
Modified: 2021-01-02 17:39 CET (History)
2 users (show)

See Also:
Source RPM:
CVE:
Status comment: fixed in git


Attachments
8beta2 installer grub fail: several partition labels (184.87 KB, application/x-xz)
2020-12-18 03:06 CET, Morgan Leijström
Details
Same fault with default partitioning (182.63 KB, application/x-xz)
2020-12-18 03:32 CET, Morgan Leijström
Details
journal from failed boot menu install (36.86 KB, application/x-xz)
2020-12-19 19:02 CET, Dave Hodgins
Details

Description Morgan Leijström 2020-12-18 03:04:31 CET
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
Comment 1 Morgan Leijström 2020-12-18 03:06:39 CET
Created attachment 12101 [details]
8beta2 installer grub fail: several partition labels
Comment 2 Morgan Leijström 2020-12-18 03:32:11 CET
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?
Comment 3 Dave Hodgins 2020-12-18 05:44:49 CET
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

Comment 4 Morgan Leijström 2020-12-18 11:39:39 CET
(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!
Comment 5 Morgan Leijström 2020-12-18 11:44:16 CET
*** Bug 27863 has been marked as a duplicate of this bug. ***
Comment 6 Martin Whitaker 2020-12-18 11:46:46 CET
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

Comment 7 Morgan Leijström 2020-12-18 11:52:15 CET
 * 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 => High
Summary: 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!

Morgan Leijström 2020-12-18 11:53:34 CET

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

Comment 8 Morgan Leijström 2020-12-18 12:09:07 CET
I think we should also test live installer from booted live storage to overwrite a storage containing live.
Comment 9 Dave Hodgins 2020-12-18 12:45:27 CET
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).
Comment 10 Morgan Leijström 2020-12-18 14:40:03 CET
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?
Comment 11 Morgan Leijström 2020-12-18 14:49:26 CET
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

Comment 12 Dave Hodgins 2020-12-18 21:55:26 CET
I've never needed to do it, so will have to experiment later.
Comment 13 Martin Whitaker 2020-12-19 15:23:06 CET
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.
Comment 14 Morgan Leijström 2020-12-19 15:54:54 CET
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.
Comment 15 Martin Whitaker 2020-12-19 16:08:04 CET
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.
Comment 16 Morgan Leijström 2020-12-19 16:19:32 CET
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 17 Dave Hodgins 2020-12-19 17:53:10 CET
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.
Comment 18 Dave Hodgins 2020-12-19 19:02:25 CET Comment hidden (obsolete)
Comment 19 Dave Hodgins 2020-12-19 19:13:52 CET Comment hidden (obsolete)
Comment 20 Martin Whitaker 2020-12-19 19:17:04 CET Comment hidden (obsolete)
Comment 21 Dave Hodgins 2020-12-19 19:34:31 CET
Sorry, the space comments were for bug 27872. Marking them as obsolete here.
Comment 22 Martin Whitaker 2020-12-19 23:12:59 CET
(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 => ASSIGNED
Status comment: (none) => fixed in git
Assignee: bugsquad => mageia

Comment 23 Morgan Leijström 2020-12-20 00:12:14 CET
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

Comment 24 Dave Hodgins 2020-12-20 00:17:29 CET
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.
Comment 25 Morgan Leijström 2020-12-20 00:33:52 CET
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.
Comment 26 Morgan Leijström 2021-01-02 16:51:53 CET
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.

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