2016-09-07 11:40 GMT+03:00 Neil Bothwick <n...@digimed.co.uk>: > On Wed, 7 Sep 2016 09:22:59 +0300, gevisz wrote: > >> After many attempts, I finally managed to boot with the new drive >> attached manually editing the above entry in /boot/grub/grub.cfg >> 1) deleting the root=UUID=44*** part of its line (which probably means >> that adding GRUB_CMDLINE_LINUX="root=UUID=44***" line to >> the /etc/default/grub was a bad idea :), >> 2) changing in the same last line sdb3 to sdc3, and > > Which is fine, until you next run grub-mkconfig. As Mike said, if you use > an initramfs, GRUB will then use UUIDs, avoiding all this.
It used it anyway, but cannot find a boot partion by the UUID if the order of hard disks has been changed. > Another possibility is that your new drive is connected to a lower > numbered SATA port, which is why it jumps in front of the old drive in the > device allocation. Connecting your boot drive to the lowest numbered > port may avoid future queue-jumping. Exactly! Now, I see the problem as follows: When I connected a new SATA disk to the SATA controller, the order of hard disks during the boot time changed because the new disk "jumpt in front" of the boot drive. As the result, the GRUB could not find the boot partition by its UUID on the "wrong" non-boot drive and gave up, without trying to look for the boot partition on other hard drives! When I connected the new hard disk after the boot, it (predictably) did not "jumped in front" of other hard disks. So, doing # grub-mkconfig -o /boot/grub/grub.cfg, creating a new initramfs, etc, did not helped the GRUB to boot the system next time... Only after I managed to boot the system manually editing the GRUB menu entry during the boot time and the system booted with the new hard disk that in this case took its "usual" order and then run # grub-mkconfig -o /boot/grub/grub.cfg, the problem has been "solved." Here, I am writing the "solved" in quotes because it has been solved only for me and only on this computer: next time, when I or someone else will add a new disk to any linux computer the problem may appear again. So, the question remains: why not to desing the GRUB in such a way that it could look for the boot partition by its UUID on any available hard drives?
