[solved] Grub hangs at cli on generation of cfg - during and after recent update to RC 16

yep I’m at update-grub. still hanging

at /etc/grub.d/40_custom 
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.


40 Custom look okay

Right , last test. - Remove Memory test
May be talking too long.
Edit your /boot/grub.grub.cfg

To restore original, there are 3 ways, you choose.
o Comment out the memory test part and uncomment when finished.
o Copy out that part somewhere and put it back later.
o Just remove it and then ‘update-grub’ to have it back.

This part

BEGIN /etc/grub.d/60_memtest86+

if [ “${grub_platform}” == “pc” ]; then
menuentry “Memory Tester (memtest86+)” --class memtest86 --class gnu --class tool {
search --fs-uuid --no-floppy --set=root --hint-bios=hd0,msdos13 --hint-efi=hd0,msdos13 --hint-baremetal=ahci0,msdos13 1c1e3f61-6f15-4e61-96e9-a2455d4c7f1f
linux16 /boot/memtest86+/memtest.bin
}
fi

END /etc/grub.d/60_memtest86+ ###

Ah… this bbcode thingy. hope you see it.

Opps, sorry, won’t work this way.

Wait. Chotomate.

I know the part you mean.
I’ll have to leave it for tonight
back in morning

okay. I’ll also sleep on it then.

memtest
sudo pacman -S --force memtest86+
sudo update-grub

After doing the memtest portion above, I am going to jump ahead because by the time you wake up, I will be sleeping.
The following is just in case you still have long grub-update times.

From the data you provided above, there are 3 other OS’s.

Found PCLinuxOS on /dev/sda5
Found Debian GNU/Linux (jessie/sid) on /dev/sda7
Found PCLinuxOS on /dev/sda9

Also from your data, these are the uuid’s

/dev/sda5: LABEL=“maxime” UUID=“4fb50d2e-190d-4b57-9621-3eae2131a2a4”
/dev/sda7: LABEL=“arch” UUID=“6393d9ba-1925-46d3-9f6a-ceaa6a4c2d5e”
/dev/sda9: LABEL=“kde5pclos” UUID=“40c8b8d3-4763-432c-9121-f8964a2461de” TYPE=“ext4”

If there are more, add these in, also recheck partitions and uuid’s.
Now we’re going to start by totally doing away with os-prober.
If you still have long update-grub time, it is nothing to do with os-prober, stop then and we’ll need to look again at grub.

Put this in /etc/default/grub

GRUB_DISABLE_OS_PROBER=true
# GRUB_OS_PROBER_SKIP_LIST="4fb50d2e-190d-4b57-9621-3eae2131a2a4@/dev/sda5"
# GRUB_OS_PROBER_SKIP_LIST="6393d9ba-1925-46d3-9f6a-ceaa6a4c2d5e@/dev/sda7"
# GRUB_OS_PROBER_SKIP_LIST="40c8b8d3-4763-432c-9121-f8964a2461de@/dev/sda9"

If bypassing os-prober improve update-grub times, then we’ll look into which OS probing causing the delay by elimination. We now select one OS to probe. In /etc/default/grub, modify then like this

# GRUB_DISABLE_OS_PROBER=true
# GRUB_OS_PROBER_SKIP_LIST="4fb50d2e-190d-4b57-9621-3eae2131a2a4@/dev/sda5"
GRUB_OS_PROBER_SKIP_LIST="6393d9ba-1925-46d3-9f6a-ceaa6a4c2d5e@/dev/sda7"
GRUB_OS_PROBER_SKIP_LIST="40c8b8d3-4763-432c-9121-f8964a2461de@/dev/sda9"

Then followed by

# GRUB_DISABLE_OS_PROBER=true
GRUB_OS_PROBER_SKIP_LIST="4fb50d2e-190d-4b57-9621-3eae2131a2a4@/dev/sda5"
# GRUB_OS_PROBER_SKIP_LIST="6393d9ba-1925-46d3-9f6a-ceaa6a4c2d5e@/dev/sda7"
GRUB_OS_PROBER_SKIP_LIST="40c8b8d3-4763-432c-9121-f8964a2461de@/dev/sda9"

