Bug 27679 - M8 netinstall grub2-install fail
Summary: M8 netinstall grub2-install fail
Status: RESOLVED INVALID
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-28 22:29 CET by William Kenney
Modified: 2020-11-29 06:27 CET (History)
1 user (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments
M8 netinstall grub2-install fail (627.66 KB, image/jpeg)
2020-11-28 22:30 CET, William Kenney
Details
This is what the target drive looks like in gparted (61.65 KB, image/png)
2020-11-29 02:42 CET, William Kenney
Details

Description William Kenney 2020-11-28 22:29:03 CET
Description of problem:

An attempted netinstall of M8 today resulted in a grub2-install fail warning.
I have attached an image of the warning to this bug.

Right after this failed M8 netinstall I executed an M7.1 netinstall and did not encounter any errors during the entire install.

The repo was updated at 4am, 28 Nov 2020 Los Angeles time from kernel.org.
Comment 1 William Kenney 2020-11-28 22:30:25 CET
Created attachment 12026 [details]
M8 netinstall grub2-install fail
Comment 2 Dave Hodgins 2020-11-29 01:05:39 CET
From https://html.duckduckgo.com/html/?q=grub2-install+structure+needs+cleaning&kp=-2&atb=v47-2_y&t=mageia

Looks like an existing file system was chosen, but that file system requires
a fsck to be run on it, since it was not previously shut down cleanly.

If the file system was just created by the net installer, then it's a bug.
If it was previously created and not unmounted properly then it's not a bug,
and this bug report should be resolved as invalid.

CC: (none) => davidwhodgins

Comment 3 Dave Hodgins 2020-11-29 01:09:21 CET
Also, if I'm interpreting https://www.kernel.org/doc/html/latest/filesystems/bfs.html correctly, bfs should not be used to install Mageia into.
Comment 4 William Kenney 2020-11-29 01:42:36 CET
(In reply to Dave Hodgins from comment #3)
> Also, if I'm interpreting
> https://www.kernel.org/doc/html/latest/filesystems/bfs.html correctly, bfs
> should not be used to install Mageia into.

The install was into a blank USB drive. I instructed the installer to completely erase what was on the drive and start anew. I booted from the installer. The repo
was on a M7.1 system.

I admit I don't fully nderstand what's going on here. I've had many succesful
M8 installs exactly the same way. This one failed for the above.
Comment 5 William Kenney 2020-11-29 01:45:46 CET
(In reply to Dave Hodgins from comment #2)
> From
> https://html.duckduckgo.com/html/?q=grub2-
> install+structure+needs+cleaning&kp=-2&atb=v47-2_y&t=mageia
> 
> Looks like an existing file system was chosen, but that file system requires
> a fsck to be run on it, since it was not previously shut down cleanly.
> 
> If the file system was just created by the net installer, then it's a bug.
> If it was previously created and not unmounted properly then it's not a bug,
> and this bug report should be resolved as invalid.

The history of the target USB drive was that it previoulsy had M8 installed. Likely
a netinstall. And it got corrupted during all the M8 changes in the last week.
So I decided to start all over. Again, during the initial menues I instructed
the installer to erase everything on the drive and start all over.
Comment 6 Dave Hodgins 2020-11-29 02:18:28 CET
As per comment 3, use a file system that supports linux ownership and permissions, and directory structures, not bfs.

On a usb stick, probably F2FS is the most flash friendly.
https://en.wikipedia.org/wiki/F2FS
Either that or ext2 since it doesn't have journaling.

Closing the bug as invalid since bfs is not a suitable choice for the file
system linux is being installed on.

Resolution: (none) => INVALID
Status: NEW => RESOLVED

Comment 7 Dave Hodgins 2020-11-29 02:28:54 CET
Meant to add, feel free to reopen if I've misunderstood anything.
Comment 8 William Kenney 2020-11-29 02:33:28 CET
(In reply to Dave Hodgins from comment #7)
> Meant to add, feel free to reopen if I've misunderstood anything.

More testing here tells me that the USB target drive somewhere has been rendered read only.
No matter what I use I cannot "zero" it out. Example in a su terminal:

dd if=/dev/zero of=/dev/sdb bs=1M count=1
comes back with a write error

gparted can't refomat it

isodumper can't reformat it.

there's no little switch on it to make it write only.
Comment 9 William Kenney 2020-11-29 02:42:44 CET
Created attachment 12027 [details]
This is what the target drive looks like in gparted
Comment 10 William Kenney 2020-11-29 03:18:50 CET
Any other USB device I can change, reforma it
It even still boots to the previous M8 install
I can even write files to it while I'm in the drive
Comment 11 Dave Hodgins 2020-11-29 04:29:52 CET
So grub2-install failing to copy to bfs.mod file is just because that was the
file being copied when the drive failed, not because a bfs file system is being
used. Thanks for the update.

Leaving the bug closed since it's a hardware failure, assuming it is a bad
drive. :-)
Comment 12 William Kenney 2020-11-29 06:27:12 CET
(In reply to Dave Hodgins from comment #11)

> So grub2-install failing to copy to bfs.mod file is just because that was the
> file being copied when the drive failed, not because a bfs file system is
> being
> used. Thanks for the update.

Thank you David. It's one of those if it can go bad it will things. Murphys Law.

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