PDA

View Full Version : Grub2-mkconfig problem



lsatenstein
27th November 2017, 04:36 AM
Last week, on my computer, grub2-mkconfig was working correctly, it would detect and create a grub.cfg that included /dev/sdc (my Fedora KDE version) and /dev/sde, my default Gnome version. Note: /dev/sde is my SSD, so I want to create grub.cfg from it.

However, the past few days, from my SSD (/dev/sde drive), when I execute
sudo grub2-mkconfig -o /boot/grub2/grub.cfg it only includes itself, the Gnome system installed on /dev/sde.

Any way to trace what is happening.

As a work around, in the bios I could change the boot drive to /dev/sdc and use that grub.cfg. It includes the /dev/sde. Further, I could tell grub to use the SDE entry.

Any ideas about running a trace or ideas about what to look for? The same verson of kernel is on both installations.

leigh123linux
27th November 2017, 08:25 AM
Try mounting the other root partitions (use nautilus or any other file-manager) before running the grub command.

dswaner
27th November 2017, 02:06 PM
Did some upgrade change the setting for GRUB_DISABLE_OS_PROBER?

lsatenstein
27th November 2017, 03:40 PM
I looked at 30_* in /etc/grub.d, and added an echo of the GRUB_DISABLE_OPROBER* to /tmp/prober. Value is "",
GRUB_DISABLE_OS_PROBER is not changed. Also which os-osprober shows /usr/bin

I will run diff against two /etc/grub.d (KDE one that works, vs Gnome one that stopped working).

lsatenstein
27th November 2017, 11:28 PM
How do I phrase my finding below to report a Grub bug?
I have 5 disks on my desktop system. Ignore for now /dev/sda, /dev/sdb (data disks)
At one time, I had various F27 betas on my system For example:

Fedora27betaKDE on /dev/sdc,
Fedora27betaTestGnome on /dev/sdd and
Fedora27betaGnome on SDE.


With Go live, to have clean systems, I re-installed Fedora as follows:

Fedora27KDE on /dev/sdc,
New empty clean GPT/2 partitioned disk on /dev/sdd with 2 ext4 partitions defined.
Fedora27Gnome on /dev/sde


I then created this issue, because the KDE system was not showing up on my Fedora27GnomeSDE' grub boot menu.
but from SDC's boot menu, it showed SDC's KDE and SDE's Gnome.

In attempt to discover if the problem was due to SDC's setup or SDE's setup, I installed a F27Gnome on the spare SDD (the empty disk is in-between).
Surprise.
The SDE's grub menu now shows the missing SDC's KDE, the newly installed SDD(Gnome) and itself in the boot menu. (all three systems).

How do I write this up for Grubs support?

bobx001
28th November 2017, 10:00 PM
my $0.02

since the creation of I guess HAL and UDEV , the /dev/sdN have become rather obsolete, as they constantly change based on udev's "will". So, we have entered into the age of the partition=UUID=nnnnnnnnnnnnnnn ,
and maybe this should be the way you address these devices instead of /dev/sdN

however, since I use grub2-mkconfig once every blue moon, mainly to get my laptops to suspend / hibernate properly, for which I was semi-forced to use the resume=UUID=nnnnnnnnnnnn in the grub.cfg, I am no expert

however, I suggest you look into it.

lsatenstein
30th November 2017, 03:31 AM
Hi Bob

Here is the fstab from /dev/sde



#
# /etc/fstab
# Created by anaconda on Tue Nov 28 20:47:31 2017
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
#<file system> <mount> <type> <options> <dmp fsck> <xref> <label>
UUID=58d670b9-6ac4-4069-87b5-ab060056f1c8 / xfs defaults,noatime 0 0 #/dev/sde4 sde4Slash
UUID=c46affc9-618d-43c3-bd8f-92b47ecc529c /backup xfs defaults,noatime 0 0 #/dev/sdb1 sdb1backup
UUID=9156b44c-c22c-44f0-8974-a41cb15e8776 /boot ext4 defaults,noatime 1 2 #/dev/sde3 sde3Boot
UUID=75004a31-0342-4355-9e2c-b154a5bf5fe6 /home xfs defaults,noatime 0 0 #/dev/sde6 sde6home
UUID=16ec4d08-cc8a-410e-8150-b26e9552dee9 /scratch xfs defaults,noatime 0 0 #/dev/sdb2 sdb2Scratch
UUID=0e0554c5-403e-49d4-8b23-8ab6c8e5cfad swap swap defaults,noatime 0 0 #/dev/sde5 sde5Swap

