Last time my laptop had weird problem (couldn’t boot to GUI until I reinstalled new kernel) after I used Ktorrent’s scheduled shutdown.
Yesterday I scheduled a shutdown in console with “shutdown 40” and went to bed. This morning my laptop can’t boot at all
error: file ‘/grub/x64-pc/normal.mod’ not found.
This is a tri-boot system as listed in my signature. Opensuse takes control of the grub2, which supports both UEFI and secure boot. But I have secure boot option disabled in BIOS as manjaro does not support it.
The first thing I did is to boot it with my portable opensuse and did a fsck to the 1TB drive which has 3 os installed. Here’s the message:
# fsck /dev/sda
fsck from util-linux 2.23.2
e2fsck 1.42.8 (20-Jun-2013)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sda
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
I wonder if I should do as suggested “e2fsck -b 8193 /dev/sda”?
Also, can I do a regular grub rescure as instructed here by caf?
It is very unlikely that you have filesystem on /dev/sda. You probably have several partitions and filesystem is on them. Please post output of “fdisk -l; blkid”.
Well, that I can confirm you that my laptop OS is on /dev/sda. /dev/sdb is my portable drive. And blkid just shows those two disk, a and b, nothing unusual.
The thing I don’t understand is why it says ext2, I don’t have ext2 partition, all is fat, ntfs, ext4, swap. So I don’t know if running “e2fsck - 8193 <device>” is safe.
Other question is , can I just repair the grub according to the instruction.
Can you just provide the requested output. Enclose it in a code block (the “#” icon).
The thing I don’t understand is why it says ext2, I don’t have ext2 partition, all is fat, ntfs, ext4, swap. So I don’t know if running “e2fsck - 8193 <device>” is safe.
So now we learn that you actually have such things as partitions. They probably are something like “/dev/sda1”, “/dev/sda2”, etc.
You should be running “fsck” on partitions, not on the entire disk. The output that was requested should have shown partitions, and not just disks.
We cannot help you without some useful information about your system. Thus far, the information that you have provided is wrong – it is obviously wrong.
If you cannot boot from the hard drive, then boot from a live linux CD to get the requested information.
OK. Now I understand the fsck error. I checked partition by partition, no error was found.
Only now I notice that grub is looking in the wrong directory for normal.mod
Correct dir is (hd0,gpt9)/boot/grub2/x86_64-efi/normal.mod
but it is searching in …/grub/x86… I tried in the grub_rescue with “insmod (hd0,gpt9)/boot/grub2/x86_64-efi/normal.mod”
It reported a new error “grub_isprint” not found…
It listed “manjaro and windows” but no opensuse. However, Opensuse used to control the whole grub thing as manjaro doesn’t support secure boot. So the grub installed by suse support secure boot I have it disabled in BIOS for manjaro though.
Now opensuse is not listed in the boot menu, manjaro is listed but will prompt the same grub error. The only bootable is windows 8.1 now.
Conclusion should be: grub is corrupted and not looking for the right directory, which is caused by my last scheduled shutdown. I am not sure but I think my laptop went to sleep mode or sth but then might have been forced shutdown when it was in sleep mode.
BTW, the 1TB HHD has 8 GB of SSHD which really accelerate the booting and shutdown process. I don’t know if all these are related.
However, maybe I just need to fix the broken grub, as fsck checking every partition reports clean.
I tried to fix grub with this live opensuse but I can’t mount /proc and /sys as instructed on the caf blog.
That’s probably what boot with the manjaro installed grub would look for.
However the normal.mod is at this dir: /boot/grub2/x86_64-efi/normal.mod
And that’s what the opensuse installed grub should look for.
Here’s what might work:
1: Backup the manjaro directory (not sure if it is called that) in the EFI partition. I’m guessing that it is ‘\EFI\manjaro’. To backup, you can just create a new directory and move all of the files there (from that manjaro directory).
2: Copy everything from the opensuse directory to the manjaro directory.
You should be able to do the above while booted to a live CD.
When done, umount the EFI partition (so that it is properly synchronized).
Reboot. Use F12 if needed, and boot to the manjaro system. That should actually boot to opensuse because of the copying of files in step 2 above.
We can sort things out and fix booting the right way later. The first step is to get your system booted.
There are other ways of doing it, but what I suggested is easier and less confusing.
What’s happening there, is that your BIOS has a compatibility mode to boot the old fashioned non-EFI way. And you booted that way. But you don’t have access to the efi variables if you boot that way. That’s why I suggested a different method in my previous post.
Thank you. I understand now that this error is due to that I boot as in BIOS mode rather than UEFI so I can’t make a UEFI supported grub as in BIOS boot mode.
I tried your above suggestion
mount EFI partition at /mnt
backup /mnt/EFI/manjaro folder content (only one file named grubx64.efi)
copy /mnt/EFI/opensuse/ folder content to /mnt/EFI/manjaro
unmount EFI partition.
Here I tried both BIOS booting mode and UEFI mode to boot manjaro, I however get the same error message:
“/boot/grub2/x86_64-efi/normal.mod” not found, only different from previous “error /boot/grub/x86_64-efi/normal.mod”
ls /boot/grub2/x86_64-efi | grep normal
normal.mod
I don’t know why I have this complain in the first place.
I guess the question gets down to
How do I fix a broken EFI supported grub with a live session.
At the moment I am using my portable opensuse whose grub is BIOS only. I can’t seem to change it to UEFI support mode.
I am not sure if a live opensuse DVD can be boot on UEFI mode. I saw ubuntu has a pure EFI image media.
OK. This efi-grub error is finally solved after many google.
What I did:
In BIOS setting choose UEFI boot mode, then boot a live opensuse 13.1 (which supports UEFI booting)
Do the regular grub rescue instruction and you may encounter the error “can’t find /proc”. So following this thread, instead of mount /proc,
use suggested by wolfi:
mount -t proc proc /proc
mount -t sysfs sysfs /sys
Then what’s important when you rescue a efi-grub is that you need an extra step of mount during chroot session, which is
mount /sd**(your EFI partition) /boot/efi
if you don’t do this step it will complain “efi distributor id not specified”
Finish the following rescue step in the instruction and no error was reported this time.
When I boot grub is back, but Windows menu is absent. So after I boot to suse I use Yast-bootloader to generate another grub. Reboot again window is back as well.
I’m lucky to try the mounting EFI partition. In fact I still don’t quite understand how this complicated efi works.
Still some questions though:
What exactly was broken? My efi partition or my grub under suse root folder? Maybe I should back up my efi partition or grub folder?
Okay. I’m glad you found that. Otherwise I would have had to describe the whole procedure.
What exactly was broken? My efi partition or my grub under suse root folder? Maybe I should back up my efi partition or grub folder?
I can only guess. At one time, you posted the content of “grub.cfg” in the opensuse directory within the EFI partition:
search --fs-uuid --set=root 097a00d1-9205-4d1a-8d5f-e530f3ab555c
set prefix=(${root})/boot/grub2
configfile $prefix/grub.cfg
My best guess is that somehow that string “097a00d1-9205-4d1a-8d5f-e530f3ab555c” did not match the UUID of your root file system. I could not check, because you never posted the output of “blkid” in spite of requests.
As to how that would change – that I don’t know either. If you ever backed up the partition, reformatted and restored from backup, that would do it.
