Strictly speaking, UUID is not addressing at all.
Addressing is very, very simple: read drive X sector Y - or else. Read memory address Z - or else. Addressing is simple, fast, leaves not much room for interpretation, and it's everywhere.
UUID is not addressing. Instead it's searching, finding, sometimes waiting for devices to appear, and also ...
The plain numbering scheme is not actually used in recent systems (with "recent" being Ubuntu 9 and later, other distributions may have adapted in that era, too).
You are correct in observing the root partition is set with the plain numbering scheme. But this only is a default or fall-back setting which is usually overridden with the very next command, such ...
Also do not forget labels. They aren't as unique as UUIDs, but much more informative, and make your fstab human readable. If it's your desktop, or a small company--in other words, you are managing a few to a few dozens drives, you may prefer labels to UUIDs.
Musing over @frostschutz's excellent answer to your question, one scenario when you would likely ...
Not a solution but a couple of Workarounds.
Apparently, that's a bug in os-prober .
I personally tried the second one and it works!
To quote from the link:
Workaround 1: (proaction)
When you are reaching
the “Install the GRUB boot loader to the master boot record?” prompt,
(in my case, no such prompt appeared but i figured out timing of the grub-...
You don't need live boot utilities or boot-repair for this.
Boot into kali, then run sudo efibootmgr (or just efibootmgr as root).
It should display a list that should look something like this:
Timeout: 1 seconds
BootOrder: 0000,0001 <there may be other 4-digit numbers on this line>
<... possibly ...
I did everything like in the guide except I did not generate a new random key and added it to the harddisk but used the passphrase I always used and wrote that into a file.
Passphrase in file works fine, but it must not have newline at the end.
Verify that it works with --key-file option:
cryptsetup open --verbose --key-file yourfile --test-passphrase /...
So, as a solution;
Background: I'm using Arch Linux. It uses mkinitcpio to generate its initramfs (and the early userspace(!)). Because we are booting a filesystem image from the NTFS, we need to tweak the initramfs. We can use GRUB and its ntfs module to read (GRUB ntfs module is ro afaik.) the kernel and initramfs from the NTFS partition. After this we ...
Both schemes can be mixed and matched with most linux distributions.
The consequences can be desirable or undesirable depending on use case - for example, one might prefer the older scheme (and even disable udev-style persistence hacks) if hot replacement of (virtual hardware or actual hardware) drives without having to modify configuration files is wanted.
To allow selecting a boot menu option (as-is, without editing it) without a username/password query when GRUB has password(s) configured, you'll need to add the --unrestricted option to its menuentry line in grub.cfg.
You probably already have set superusers="your_username" set in your grub.cfg.
Example from GRUB manual, with non-relevant parts elided:
I had EXACTLY the same issue as you described, down to the tee. I had to make an account just to let you know my brother!
After much frustration, i have found a permanent solution. You need to flash the BIOS. My BIOS was version 301, and when i download version 309 and applied it, now everything works correctly, i can install the latest version of Kali, AND ...
GRUB uses the system firmware routines (i.e. BIOS in your case) for all of its disk I/O operations, so if BIOS cannot read the SD card, GRUB won't be able to do it either.
GRUB's job is to load the Linux kernel and initramfs files to RAM, and then transfer control to the Linux kernel. At that point, GRUB's job is done and it won't be involved in any ...
It turns out the problem had to do with the location of the grub file, and the fact that I was using the wrong path for it.
I orignially tried to use
grub2-mkconfig -o /etc/grub2.cfg
But I should have used /boot/efi/EFI/centos/grub.cfg. as the path to the grub file. So the actual command should be
grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
This is ...
There is a third cause, which happened be my issue:
Typically in each grub menu item, there is a 'linux ... ' line and a 'initrd .... ' line.
Because I had run out of room in /boot, I had removed an initrd.... file, ran update-initramfs for a different kernel version, but neglected to run update-grub, which will update the appropriate entries.
I repaired ...
I know this question is old, but I still wanted to share what I found as this is still relevant. In my case, I was trying to convert the Terminus Bold font.
Warning: do not feel too motivated, I still couldn't convert psf to pf2 in the end, but others have reported that it did work for them. Maybe you will be one of the lucky ones. It may also depend on ...
I believe this was the main culprit and was in need of a change.
It was as simple as booting up the system on the SATA drive and running:
# gdisk /dev/nvme0n1
x for experts menu
g for new disk GUID
R for randomize
w to write changes to disk
y to confirm
The disk UUID had been changed... No need to change both of them, of course.
# fdisk -...
You cannot remove or modify any file from within grub.
It is clearly stated in the grub manual:
GRUB deliberately does not implement support for writing files in
order to minimise the possibility of the boot loader being responsible
for file system corruption.
and later on
Since GRUB intentionally contains no code for writing to file systems,
/boot/grub contains all of GRUB (which is split up into modules). The purpose of GRUB is to provide an environment from which a full-blown operating system can be booted; GRUB has become a small operating system in its own right, with modules providing support for a variety of storage devices, file systems, encryption layers, software RAID layers, partition ...
You might need to reduce the number of files in the sda5 containing 123Gb to fit into the sdb with 111G capacity. Is that a problem?
Create a new partition on sdb for your Linux and maybe a swap partition. If your computer has a UEFI BIOS then you would need a ESP partiton. I imagine the 123Gb have some files that could be deleted or moved to a USB drive. ...
Use blkid or e2label /dev/sda1 to get the partition label then replace it in your fstab, the root option in grub.cfg file is different, it is used to set the root file system.
Add the following lines to your /etc/defaut/grub :
Then edit the 2 lines in your /boot/grub/grub.cfg as follows:
You should set GRUB_RECORDFAIL_TIMEOUT=0 in your /etc/default/grub then run update-grub.
info -f grub -n 'Simple configuration' | less -p 'GRUB_RECORDFAIL_TIMEOUT'
If this option is set, it overrides the default recordfail setting.
A setting of -1 causes GRUB to wait for user input indefinitely.
However, a false positive in ...
Reading your grub.cfg file, the part that is the immediate cause of the first LUKS password request is this:
cryptomount -u 99cc765bd11945e7a922436c76cfd505
So, it looks like update-grub is preparing to read something from a LVM-based filesystem. What might that ...
I'm not a Kali user, this is just a suggestion of something to try much more than an out right answer.
Given that Kali is based on Debian there's a reasonable chance of sharing boot issues.
There's an answer (here https://unix.stackexchange.com/a/255583/20140 ) which points to issues with graphics drivers.
You do have access to get an unbootable system ...
PXELINUX is not "doing symlinks": it's just downloading a configuration file whose name includes the client's IP or MAC address or part of it. The fact that the matching file happens to be a symlink is entirely between you and your TFTP server that provides the file to PXELINUX.
Note that unlike PXELINUX, GRUB only looks for a single configuration file, ...
It looks like some of your disks aren't always getting detected in a reliable way. This suggests a possible hardware or firmware problem.
Check the health of your disks with Windows CrystalDiskInfo or Linux smartctl command. For example, to check disk /dev/sda:
smartctl -i -HA -l error -f brief /dev/sda
If all your disks are good, see if your BIOS ...
Your trick with grub.conf is working solution. Also you can apply one of the next approaches:
Download kernel rpm package with yumdownloader and install kernel package with --noscripts parameter to ignore scripts which configure package by running prerun, postrun ... scripts during package are being configured. There is no way to tell --noscripts to yum ...
x86-64 CPUs, from both AMD and Intel, pre-date UEFI, so it was common for a while to see 64-bit systems with only old-style BIOSs. It is still possible to boot them, with new kernels, so it should be possible to boot your Packard Bell.
I can’t guarantee that your failure is unrelated, but it could easily be related to something else. Attempting to kill init ...
The answer to your second question ("why does this addressing scheme continue to be used?") is, I guess, inertia. Yes, it is totally possible to use only UUIDs on GPT partitioned disks. You can use UUIDs instead of /dev/xxx names in /etc/fstab. And now that we have the Discoverable Partitions Specification, in many cases you don't even have to specify the ...
There is no need for chroot. Mounting the ESP prior to running grub-install should be sufficient. grub-install should pick it up automagically. Use --no-nvram to leave EFI variables untouched.
grub-install --target=x86_64-efi --bootloader-id="Void Linux [GRUB]" --no-nvram /dev/sdb
/etc/default/grub is not used by grub-install. It is only relevant for grub-...
When GRUB boots from a MBR, the number of legacy BIOS compatibility steps it needs to take at the beginning of the boot process means that the code actually in the MBR is only capable of loading one disk block whose LBA number is patched in to the MBR code at the time of installation. That block is usually the first block of GRUB core image. It contains the ...