Gentoo Archives: gentoo-user

From: gevisz <gevisz@×××××.com>
To: "gentoo-user@l.g.o" <gentoo-user@l.g.o>
Subject: [gentoo-user] Re: [Solved but ...] Kernel does not boot after adding a new SATA drive
Date: Wed, 07 Sep 2016 11:39:07
1 2016-09-07 11:40 GMT+03:00 Neil Bothwick <neil@××××××××××.uk>:
2 > On Wed, 7 Sep 2016 09:22:59 +0300, gevisz wrote:
3 >
4 >> After many attempts, I finally managed to boot with the new drive
5 >> attached manually editing the above entry in /boot/grub/grub.cfg
6 >> 1) deleting the root=UUID=44*** part of its line (which probably means
7 >> that adding GRUB_CMDLINE_LINUX="root=UUID=44***" line to
8 >> the /etc/default/grub was a bad idea :),
9 >> 2) changing in the same last line sdb3 to sdc3, and
10 >
11 > Which is fine, until you next run grub-mkconfig. As Mike said, if you use
12 > an initramfs, GRUB will then use UUIDs, avoiding all this.
14 It used it anyway, but cannot find a boot partion by the UUID
15 if the order of hard disks has been changed.
17 > Another possibility is that your new drive is connected to a lower
18 > numbered SATA port, which is why it jumps in front of the old drive in the
19 > device allocation. Connecting your boot drive to the lowest numbered
20 > port may avoid future queue-jumping.
22 Exactly! Now, I see the problem as follows:
24 When I connected a new SATA disk to the SATA controller, the order of
25 hard disks during the boot time changed because the new disk "jumpt
26 in front" of the boot drive. As the result, the GRUB could not find the
27 boot partition by its UUID on the "wrong" non-boot drive and gave up,
28 without trying to look for the boot partition on other hard drives!
30 When I connected the new hard disk after the boot, it (predictably)
31 did not "jumped in front" of other hard disks. So, doing
32 # grub-mkconfig -o /boot/grub/grub.cfg, creating a new initramfs,
33 etc, did not helped the GRUB to boot the system next time...
35 Only after I managed to boot the system manually editing the GRUB
36 menu entry during the boot time and the system booted with the new
37 hard disk that in this case took its "usual" order and then run
38 # grub-mkconfig -o /boot/grub/grub.cfg, the problem has been "solved."
40 Here, I am writing the "solved" in quotes because it has been solved
41 only for me and only on this computer: next time, when I or someone
42 else will add a new disk to any linux computer the problem may appear
43 again.
45 So, the question remains: why not to desing the GRUB in such a way
46 that it could look for the boot partition by its UUID on any available
47 hard drives?