And

# GRUB_DISABLE_OS_PROBER=true
GRUB_OS_PROBER_SKIP_LIST="4fb50d2e-190d-4b57-9621-3eae2131a2a4@/dev/sda5"
GRUB_OS_PROBER_SKIP_LIST="6393d9ba-1925-46d3-9f6a-ceaa6a4c2d5e@/dev/sda7"
# GRUB_OS_PROBER_SKIP_LIST="40c8b8d3-4763-432c-9121-f8964a2461de@/dev/sda9"

Identify which OS is the slow OS for os-prober, then go into that OS and check. Possibly an “update-grub” is alll it takes.

Thank you for all this input. You are going way beyond the call of duty and I am grateful.
I can’t do anything until much later in the day.

One more thing: what does Chotomate mean?

cheers

It means wait in Japanese, learned that from porns :smile:

Right, sorry for the delay in taking up the thread again.

Update:
Rather than continue troubleshooting I decided to download the RC 16.06 ISO KDE version and install it to a new partition.

Install went well - wouldn’t be the first time I’d used calamares! - until I reached installing bootloader section and there it was: the same long delay experienced by myself and apparently no-one else on the forums. After 12 minutes or so we moved on to the next stage - postcfg? - and there was comforting disk activity and then nothing and then nothing.
I abandoned the install at this point.

Not bothered about that it was an experiment after all.
Something in Daniella RC 16.06 does not like my Desktop PC.
I did say the problem started after the RC update and I did see one other user mentioned an os-prober delay with this release - eugen_b - I can’t find the thread but it wasn’t answered if I recall correctly.

So the last time I saw a bootloader delay was a few years back with openSUSE 13.2 that one lasted 30 minutes:scream:

Anyway there you go.
No point in troubleshooting my install if the latest ISO fares no better.
If I find eugen-b’s post I’ll link to it or reproduce his portion of the thread here.

Best wishes and many thanks to all who offered help and advice.

Still baffled about all this. I’ve had this system running since late December 2015.

At the beginning of this update was the question - replace bootloader with efitools Y/n
I think I delayed answering that question until I found out what would be the outcome if I did such a thing.
I found nothing untoward at that time and although I have no need of a secure boot, my motherboard and bios are from 2010 I decided to proceed OR maybe I wasn’t allowed to proceed until I chose Y. Don’t recall which.
All I know is this - I proceeded with Y to the replacement and that as when I saw the delay referred to in my first post.

Is it possible it is all down to efitools?
Am I to be plagued for ever or until I upgrade to a computer with a secure boot system?

:cold_sweat:

This is strange.
Let’s check a few things. From what you’ve provided, it does appear to be msdos and bios-legacy boot.
But let’s verify both of them first.
At terminal, provide output of

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
sudo parted -l

I’m not in my manjaro install right now as I messed up really badly.
I’m back in one my other distro installations thanks to supergrub2 - only one of many solutions, I know of, to rescue a person of wit and intelligence to get back control of their PC after wild experimental mistakes.

I don’t have to issue commands to know my bios - we have been intimate since 2010 - it is a legacy bios. My motherboard unchanged since its creation apart from gathering dust bunnies.

Just as a matter of interest and out of respect for your continuing interest in my welfare I will provide the verification you seek.

er…what does this do?

The bit inside square brackets doesn’t appear to have a command before its options.

We can continue this conversation when I’m back in my manjaro.
Also I think everyone was offered efitools Y/n at the system upgrade prompt.
Is it unlikely I would have been permitted to continue if I answered no.
Who would know? It seems to me it might be like hybridized ISOs - I don’t need the uefi part but nonetheless it is present and certainly has never caused me any problems in recent installs.

cheers

