On Mon, 5 Jul 2021 at 02:46, Stella Ashburne <[email protected]> wrote: > > Sent: Sunday, July 04, 2021 at 12:01 PM > > From: "David" <[email protected]>
> > As I mentioned, I do not know GPT and UEFI systems. > It's off-topic; I am curious why you do not use GPT/UEFI/Secure Boot? > Secure Boot has been supported since Debian Buster. Let's stay on topic. > What did you mean by "prefix"? Would you like to elaborate? grub> echo "$prefix" And read the grub docs. > > Doing that, grub should attempt to boot the specified files, perhaps > > giving further error messages as a clue to what might be > > wrong. Did you try this method? > No, I didn't. Let's take a step back, I'd like to set out my view of the situation. 1) grub is a boot manager. If you give it correct information, it can boot an operating system. The correct information can be read from a grub.cfg somewhere, or if that fails, someone can type the correct information at the grub> prompt. 2) Back in the old days, people had to write their own grub.cfg file. It was pretty simple, just a few commands to tell grub what to boot. Because people did this, they were familiar with those commands, so they weren't scared to type them at the grub> prompt when they needed to rescue a system. The grub> prompt even had tab-completion, for exactly this reason. 3) These days, grub comes with 'grub-update' that generates a grub.cfg file somewhere. Unfortunately this file contains so much complicated junk that people can't easily see how to rescue their system by typing at the grub> prompt. However it is no harder than the old days, if you know what to type. 4) Knowing what to type is a useful skill. It is easiest to learn this on a non-broken system. 5) Your original post said that you have a grub> prompt, but no menu. This means that grub is running on your system just fine, but it does not know where to look for any grub.cfg file. So at that point, your system does not need a rescue disk, grub just needs to be told what to boot. 6) Perhaps something else is broken, but attempting to boot from the grub> prompt will help to diagnose that. That is certain, and straightforward. I have given you the steps to try, but you have not yet reported trying it. 7) Inside grub, the 'prefix' variable defines where grub finds its own code. That appears to be correct, otherwise you would see grub_rescue> prompt. 8) Inside grub, the 'root' variable defines the device root for all filenames specified, including grub.cfg. It just defines what '/' means at the start of a file pathname. If full device pathnames are specified to grub, then 'root' isn't used. 9) I suppose you can use a rescue environment and chroot to boot your system, but it seems unnecessary unless you can't boot any other way. But if you have a broken initrd, you will need to do this. 10) Once booted, you will need to 'grub-install' to fix the problem of grub.cfg not being found. Because grub currently can't find any grub.cfg, you need to make sure that the new one is installed to the correct location, which needs to be outside your encrypted partition. I would not be surprised if the /boot in your new installation is not the same as your boot partition, you should check that. Check your mountpoints. Does 'lsblk -f' show the boot partition is mounted at /boot? Run 'grub-install -v <your_device>' and look for output like: grub-install: info: setting the root device to <some_device> Make sure <some_device> is your unencrypted boot partition. If it isn't, run 'grub-install' again with the '--boot-directory' option pointing to your boot partition. Read 'man grub-install' for documentation of its options. 11) Now you have plenty of suggestions that you could try. For example: a) Can you boot from grub> prompt? b) At grub>, can you check the value of $root to discover where it is looking for grub.cfg? grub> echo "$root" c) At grub>, can you find grub.cfg anywhere by the tab-completion method I described in a prior message? Where? d) After booting somehow, if you run 'grub-install -v', what root device does it use to to save the files that it updates, as explained above? e) If you reboot after running 'grub-install', does it work? f) Is the value of '$root' above the same location that 'grub-install' writes to by default? If not, use its '--boot-directory' option.
