[Solved!] Installing Gentoo: failing to boot after install

wolly01 · n00b Joined: 22 Jul 2017 Posts: 35

Gentoo forum people:

I am currently trying to install the amd64 version of Gentoo following the handbook and making the choices of using OpenRC, efibootmgr and GPT at the relevant stages. I have only deviated from the handbook in two ways: firstly, making a separate partition for /home, and secondly a slight difference in the layout of my efi /boot partition. In particular my efi files and ramdisk are renamed to "bootx64.efi" and "initramfsx64.img" respectively and are located in "\boot\efi\Gentoo" where \boot is the mountpoint of /dev/sda1. Furthermore the command I issued to create my boot entry was:
efibootmgr command

NeddySeagoon · Posted: Fri Dec 23, 2022 3:11 pm Post subject:

wolly01,

wolly01 · n00b Joined: 22 Jul 2017 Posts: 35

NeddySeagoon, thanks for the response!

pietinger · Posted: Fri Dec 23, 2022 3:57 pm Post subject:

wolly01 · n00b Joined: 22 Jul 2017 Posts: 35

Thanks, I will try this fix and then attempt Grub if it does not work!

NeddySeagoon · Posted: Fri Dec 23, 2022 4:08 pm Post subject:

wolly01,

There is an overview of the PC Boot Process which mak help understanding what's going on.
If your root is /dev/sda3, then the built in kernel command line is correct.

Its going wrong before the kernel attempts to mount root though.
It appears that one or more of the modules you need to mount root are in the initramfs.
The initramfs also has a control script with error handing, so you get a 'rescue shell' when things go wrong.

The initramfs is a root ffilesystem in a file that is used to mount the real root filesystem.
As you get a kernel panic, not a rescue shell, it looks like the initramfs is not being used. It may not even be loaded.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

pietinger · Posted: Fri Dec 23, 2022 4:49 pm Post subject:

wolly01 · n00b Joined: 22 Jul 2017 Posts: 35

Thanks for the Help you two.

I was just doing some tests along the side and It looks like My PC failed memtest so I'm going to have to start an RMA process before I can resume setting up my OS!

:cry:

wolly01 · n00b Joined: 22 Jul 2017 Posts: 35

Great News!

So I originally ran memtest on the Gentoo live-cd which failed. However I set up a memtest usb using the latest image from passmark and ran all the tests for 4 passes without a single error which took about 8hrs. I'm thus willing at the moment to chalk the failure down to the version of memtest on the livecd (though I will run more extensive tests and check with Kingstone soon just to be doubly-sure!).

I followed pietingers advice and retried my UEFI entry using -u. Initially this caused the same kernel panic as before but failed worse as it also somehow caused the PC to decide to remove boot entry from the UEFI list every time I tried it, where before the entry would stay.

So, I did some more digging and double checks. I emerged pciutils and used lspci -kk to determine that the driver for my SATA HDD used by the kernel was ahci. After checking my kernel config I discovered that the associated drivers where still being compiled as modules by accident. Without knowing which specific ahci driver was being used I simply added them all and re-genned my kernel before moving and renaming the stub and ramfs as in my original post and re-adding the boot entry.

On restarting the system I no-longer get a Kernel panic! however, all is not right as the PC fails to mount the root partition and asks me to give a partition or drop into the rescue shell. If I give /dev/sda3/ then the system successfully loads into Gentoo (but fails to mount /home) and I can log in as root (I am yet to make myself a user account). After logging in I can successfully mount /home.

Conversely if I choose the recovery shell I am, unsurprisingly, dropped into a shell. Whilst the shell is responsive and I can use fdisk to locate drives, I cannot for some reason mount any partitions so cannot carry the log files onto a usb stick to paste here. Furthermore it looks like there is no text editor on the rescue shell so I cannot open them to look inside either. What I can access however is the init.log when I manually mount root instead of dropping into the shell. I give one such log below:

pietinger · Posted: Sat Dec 24, 2022 12:12 pm Post subject:

NeddySeagoon · Posted: Sat Dec 24, 2022 4:50 pm Post subject:

wolly01,

rootfstype is a kernel parameter and goes on the kernel command line.

It won't fix anything. When its missing, the kernel tries all the filesystems it knows to mount root.

wolly01 · n00b Joined: 22 Jul 2017 Posts: 35

Thanks for the continued help.

I retried using efiboormgr -u a few times just to make certain that it was not working for my device, and then tried altering the kernel command line parameter. I found out that I had forgot to prefix my parameter with root= originally and just had /dev/sda3 set, which may have been causing problems. I updated the parameter to:

wolly01 · n00b Joined: 22 Jul 2017 Posts: 35

Oh my goodness I am an idiot. I misspelled btrfs as brtfs in my fstab twice and haven't noticed this entire time. I have made the correction and all now works.

Many thanks for the help, especially with regards to the efi bootmanger/kernel command line parameters!

Issue is now solved yay!

NeddySeagoon · Posted: Sat Dec 24, 2022 8:38 pm Post subject:

wolly01,

You are looking for dmesg.
Use wgetpaste to share it. It won't be installed yet.

Also share your /etc/fstab. That will go into a post though.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.