FYI, I analyze the /etc/fstab and build the cross reference. I can cross reference LABEL=... UUID==,
/dev/sdx ... Tempdisk.
That program is available for free for the asking. I wrote it as a convenience to myself. It cannot write to /etc/fstab or overwrite it's own input. I've been using it since Fedora 23.

lsatenstein
6th December 2017, 12:37 AM
Out of the blue, my 4 Fedora distributions (4 separate disks) are each not picking up the other 3 Fedora installations. I am using xfs for two distributions and ext4 for the other two.

In other words, where a grub2-mkconfig would list the alternates Fedora distributions, not one of the grub.cfg had other than it's own boot information.

A few messages went zooming past me during the boot process for one of installed messages, about a disk integrity check. Is it being run because the normal Fedora termination did not occur? Running fdisk on the / partition of that other installation fixed the problem with that partition and distribution.
Retrying grub2-mkconfig after the fdisk fixup now included that distribution in the /boot/grub2/grub.cfg.

Since fdisk on root worked for that distribution, I switched to the next one that did not show up. When I tried to run fdisk on it, it failed, even though I could boot that distribution by using the bios to select it. I checked and noted that the file system was xfs. Is it possible that a fdisk on xfs is not as able to fix up many the file system problems, even if all the files are readable? Is the only strong repair action to be a backup and a restore?

I did the next best thing. I backed up the xfs partition, reformatted it as ext4. Running grub2-mkconfig was successful. By the way reformatting a partition changes the UUID. One has to fix up /etc/fstab.

My thoughts are these, If a system is shutdown before any root(/) partition is marked as clean, grub will not access that partition, even though grub will not be writing to it. fdisk is not assured to work as well as it does for ext4 than for xfs file systems.

Bequimao
6th December 2017, 11:36 AM
Hi,

if writing about grub, you should always mention if your system is MBR or UEFI boot, if it has GPT partition tables or not.

You can invoke

# os-prober
to check if the partitions are recognized.

You should also reinstall grub

# grub2-install /dev/sdX
to see any error messages, followed by

# grub2-mkconfig -o ...

I don't agree with your guesses about xfs. If a filesystem is shutdown uncleanly, it will be cleaned automatically with next remount, or else there would be an error message.
The tool for xfs repairs I use is

# xfs_repair <partition name>
or check only

# xfs_repair -n <partition name>

Best regards,
Bequimão

antikythera
6th December 2017, 01:28 PM
duplicate thread merged

lsatenstein
6th December 2017, 08:22 PM
Antikythera, thanks for the merge. Sometimes when I search for my previous entry, it fails.

Hi Bequimao,
I invoked xfs_repair via gparted, and it setup that command line. But step two of the repair crashed, and not able to complete. I tried the xfs_repair with several other options. It was not successful.

A backup/format/restore worked just fine.

Topic change: I am sure that the IBM VSAM (1982) file system served as a model for the xfs file system.

The VSAM file system was organized as Access Groups (intervals), and worked as a B+tree. It also used disk rotational positional sensing (RPS) and disk access arm location" to perform out of order shortest I/O time to read/write a group of sectors.

