boot failure after installing Mint 20

Martinus2u · 10-24-2020, 06:55 PM

hi to all Linux Mint experts!

I'm not new to Linux at all, but new to Linux Mint, and new to grub.

I've started installing Linux Mint for friends and family on accounts of it being beginner-friendly. But I have come across an issue that a beginner can't solve.

A minor nuisance is that the installer freezes occasionally. I've observed that on two machines, using the same GT 240 graphics card. My assumption is that it is nouveau-related, and well, i can re-boot until the installer runs through.

A much bigger problem is this: whenever I try a non-trivial partitioning scheme (I choose "Something else" and then create two partitions mounted at / and /boot, for instance) the installation runs through, but the subsequent boot ends up with kernel panic - root filesystem not found. Upon further inspection it turns out that the grub parameters for root= are wrong (wrong UUIDs or no UUIDS at all)

When I repeat the install with a simpler scheme (only one partition mounted on /) everything is installed correctly.

Now the questions to the experts: what am I doing wrong? how can I fix the grub installation in case of a botched install? I am familiar with fdisk and the like, just not with grub.

colorpurple21859 · 10-24-2020, 07:15 PM

Why not select alongside or use whole disk, to see what the installer does? Do note if you select whole disk it will erase everything on the disk, and create a new partition layout. For alongside you will need empty space on the drive where no partition exists.

Code:

Now the questions to the experts: what am I doing wrong? how can I fix the grub installation in case of a botched install?

It could be any number of things from wrong mount points, no efi partition on an efi system, the efi partition mounted at the wrong place, on legacy system a gpt disk with no 2mb partition flagged bios-grub or something else. Most grub issues can be fixed from a live iso.

syg00 · 10-24-2020, 07:50 PM

I'll have a small wager on EFI. Let's see "lsblk -f" from one of the victims where your manual partitioning failed initially.

Martinus2u · 10-24-2020, 08:06 PM

Quote:

Originally Posted by colorpurple21859

Why not select alongside or use whole disk, to see what the installer does? Do note if you select whole disk it will erase everything on the disk, and create a new partition layout. For alongside you will need empty space on the drive where no partition exists.

Yes, on a couple of instances I have done that, and as i wrote, the installer works correctly in those cases. However, for my latest install I will probably want to encrypt the root filesystem, so I need at least a separate /boot partition.

Quote:

Originally Posted by colorpurple21859

It could be any number of things from wrong mount points, no efi partition on an efi system, the efi partition mounted at the wrong place, on legacy system a gpt disk with no 2mb partition flagged bios-grub or something else. Most grub issues can be fixed from a live iso.

Maybe we are getting closer to the point. (Surely grub would complain if a partition was missing, instead of creating an unbootable installation?). The previous two systems were non-EFI, the current system is EFI. From the latter I'll attach the output of fdisk and /etc/fstab (showing unexpected UUIDS, the same being shown when hitting "e" in the grub boot menu).

Martinus2u · 10-24-2020, 08:14 PM

Quote:

Originally Posted by syg00

I'll have a small wager on EFI. Let's see "lsblk -f" from one of the victims where your manual partitioning failed initially.

Interesting. I'll attach the output. The strange UUIDs belong to the other NVME drive (containing a windoze installation for dual booting)...

colorpurple21859 · 10-24-2020, 09:43 PM

The first thing that stands out is the size of your /boot partition 94M, that may be to small, would recommend at least 512M.

syg00 · 10-24-2020, 11:47 PM

As it happens, you don't actually need a separate /boot partition even for a LUKS encrypted system. Setup is more complex, and I don't know it Mint supports it from the installer. I'd doubt it actually. I'll toss in a thought - why in hell do you want to encrypt the OS itself ?. Give them a separate /home and encrypt that.

As for your system, the odd UUIDs aren't actually UUIDs at all - Microsoft filesystems don't include them, so Linux generates a fudged entry just for convenience; most people can't tolerate inconsistency ...

As suggested above, you need to allocate an EFI mountpoint to the installer - best IMHO to use the Windoze one on /dev/nvme1n1p1. Personally I wouldn't use a /boot partition at all, but it's easily accommodated even with an EFI.

Martinus2u · 10-25-2020, 03:40 AM

OK, thanks. Would it be wrong to have two separate EFI partitions, one on each NVME drive? That would give me the option of taking out a drive at will. I think I'll just try it out.

According to df, the boot partition is 30% full at this point in time.

Regarding encryption, I don't like the performance overhead at all, but we live in Orwellian times. It is always hard to control what data ends up where, in /var/cache, /tmp, /opt etc. and with LUKS you need a key for every volume. Doing / is just the most simple option... I'll think about it.

syg00 · 10-25-2020, 04:08 AM

Quote:

Originally Posted by Martinus2u

Would it be wrong to have two separate EFI partitions, one on each NVME drive? That would give me the option of taking out a drive at will. I think I'll just try it out.

Feel free on your own machine - don't do it on systems that will be used by technically naive users. At some random time in the future the firmware will enumerate the devices differently. The machine will boot, but no operating system will ... guess who will get an irate phone call.

Martinus2u · 10-25-2020, 06:57 AM

Creating an EFI partition on the first NVME worked fine, windoze boots from it, but Mint still baulks with the "root fs not found" panic. /etc/fstab has the correct UUIDs this time. I noticed in the editor snippet that I get when hitting "e" from the grub menu, on the kernel command line, it says root=/dev/nvme0n1p3 (which is technically correct). I changed it to root=UUID=722a3c99-96a1-4158-91f2-43996924843a but it still fails. So I'm a little bit out of my depth, other than trying to club everything into a single partition.

lsblk output is attached.

Martinus2u · 10-25-2020, 11:19 AM

OK, having spent way too much time on this issue already my verdict is as follows: for some unknown reason it is impossible to set up an installation with / and /boot on different partitions with the Mint 20 installer. The grub stanza it creates looks correct (I changed the last line to UUID= with no effect):

Code:

menuentry 'Linux Mint 20 Cinnamon' --class linuxmint --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-722a3c99-96a1-4158-91f2-43996924843a' {
	recordfail
	load_video
	gfxmode $linux_gfx_mode
	insmod gzio
	if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
	insmod part_gpt
	insmod ext2
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root  91ddc4b1-6778-4475-9497-17cbee644bfd
	else
	  search --no-floppy --fs-uuid --set=root 91ddc4b1-6778-4475-9497-17cbee644bfd
	fi
	linux /vmlinuz-5.4.0-26-generic root=UUID=722a3c99-96a1-4158-91f2-43996924843a ro quiet splash 
}

It is correct that the grub variable "root" points to /boot, while the kernel command line parameter "root" points to /. Why it doesn't work I cannot tell. It only works if both point to the same partition.

Together with the constantly freezing nouveau driver, my first impression has been less than stellar...