Finally!! I am back in my manjaro install.
I arch-chrooted from my arch install into manjaro and performed:

grub-install --target=i386-pc --recheck --debug --force /dev/sda

After that command + options did its scrolling ouput at a rate of knots, I ran:

grub-mkconfig -o /boot/grub/grub.cfg

and held my breath to see if it would stall/hang for 12 minutes as it has been doing relentlessly.
I am happy to report the generation of grub.cfg was over very quickly and I did not suffocate.

cheers

well I said I would so here you go:

$ [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
BIOS
sudo parted -l
[sudo] password for hugh: 
Model: ATA WDC WD1001FAES-7 (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type      File system  Flags
 1      2096kB  532GB   532GB   extended               boot
 5      2097kB  55.9GB  55.9GB  logical   ext4
 6      55.9GB  112GB   55.9GB  logical   ext4
 7      163GB   205GB   41.8GB  logical   ext4
 8      205GB   239GB   33.3GB  logical   ext4
 9      239GB   272GB   33.4GB  logical   ext4


Model: ATA WDC WD10EAVS-32D (scsi)
Disk /dev/sdb: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system     Flags
 1      1049kB  996GB   996GB   primary  ntfs            boot
 2      996GB   1000GB  4293MB  primary  linux-swap(v1)

Ah… the whole sda is one extended partition (with logical partitions in it).
While we are correct that your system is indeed bios-legacy with msdos partitioning, it is the structure of your partitioning that is causing problems.

Also that may explain why the update ask if you want to replace bootloader with efitools.
It is true efitools may be part of the package for bios/msdos system, the bootloader must not be efivar., that is only for gpt/uefi system.

You may need to rethink how you want to structure your disk or you may decide to leave it alone. If you restructure, your data in the whole disk will be lost.

Well, whatever, good luck and take care.

I would point out once again, reluctantly, as it might be coincidence - everything worked until that Daniella update and me choosing to allow the prebootloader to be replaced. I recall from arch days that if you were offered something at an update stage and capital Y is the default choice the upgrade team are expecting that you will choose that.
I have had occasion in the last few days to change the distro that owns the controlling grub or I would not have a booting system. Each distro I have allowed temporary control has installed in /dev/sda and run its grub-update or grub-mkconfig - o /boot/grub.grub.cfg without any delay whatsoever.

Now as we know Manjaro needs to be in control due to that intel-ucode image and I am delighted that I have Manjoro back in control. All other distros are being detected and booted as normal.

Oh, OK, I’ll have to ask…why? how? Absence of a primary partition?:grinning:

cheers friend

Mainly because of the first sector.
The first sector of a device (disk) is the “mbr” and that is where the bootloader gets the first instruction (stage 1)
The first sector of a partition is where the instruction goes from the mbr and here it gives further instructions to get to the partition itself. In grub-legacy, it’s where the stage 1.5 resides. In grub 2, it is the core.img or core.efi.
In an extended partition, there is this extended boot record instead. https://en.wikipedia.org/wiki/Extended_boot_record so it doesn’t work the same way.

GPT/uefi works better.

But if you get into problems again, try doing this grub-install --force --debug again.
BTW, grub-mkconfig is same as update-grub (a script).

ps: also same reason why swap partition should not be the first partition of an msdos disk.
It may work, like in your case, but would be… er, unreliable.

On update-grub and grub-mkconfig - I know, I like to alternate. I used grub-mkconfig before update-grub came along.

My swap partition resides at the end of dev/sdb
/dev/sdb1 is an NTFS formatted partition.
/dev/sdb2 is the swap.

I do some research I’ll have you know :grinning:

cheers again

Your swap here is okay. It’s not the first partition.
I am saying that others have swap as the first partition and they could face problems as you did with having the whole sda in extended partition. In fact, they would face more frequent problems as swap is used up. Luckily nowadays, swap is seldom used in normal operations with larger rams in place.

Forum kindly sponsored by Bytemark