antikythera
7th December 2017, 12:43 AM
to save searching, subscribe to threads. the option is in the Thread Tools drop down menu at the top of the thread pages then use the View all subscribed threads (https://forums.fedoraforum.org/subscription.php?do=viewsubscription&folderid=all) tool on your profile page. it's in the format of a topic list, but you can create sub-folders if you wish as well.

Kobuck
7th December 2017, 04:30 AM
If you issue "os-prober" from a terminal as root, do you get a complete listing of all your installed os's? ( should show all other than your currently booted OS )

lsatenstein
7th December 2017, 04:54 AM
Hi Kobuck

After detecting the problems I ran os-prober to try to understand what was happening. Initially, os-prober was telling me the / of the other faulty systems was write protected????. Why should that matter, as I only read from them. As I wrote, in an earlier response, xfs_repair fixed one problem, but not the other. A backup/restore corrected the second problem.

All is well that ends well.

lsatenstein
7th December 2017, 07:12 PM
If an OS did not shut down properly, then root (/ on ext4) is deemed to not be clean. os-prober will skip over that OS.
I proved it by doing a fdisk check/recovery over the skipped OS, and immediately thereafter, os-prober recognized it.
For the second OS with root (/ on xfs), the xfs_repair was not able to do it's thing. retesting with os-prober failed.
A backup, reformat partition and restore corrected the problem.

Summary. The file system has to be clean before os-prober will work on it. It will always work on the OS from which it was initiated.

amiga
7th December 2017, 10:37 PM
Try mounting the other root partitions (use nautilus or any other file-manager) before running the grub command.

This is absolutely not necessary as os-prober scans all partitions for known OSs and can mount and examine file systems itself. There is absolutely no need to have any other file systems mounted.

lsatenstein
8th December 2017, 02:35 AM
Amiga is right,
On Fedora 28 rawhide, /dev/sda, the / partition was closed correctly, and osprober recognized it.

/dev/sdb is purely my data Disk, , no operating system.

/dev/sdc is where the second Fedora F27 KDE was installed, and it had a problem with / and it was jumped over by os-prober. Had it been mounted, that operation would have corrected the os-prober and it's recognition of same.
/dev/sdc was corrected using xfs_repair. The repair was successful and os-prober recognized the F27 KDE.

/dev/sdd was a temporary Fedora 28 (I temporarily installed it to resolve the os-prober problem). For some reason the / root partition could not be repaired by xfs_repair. backing up and restoring / fixed the problem. Subsequently the Fedora was recognized by os-prober.

Looking back at what happened, because I could boot any of the /dev/sd{a,c,d} via bios, I conclude that amiga is right. If the disks were pre-mounted, the linux mount command would have corrected whatever setting there was that blocked os-prober.

For the past three years I have been running multiple Fedora versions (up to 4) concurrently. This is the first time something like this has happened. Now I am aware of what to do to correct same. I do run btrfs file system on a fourth SSD device.
but it caused other problems with Gnome due to btrfs's "copy on write".

Thank you all for your help.

lsatenstein
14th December 2017, 05:52 PM
I have 5 disks on my system
/dev/sda Test Fedora 28
/dev/sdb Data
/dev/sdc Fedora 27 KDE
/dev/sdd Data
/dev/sde Fedora 27 Gnome on SSD

Today I had a kernel upgrade to version 4.14.3-300.fc27.x86_64. The grub.cfg that was generated
included the three Fedora installations.
When manually running grub2-mkconfig from the F27Gnome version, it skips the KDE distribution.

When I run manually, I was getting stopped by "/etc/grub.d/15_ostree" script. I stored that out of harms away as it causes the manual execution of grub2-mkconfig to fail. (message that I detected "error: opendir(ostree/repo): No such file or directory"

Anyone else experiencing these two problems? You can test by not directing grub2-mkconfig to a file or directing the output to /tmp/grub.test

antikythera
15th December 2017, 09:36 AM
leslie, please stop creating duplicate topics each time this happens with a kernel update. you can subscribe to this thread and find it again via your user control panel. any further duplicates will be removed and not merged back in.

lsatenstein
16th December 2017, 12:09 AM
Antikythera,
It seems that I can find other's postings more easily than my own. It is discouraging to me too.
Why is the 15_ostree link within /etc/grub.d pointing to a value that kills grub2-mkconfig, but when it is a kernel update,
the new grub.cfg seems to just jump over that 15_ostree. I did move that link out but it was recreated with the kernel upgrade.

As I indicated grub2-mkconfig [enter] displays all the build activities, including error messages. os-prober quits early in the scan process without error messages

leigh123linux
16th December 2017, 07:14 PM
This is absolutely not necessary as os-prober scans all partitions for known OSs and can mount and examine file systems itself. There is absolutely no need to have any other file systems mounted.

Choose what you want to believe!, os-prober doesn't work 50% of the time here and never has.
I see the same on my T410 or desktop PC




os-prober first fail

[leigh@localhost ~]$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
[sudo] password for leigh:
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.13.16-200.fc26.x86_64
Found initrd image: /boot/initramfs-4.13.16-200.fc26.x86_64.img
Found linux image: /boot/vmlinuz-4.13.13-200.fc26.x86_64
Found initrd image: /boot/initramfs-4.13.13-200.fc26.x86_64.img
Found linux image: /boot/vmlinuz-4.13.12-200.fc26.x86_64
Found initrd image: /boot/initramfs-4.13.12-200.fc26.x86_64.img
Found memtest image: /boot/elf-memtest86+-5.01
Found Fedora 25 (Twenty Five) on /dev/nvme0n1p3
Found Fedora 28 (Rawhide) on /dev/nvme0n1p5
done
[leigh@localhost ~]$ sudo os
osage osbs-2.7 osgmlnorm ospcat os-prober osx
osbs-2 osd_login ospam ospent ostree

os-prober second fail

[leigh@localhost ~]$ sudo os-prober
/dev/nvme0n1p3:Fedora 25 (Twenty Five):Fedora:linux
/dev/nvme0n1p5:Fedora 28 (Rawhide):Fedora1:linux

Give the crapware it's third and final chance to find F27, how friggin hard can it be to find a plain ext4 partition on the same friggin drive?

[leigh@localhost ~]$ sudo os-prober
/dev/nvme0n1p3:Fedora 25 (Twenty Five):Fedora:linux
/dev/nvme0n1p5:Fedora 28 (Rawhide):Fedora1:linux

Mount F27 root in nemo then it can find it :rolleyes:

[leigh@localhost ~]$ sudo os-prober
/dev/nvme0n1p2:Fedora 27 (Twenty Seven):Fedora:linux
/dev/nvme0n1p3:Fedora 25 (Twenty Five):Fedora1:linux
/dev/nvme0n1p5:Fedora 28 (Rawhide):Fedora2:linux
[leigh@localhost ~]$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.13.16-200.fc26.x86_64
Found initrd image: /boot/initramfs-4.13.16-200.fc26.x86_64.img
Found linux image: /boot/vmlinuz-4.13.13-200.fc26.x86_64
Found initrd image: /boot/initramfs-4.13.13-200.fc26.x86_64.img
Found linux image: /boot/vmlinuz-4.13.12-200.fc26.x86_64
Found initrd image: /boot/initramfs-4.13.12-200.fc26.x86_64.img
Found memtest image: /boot/elf-memtest86+-5.01
Found Fedora 27 (Twenty Seven) on /dev/nvme0n1p2
Found Fedora 25 (Twenty Five) on /dev/nvme0n1p3
Found Fedora 28 (Rawhide) on /dev/nvme0n1p5
done
[leigh@localhost ~]$

antikythera
16th December 2017, 08:11 PM
It's never worked reliably for me either which is why I use rEFInd.


Give the crapware it's third and final chance to find F27, how friggin hard can it be to find a plain ext4 partition on the same friggin drive? :D

lsatenstein
17th December 2017, 03:56 PM
Hi os-prober users.

What I have noticed is the following:
if I run grub2-mkconfig for my own booted distribution, it never fails.
If one of the other Fedora Linux versions has an unclean (partition not marked as clean), os-prober fails.
So, in my case
/dev/sda was clean, (F 28 rawhide -test)
/dev/sdb -- my data disk had a partition that not marked as "clean" os-prober fails
/dev/sdc os-prober had quit. KDE version of Fedora on this disk was not picked up.
/dev/sde --Fedora 27, my daily Fedora 27 is not showing /dev/sda or /dev/sdc Fedora Linux versions

I posted this bug
by the way, mounting a partition appears to load the corresponding journal file and mark that partition as clean.
Ergo, Amiga (comment 16) is right

leigh123linux
17th December 2017, 04:02 PM
Hi os-prober users.

What I have noticed is the following:
if I run grub2-mkconfig for my own booted distribution, it never fails.
If one of the other Fedora Linux versions has an unclean (partition not marked as clean), os-prober fails.
So, in my case
/dev/sda was clean, (F 28 rawhide -test)
/dev/sdb -- my data disk had a partition that not marked as "clean" os-prober fails
/dev/sdc os-prober had quit. KDE version of Fedora on this disk was not picked up.
/dev/sde --Fedora 27, my daily Fedora 27 is not showing /dev/sda or /dev/sdc Fedora Linux versions

I posted this bug
by the way, mounting a partition appears to load the corresponding journal file and mark that partition as clean.
Ergo, Amiga (comment 16) is right

Try again as your theory has just been proved wrong, the partition was/is clean (systemd runs fsck automatically) .


sudo fsck -a /dev/nvme0n1p2
fsck from util-linux 2.31
F27_ROOT: clean, 428313/2564096 files, 5050891/10238720 blocks

lsatenstein
18th December 2017, 03:28 AM
Leigh, I could not create a clean grub.cfg until I mounted the / partitions of the other copies of Fedora.
I did run fsck via Gparted to clean up each partition on each drive. When I tried to create the grub.cfg, it failed until
I mounted those drives.
And after demounting the drives, I was able to once again create the grub.cfg. Mounting/demounting the drive did something.,