| 1 |
On Tue, Sep 6, 2016 at 4:10 PM, Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
| 2 |
> On 06/09/2016 21:39, gevisz wrote: |
| 3 |
>> |
| 4 |
>> 2016-09-06 22:08 GMT+03:00 Rich Freeman <rich0@g.o>: |
| 5 |
>>> |
| 6 |
>>> On Tue, Sep 6, 2016 at 3:01 PM, gevisz <gevisz@×××××.com> wrote: |
| 7 |
>>>> |
| 8 |
>>>> |
| 9 |
>>>> I have already looked into this file but did not find where to set the |
| 10 |
>>>> UUID of the root partion. |
| 11 |
>>>> |
| 12 |
>>> |
| 13 |
>>> It depends. :) |
| 14 |
>>> |
| 15 |
>>> Usually you end up with root=UUID=abc on your kernel command line. It |
| 16 |
>>> looks like grub-mkconfig is supposed to do this automatically. |
| 17 |
>> |
| 18 |
>> |
| 19 |
>> I do agree and suspect that it is a bug in grub-mkconfig. |
| 20 |
>> |
| 21 |
>> Why otherwise adding a new unformatted disk to the system |
| 22 |
>> should prevent grub from finding a root (and boot :) partition |
| 23 |
>> if it already been set in fstab? |
| 24 |
> |
| 25 |
> Easy. BIOS/efi and/or udev has decided to renumber your drives and give them |
| 26 |
> different node names. |
| 27 |
> |
| 28 |
|
| 29 |
Adding a new disk would not affect the UUID of existing disks, so as |
| 30 |
long as grub-mkconfig is setting them on the command line you won't |
| 31 |
have this issue. |
| 32 |
|
| 33 |
Whether or not there is a bug is another matter. If you tell |
| 34 |
grub-mkconfig to not use UUID then it will comply. And then |
| 35 |
renumbering can certainly cause issues. |
| 36 |
|
| 37 |
-- |
| 38 |
Rich |
Archives