Neon system grub boot error -- can I devine what to do? /dev/?

[Schwarzer Kater]

If you want to continue on this path…
https://www.gnu.org/software/grub/manual/grub/grub.html

[pwrcul]

I already downloaded and burned a DVD with the Debian 12 ISO. It failed to boot as a live system when I tried it some week+ ago, but that may have been before I identified a good USB port to attach my portable DVD ROM drive.
So I will need to learn how to chroot and the fixing tools.
I have a chroot guide, https://bartsimons.me/ubuntu-linux-chroot-guide/ written in 2018 and a few articles.

So an easy boot to grub boot did not work....

[Schwarzer Kater]

There are also other less easy ways than the Debian rescue mode to do this: Arch with their pre-configured chroot or the Rescue System from an openSUSE Leap ISO (https://download.opensuse.org/distri...6_64-Media.iso).

The following example is for booting with the openSUSE Leap Rescue System (more or less off the top of my head - so double-check it , but it should work if only GRUB is the problem…):

• at login just enter root (no password)
• # mount /dev/sdaX /mnt (replace sdaX with the root partition of your KDE neon installation)
• # mount /dev/sdaY /mnt/boot/efi (replace sdaY with the EFI partition of your KDE neon installation)
• # mount -o bind /dev /mnt/dev
• # mount -o bind /run /mnt/run
• # mount -o bind /sys /mnt/sys
• # mount -o bind /proc /mnt/proc
• # chroot /mnt
• # grub-install (possibly grub2-install)
• # exit
• # reboot

Afterwards you should be able to boot into KDE neon again and configure everything to your liking if necessary.

[pwrcul]

Your message arrived as I had entered the austere Debian 12 world.
I decided I wanted something more helpful to people of limited experience.
I will try with what you proposed using openSUSE.
I will download it and burn a CD.

Before that I had looked over other rescue options and had tentatively selected Rescutux 0.73 based on Debian 10.

[pwrcul]

Here are the commands above when executed.
Error messages follow most.
I did not find articles that lept out at me with a clear
explanation of the mounting commands yet that eliminates the errors.

# mount /dev/nvme0n1p3 /mnt
# mount /dev/nvme0n1p1 /mnt/boot/efi
# mount -o bind /dev /mnt/dev
mount.bin: /mnt/dev: mount point does not exist
# mount -o bind /run /mnt/run
mount.bin: /mnt/run: mount point does not exist
# mount -o bind /sys /mnt/sys
mount.bin: /mnt/sys: mount point does not exist
# mount -o bind /proc /mnt/proc
mount.bin: /mnt/proc: mount point does not exist

We did not enter the next command yet
# chroot /mnt

[Schwarzer Kater]

This means that there is no /dev, /run, /sys and /proc on your /dev/nvme0n1p3.
Are you sure this really is the root partition of the system you want to repair GRUB for?!?

What does ls -l /mnt say after you mounted /dev/nvme0n1p3 to it?

Otherwise I would dare to say that the system on /dev/nvme0n1p3 is seriously broken and I would recommend deleting /dev/nvmen0n1p3 and reinstalling…
There is only so much one can do from afar unfortunately.

PS: I just checked the procedure in post # 18 with the Rescue System of an openSUSE Leap USB boot stick and my KDE neon installation.
It worked as intended until installing GRUB (I didn't want to do that, because the GRUB I use is heavily customized for my needs and KDE neon is just one of my test installations…).

[Schwarzer Kater]

[…]
I did not find articles that lept out at me with a clear
explanation of the mounting commands yet that eliminates the errors. […]

Sometimes the simplest way is the most efficient one - from man mount:

"-o, --options opts
Use the specified mount options."

and

"Bind mount operation
Remount part of the file hierarchy somewhere else. The call is:

mount --bind olddir newdir"

If you want to read the man pages online instead of in a terminal: https://man7.org/linux/man-pages/ (most of it is there).

[pwrcul]

Thanks, again.
I had been thinking thinking along the opposite track, that I could create a directory that would include those missing subdirectories--as I had seen in an article that talked like that--but I am still unsure.

Thanks for the man pages tip.

To answer your question: ls -l /mnt gets total 1
drwxr-xr-x 5 root root 512 Apr 9 2020 EFI

Back on Wed, July 19, I did ls (hd2,gpt3) and got the typical Linux file system, I believe.
Could it have lost so much since then?
I exited the openSUSE rescue disk and ended up in the CLI of grub where I did ls and got (hd0) (hd0,gpt3) (hd0,gpt2) (hd0,gpt1)
I then did ls (hd0,gpt3) and got ./ ../ lost+found/ dev/ proc/ run/ sys/ bin lib lib32 lib64 libx32 sbin boot/ etc/ home/ media/ mnt/ opt/ root/ snap/ srv/ tmp/ usr/ var/
That seems like the files are still intact.

I can't grasp the discrepancy between our prior good indications of a file system and the bleak picture from this afternoon, esp. in contrast to ls (hd0,gpt3).
I am puzzled.

[Schwarzer Kater]

[…]
To answer your question: ls -l /mnt gets total 1
drwxr-xr-x 5 root root 512 Apr 9 2020 EFI

This means your /dev/nvme0n1p3 is empty, if you mounted it correctly…
And your EFI was mounted to the wrong place, probably because there was no root partition in /mnt with the right directories to mount to.

I exited the openSUSE rescue disk and ended up in the CLI of grub where I did ls and got (hd0) (hd0,gpt3) (hd0,gpt2) (hd0,gpt1)
I then did ls (hd0,gpt3) and got ./ ../ lost+found/ dev/ proc/ run/ sys/ bin lib lib32 lib64 libx32 sbin boot/ etc/ home/ media/ mnt/ opt/ root/ snap/ srv/ tmp/ usr/ var/
That seems like the files are still intact.

I can't grasp the discrepancy between our prior good indications of a file system and the bleak picture from this afternoon, esp. in contrast to ls (hd0,gpt3).
I am puzzled.

I suppose that your hd0,gpt3 just isn't /dev/nvme0n1p3 then… = /dev/nvme0n1p3 doesn't seem to be your KDE neon's root partition (if you mounted it correctly as already said above).
My NVMe M2 drive is at hd3, for example - but every motherboard handles these things differently.

Did you check with e.g. lsblk and lsblk -f in the Leap Rescue System before mounting anything?
-> You really have to be sure about the partitions you mounted before something like chroot and/or installing GRUB to an EFI partition!
This also applies to the Debian rescue mode or any other more comfortable way of chroot.

[pwrcul]

I have had repeated problems with my laptop in which formatting disappeared, so please bear with me.

lsblk yields a table. I will put in what I think are the main items
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 141.9M 1 loop
loop1 7:1 0 14.3 1 loop
loop2 7:2 0 42.6 1 loop /mounts/mp_0000
loop3 7:3 0 50.2 1 loop /mounts/mp_0001
loop4 7:4 0 4.1 1 loop /mounts/mp_0002
loop5 7:5 0 141.9 1 loop /parts/mp_0000
sda 8:0 1 0B 0 disk
sdb 8:16 1 0B 0 disk
sdc 8:32 1 0B 0 disk
sdd 8:48 1 0B 0 disk
sro 11:0 1 4.1G 0 rom
zram0 253:0 0B 0 disk
nvme0n1 259:0 931.5G 0 disk
nvme0n1n1p1 259:1 37M 0 part
nvme0n1n1p2 259:2 2 0 part
nvme0n1n1p3 259:3 488.3G 0 part

Note that Neon is on half of the nvme0n1 disk in partition 3.
lsblk -f yields another table

NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
loop0 squashf 4.0
loop1 squashf 4.0
loop2 squashf 4.0
loop3 squashf 4.0
loop4 squashf 4.0
loop5 squashf 4.0
sda
sdb
sdc
sdd
sr0 iso9660 Joliett Ex
zram0
nvme0n1
nvme0n1p1FAT32
nvme0n1p2
nvme0n1p3 ext4

[Schwarzer Kater]

So if you are sure which one it is the right root partition of your KDE neon, try the steps in post # 18 again and perhaps use [Tab] for auto-completion when entering commands to avoid wrong characters.
But lsblk -f before and after mounting e.g. nvme0n1p3 to /mnt and then check again that it worked as intended with ls -l /mnt and if not keep trying to find out why.
That's all I can say for now.

[pwrcul]

Thank you, Schwarzer Kater, and all.
I am ready to move on unless you know some other tool to try.

With CLI grub> ls (hd0,gpt1) is efi
With openSUSE rescue nvme0n1p1 does not exist as in mount /dev/nvme0n1p1 /mnt/boot/efi

I checked Rescatux and their Super Grub2 Disk.
They report that the efi partition is not useable so cannot mount at /boot/efi

Unless there is a way to rewrite the efi partition I see no chance,
# mount /dev/nvme0n1p3 /mnt succeeds but at other times my Neon partition does not do well.

With my modest level of experience and understanding I am willing to believe I have done my due diligence and now reinstall.

Any further suggestions are welcome.

[krodrig2]

I have not tried this but MX Linux has a lot of pre-configured tools one focused on fixing boot, you could try booting the live Cd and running that tool.