[gentoo-user] Kernel does not boot after adding a new SATA drive

[gentoo-user] Kernel does not boot after adding a new SATA drive

[gevisz]

I had one IDE hard drive for /
and one SATA hard drive for /home

After adding another (yet non-formatted) SATA hard drive
the system panics and complains that it cannot find kernel
(if I understood it correctly :).

As it happens after the GRUB(2) menu, I suspect GRUB(2).

Just executed
# grub-mkconfig -o /boot/grub/grub.cfg
but have not tried to reboot yet.

After disconnecting a new hard drive, the system boot normally.

Any ideas?

[gentoo-user] Re: Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-06 21:16 GMT+03:00 gevisz <gevisz@gmail.com>:
> I had one IDE hard drive for /
> and one SATA hard drive for /home
>
> After adding another (yet non-formatted) SATA hard drive
> the system panics and complains that it cannot find kernel
> (if I understood it correctly :).
>
> As it happens after the GRUB(2) menu, I suspect GRUB(2).
>
> Just executed
> # grub-mkconfig -o /boot/grub/grub.cfg
> but have not tried to reboot yet.
>
> After disconnecting a new hard drive, the system boot normally.
>
> Any ideas?

P.S. Just forgot to say that everything works fine if I connect the
      new SATA drive already after booting the system.

Re: [gentoo-user] Re: Kernel does not boot after adding a new SATA drive

[Willie M]

[-- Attachment #1.1: Type: text/plain, Size: 1034 bytes --]

On 09/06/2016 11:20 AM, gevisz wrote:
> 2016-09-06 21:16 GMT+03:00 gevisz <gevisz@gmail.com>:
>> I had one IDE hard drive for /
>> and one SATA hard drive for /home
>>
>> After adding another (yet non-formatted) SATA hard drive
>> the system panics and complains that it cannot find kernel
>> (if I understood it correctly :).
>>
>> As it happens after the GRUB(2) menu, I suspect GRUB(2).
>>
>> Just executed
>> # grub-mkconfig -o /boot/grub/grub.cfg
>> but have not tried to reboot yet.
>>
>> After disconnecting a new hard drive, the system boot normally.
>>
>> Any ideas?
> 
> P.S. Just forgot to say that everything works fine if I connect the
>       new SATA drive already after booting the system.
> 

Your /dev/sd* devices are changing when you boot with the new drive most
likely. Try taking the new drive out and reconfigure your system to boot
with UUID's for the drives instead of /dev/sda1 or whatever it is in
your case.

-- 

Willie Matthews
matthews.willie80@gmail.com
702.659.9966


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] Re: Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-06 21:24 GMT+03:00 Willie M <matthews.willie80@gmail.com>:
> On 09/06/2016 11:20 AM, gevisz wrote:
>> 2016-09-06 21:16 GMT+03:00 gevisz <gevisz@gmail.com>:
>>> I had one IDE hard drive for /
>>> and one SATA hard drive for /home
>>>
>>> After adding another (yet non-formatted) SATA hard drive
>>> the system panics and complains that it cannot find kernel
>>> (if I understood it correctly :).
>>>
>>> As it happens after the GRUB(2) menu, I suspect GRUB(2).
>>>
>>> Just executed
>>> # grub-mkconfig -o /boot/grub/grub.cfg
>>> but have not tried to reboot yet.
>>>
>>> After disconnecting a new hard drive, the system boot normally.
>>>
>>> Any ideas?
>>
>> P.S. Just forgot to say that everything works fine if I connect the
>>       new SATA drive already after booting the system.
>>
>
> Your /dev/sd* devices are changing when you boot with the new drive most
> likely. Try taking the new drive out and reconfigure your system to boot
> with UUID's for the drives instead of /dev/sda1 or whatever it is in
> your case.

Thank you for the prompt reply but as I have just written to Neil,
in my fstab, all the old drives are specified by UUID.
And the new one does not have UUID yet.

Where else should I specify them?

Do you think that running
# grub-mkconfig -o /boot/grub/grub.cfg
with a new drive connected will be enough?

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

On Tue, 6 Sep 2016 21:16:12 +0300, gevisz wrote:

> I had one IDE hard drive for /
> and one SATA hard drive for /home
> 
> After adding another (yet non-formatted) SATA hard drive
> the system panics and complains that it cannot find kernel
> (if I understood it correctly :).
> 
> As it happens after the GRUB(2) menu, I suspect GRUB(2).
> 
> Just executed
> # grub-mkconfig -o /boot/grub/grub.cfg
> but have not tried to reboot yet.
> 
> After disconnecting a new hard drive, the system boot normally.

It sounds like you are specifying the root device by device node and
those have changed with the addition of a new drive. Using UUID or LABEL
will avoid this problem.


-- 
Neil Bothwick

And then Adam said, "What's a headache?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-06 21:21 GMT+03:00 Neil Bothwick <neil@digimed.co.uk>:
> On Tue, 6 Sep 2016 21:16:12 +0300, gevisz wrote:
>
>> I had one IDE hard drive for /
>> and one SATA hard drive for /home
>>
>> After adding another (yet non-formatted) SATA hard drive
>> the system panics and complains that it cannot find kernel
>> (if I understood it correctly :).
>>
>> As it happens after the GRUB(2) menu, I suspect GRUB(2).
>>
>> Just executed
>> # grub-mkconfig -o /boot/grub/grub.cfg
>> but have not tried to reboot yet.
>>
>> After disconnecting a new hard drive, the system boot normally.
>
> It sounds like you are specifying the root device by device node and
> those have changed with the addition of a new drive. Using UUID or LABEL
> will avoid this problem.

Thank you for the prompt reply!

In my fstab, all the old drives are specified by UUID.
And the new one does not have UUID yet.

But it seems that GRUB does not read fstab... :(

Where else should I specify them?

Do you think that running
# grub-mkconfig -o /boot/grub/grub.cfg
with a new drive connected will be enough?

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Willie M]

[-- Attachment #1.1: Type: text/plain, Size: 1293 bytes --]

On 09/06/2016 11:38 AM, gevisz wrote:
> 2016-09-06 21:21 GMT+03:00 Neil Bothwick <neil@digimed.co.uk>:
>> On Tue, 6 Sep 2016 21:16:12 +0300, gevisz wrote:
>>
>>> I had one IDE hard drive for /
>>> and one SATA hard drive for /home
>>>
>>> After adding another (yet non-formatted) SATA hard drive
>>> the system panics and complains that it cannot find kernel
>>> (if I understood it correctly :).
>>>
>>> As it happens after the GRUB(2) menu, I suspect GRUB(2).
>>>
>>> Just executed
>>> # grub-mkconfig -o /boot/grub/grub.cfg
>>> but have not tried to reboot yet.
>>>
>>> After disconnecting a new hard drive, the system boot normally.
>>
>> It sounds like you are specifying the root device by device node and
>> those have changed with the addition of a new drive. Using UUID or LABEL
>> will avoid this problem.
> 
> Thank you for the prompt reply!
> 
> In my fstab, all the old drives are specified by UUID.
> And the new one does not have UUID yet.
> 
> But it seems that GRUB does not read fstab... :(
> 
> Where else should I specify them?
> 
> Do you think that running
> # grub-mkconfig -o /boot/grub/grub.cfg
> with a new drive connected will be enough?
> 
 I edit the /etc/default/grub.

-- 

Willie Matthews
matthews.willie80@gmail.com


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-06 21:45 GMT+03:00 Willie M <matthews.willie80@gmail.com>:
> On 09/06/2016 11:38 AM, gevisz wrote:
>> 2016-09-06 21:21 GMT+03:00 Neil Bothwick <neil@digimed.co.uk>:
>>> On Tue, 6 Sep 2016 21:16:12 +0300, gevisz wrote:
>>>
>>>> I had one IDE hard drive for /
>>>> and one SATA hard drive for /home
>>>>
>>>> After adding another (yet non-formatted) SATA hard drive
>>>> the system panics and complains that it cannot find kernel
>>>> (if I understood it correctly :).
>>>>
>>>> As it happens after the GRUB(2) menu, I suspect GRUB(2).
>>>>
>>>> Just executed
>>>> # grub-mkconfig -o /boot/grub/grub.cfg
>>>> but have not tried to reboot yet.
>>>>
>>>> After disconnecting a new hard drive, the system boot normally.
>>>
>>> It sounds like you are specifying the root device by device node and
>>> those have changed with the addition of a new drive. Using UUID or LABEL
>>> will avoid this problem.
>>
>> Thank you for the prompt reply!
>>
>> In my fstab, all the old drives are specified by UUID.
>> And the new one does not have UUID yet.
>>
>> But it seems that GRUB does not read fstab... :(
>>
>> Where else should I specify them?
>>
>> Do you think that running
>> # grub-mkconfig -o /boot/grub/grub.cfg
>> with a new drive connected will be enough?
>>
>  I edit the /etc/default/grub.

I have already looked into this file but did not find where to set the
UUID of the root partion.

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Rich Freeman]

On Tue, Sep 6, 2016 at 3:01 PM, gevisz <gevisz@gmail.com> wrote:
>
> I have already looked into this file but did not find where to set the
> UUID of the root partion.
>

It depends.  :)

Usually you end up with root=UUID=abc on your kernel command line.  It
looks like grub-mkconfig is supposed to do this automatically.

Your initramfs tool may also do something here (I know dracut sticks a
copy of your fstab in the initramfs and uses it to help find the root
partition, assuming you have root in your fstab (if not it will
probably yell at you at some point)).

You have to use an initramfs to use a UUID to mount your root.

-- 
Rich

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-06 22:08 GMT+03:00 Rich Freeman <rich0@gentoo.org>:
> On Tue, Sep 6, 2016 at 3:01 PM, gevisz <gevisz@gmail.com> wrote:
>>
>> I have already looked into this file but did not find where to set the
>> UUID of the root partion.
>>
>
> It depends.  :)
>
> Usually you end up with root=UUID=abc on your kernel command line.  It
> looks like grub-mkconfig is supposed to do this automatically.

I do agree and suspect that it is a bug in grub-mkconfig.

Why otherwise adding a new unformatted disk to the system
should prevent grub from finding a root (and boot :) partition
if it already been set in fstab?

> Your initramfs tool may also do something here (I know dracut sticks a
> copy of your fstab in the initramfs and uses it to help find the root
> partition, assuming you have root in your fstab (if not it will
> probably yell at you at some point)).
>
> You have to use an initramfs to use a UUID to mount your root.

I do use initramfs (created by genkernel) as the system refuses
to boot without it.

I have already thought about it.

Do you think that I  should recreate initramfs anew after adding
a new hard disk?

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Daniel Frey]

On 09/06/2016 12:39 PM, gevisz wrote:
> 2016-09-06 22:08 GMT+03:00 Rich Freeman <rich0@gentoo.org>:
>> On Tue, Sep 6, 2016 at 3:01 PM, gevisz <gevisz@gmail.com> wrote:
>>>
>>> I have already looked into this file but did not find where to set the
>>> UUID of the root partion.
>>>
>>
>> It depends.  :)
>>
>> Usually you end up with root=UUID=abc on your kernel command line.  It
>> looks like grub-mkconfig is supposed to do this automatically.
> 
> I do agree and suspect that it is a bug in grub-mkconfig.
> 
> Why otherwise adding a new unformatted disk to the system
> should prevent grub from finding a root (and boot :) partition
> if it already been set in fstab?

Because either the BIOS (or the kernel itself) is rearranging your
device names when you plug the new device in.


> 
>> Your initramfs tool may also do something here (I know dracut sticks a
>> copy of your fstab in the initramfs and uses it to help find the root
>> partition, assuming you have root in your fstab (if not it will
>> probably yell at you at some point)).
>>
>> You have to use an initramfs to use a UUID to mount your root.

I ran into this myself and I don't remember having to use an initramfs
to fix it. In my case I believe it was USB devices mucking it up and I
was able to fix it by building sata into the kernel and USB as modules
so it wouldn't mess up my boot order. I don't think this will work in
your case though.

I see you are still using IDE drives, so perhaps the kernel is loading
the sata and ide order differently when adding a new drive.


Dan

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-06 22:48 GMT+03:00 Daniel Frey <djqfrey@gmail.com>:
> On 09/06/2016 12:39 PM, gevisz wrote:
>> 2016-09-06 22:08 GMT+03:00 Rich Freeman <rich0@gentoo.org>:
>>> On Tue, Sep 6, 2016 at 3:01 PM, gevisz <gevisz@gmail.com> wrote:
>>>>
>>>> I have already looked into this file but did not find where to set the
>>>> UUID of the root partion.
>>>>
>>>
>>> It depends.  :)
>>>
>>> Usually you end up with root=UUID=abc on your kernel command line.  It
>>> looks like grub-mkconfig is supposed to do this automatically.
>>
>> I do agree and suspect that it is a bug in grub-mkconfig.
>>
>> Why otherwise adding a new unformatted disk to the system
>> should prevent grub from finding a root (and boot :) partition
>> if it already been set in fstab?
>
> Because either the BIOS (or the kernel itself) is rearranging your
> device names when you plug the new device in.

After the GRUB menu, it should be GRUB.

But why, on earth, it does not use UUID that has been set in fstab
and was available for grub-mkconfig?

It seems that now I should edit /boot/grub/grub.cfg directly
without even knowing its commands.

>>> Your initramfs tool may also do something here (I know dracut sticks a
>>> copy of your fstab in the initramfs and uses it to help find the root
>>> partition, assuming you have root in your fstab (if not it will
>>> probably yell at you at some point)).
>>>
>>> You have to use an initramfs to use a UUID to mount your root.
>
> I ran into this myself and I don't remember having to use an initramfs
> to fix it. In my case I believe it was USB devices mucking it up and I
> was able to fix it by building sata into the kernel and USB as modules
> so it wouldn't mess up my boot order. I don't think this will work in
> your case though.
>
> I see you are still using IDE drives, so perhaps the kernel is loading
> the sata and ide order differently when adding a new drive.
>
>
> Dan
>

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Rich Freeman]

On Tue, Sep 6, 2016 at 4:57 PM, gevisz <gevisz@gmail.com> wrote:
>
> It seems that now I should edit /boot/grub/grub.cfg directly
> without even knowing its commands.
>

Well, if nothing else you can certainly read it and see what it is
putting in there.  If you page down you'll hit the actual menus which
are readable enough.

While the autogenerated menus are fairly complex, the reality is that
grub2 is able to handle simple configuration files the same way that
grub1 was.  The format is slightly different though.  So, that is
always a fallback.  However, I'd check /etc/defaults/grub to make sure
you don't have it set to suppress UUIDs.  That will, obviously,
suppress UUIDs.

-- 
Rich

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-07 0:07 GMT+03:00 Rich Freeman <rich0@gentoo.org>:
> On Tue, Sep 6, 2016 at 4:57 PM, gevisz <gevisz@gmail.com> wrote:
>>
>> It seems that now I should edit /boot/grub/grub.cfg directly
>> without even knowing its commands.
>>
>
> Well, if nothing else you can certainly read it and see what it is
> putting in there.  If you page down you'll hit the actual menus which
> are readable enough.
>
> While the autogenerated menus are fairly complex, the reality is that
> grub2 is able to handle simple configuration files the same way that
> grub1 was.  The format is slightly different though.  So, that is
> always a fallback.  However, I'd check /etc/defaults/grub to make sure
> you don't have it set to suppress UUIDs.  That will, obviously,
> suppress UUIDs.
# Copyright 1999-2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$
#
# To populate all changes in this file you need to regenerate your
# grub configuration file afterwards:
#     'grub2-mkconfig -o /boot/grub/grub.cfg'
#
# See the grub info page for documentation on possible variables and
# their associated values.

GRUB_DISTRIBUTOR="Gentoo"

# Default menu entry
GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
# Boot the default entry this many seconds after the menu is displayed
GRUB_TIMEOUT=7
#GRUB_TIMEOUT_STYLE=menu

# Append parameters to the linux kernel command line
#GRUB_CMDLINE_LINUX=""
#
# Examples:
#
# Boot with network interface renaming disabled
# GRUB_CMDLINE_LINUX="net.ifnames=0"
#
# Boot with systemd instead of sysvinit (openrc)
# GRUB_CMDLINE_LINUX="init=/usr/lib/systemd/systemd"

# Append parameters to the linux kernel command line for non-recovery entries
#GRUB_CMDLINE_LINUX_DEFAULT=""

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal.
# Note that you can use only modes which your graphic card supports via VBE.
# You can see them in real GRUB with the command `vbeinfo'.
#GRUB_GFXMODE=640x480

# Set to 'text' to force the Linux kernel to boot in normal text
# mode, 'keep' to preserve the graphics mode set using
# 'GRUB_GFXMODE', 'WIDTHxHEIGHT'['xDEPTH'] to set a particular
# graphics mode, or a sequence of these separated by commas or
# semicolons to try several modes in sequence.
#GRUB_GFXPAYLOAD_LINUX=

# Path to theme spec txt file.
# The starfield is by default provided with use truetype.
# NOTE: when enabling custom theme, ensure you have required font/etc.
#GRUB_THEME="/boot/grub/themes/starfield/theme.txt"

# Background image used on graphical terminal.
# Can be in various bitmap formats.
#GRUB_BACKGROUND="/boot/grub/mybackground.png"

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to kernel
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY=true

# Uncomment to disable generation of the submenu and put all choices on
# the top-level menu.
# Besides the visual affect of no sub menu, this makes navigation of the
# menu easier for a user who can't see the screen.
#GRUB_DISABLE_SUBMENU=y

# Uncomment to play a tone when the main menu is displayed.
# This is useful, for example, to allow users who can't see the screen
# to know when they can make a choice on the menu.
#GRUB_INIT_TUNE="60 800 1"

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Alan McKinnon]

On 06/09/2016 21:39, gevisz wrote:
> 2016-09-06 22:08 GMT+03:00 Rich Freeman <rich0@gentoo.org>:
>> On Tue, Sep 6, 2016 at 3:01 PM, gevisz <gevisz@gmail.com> wrote:
>>>
>>> I have already looked into this file but did not find where to set the
>>> UUID of the root partion.
>>>
>>
>> It depends.  :)
>>
>> Usually you end up with root=UUID=abc on your kernel command line.  It
>> looks like grub-mkconfig is supposed to do this automatically.
>
> I do agree and suspect that it is a bug in grub-mkconfig.
>
> Why otherwise adding a new unformatted disk to the system
> should prevent grub from finding a root (and boot :) partition
> if it already been set in fstab?


Easy. BIOS/efi and/or udev has decided to renumber your drives and give 
them different node names.

All my Dell laptops are like that - firmware sees the ssd as the first 
drive and that's the name grub uses. The kernel and udev see them in the 
opposite order so auto tools for grub always get it wrong.

It's common, nothing to get upset about. It's one of the reasons why 
udev does the tricks it does.





>
>> Your initramfs tool may also do something here (I know dracut sticks a
>> copy of your fstab in the initramfs and uses it to help find the root
>> partition, assuming you have root in your fstab (if not it will
>> probably yell at you at some point)).
>>
>> You have to use an initramfs to use a UUID to mount your root.
>
> I do use initramfs (created by genkernel) as the system refuses
> to boot without it.
>
> I have already thought about it.
>
> Do you think that I  should recreate initramfs anew after adding
> a new hard disk?
>

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Rich Freeman]

On Tue, Sep 6, 2016 at 4:10 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 06/09/2016 21:39, gevisz wrote:
>>
>> 2016-09-06 22:08 GMT+03:00 Rich Freeman <rich0@gentoo.org>:
>>>
>>> On Tue, Sep 6, 2016 at 3:01 PM, gevisz <gevisz@gmail.com> wrote:
>>>>
>>>>
>>>> I have already looked into this file but did not find where to set the
>>>> UUID of the root partion.
>>>>
>>>
>>> It depends.  :)
>>>
>>> Usually you end up with root=UUID=abc on your kernel command line.  It
>>> looks like grub-mkconfig is supposed to do this automatically.
>>
>>
>> I do agree and suspect that it is a bug in grub-mkconfig.
>>
>> Why otherwise adding a new unformatted disk to the system
>> should prevent grub from finding a root (and boot :) partition
>> if it already been set in fstab?
>
> Easy. BIOS/efi and/or udev has decided to renumber your drives and give them
> different node names.
>

Adding a new disk would not affect the UUID of existing disks, so as
long as grub-mkconfig is setting them on the command line you won't
have this issue.

Whether or not there is a bug is another matter.  If you tell
grub-mkconfig to not use UUID then it will comply.  And then
renumbering can certainly cause issues.

-- 
Rich

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

On Tue, 6 Sep 2016 21:38:07 +0300, gevisz wrote:

> > It sounds like you are specifying the root device by device node and
> > those have changed with the addition of a new drive. Using UUID or
> > LABEL will avoid this problem.  
> 
> Thank you for the prompt reply!
> 
> In my fstab, all the old drives are specified by UUID.
> And the new one does not have UUID yet.
> 
> But it seems that GRUB does not read fstab... :(

It does not, because it has not loaded the kernel yet, so it cannot do
anything on the system.
 
> Where else should I specify them?

grub.cfg in the kernel options.

> Do you think that running
> # grub-mkconfig -o /boot/grub/grub.cfg
> with a new drive connected will be enough?

grub-mkconfig should use UUIDs by default, unless you have uncommented

#GRUB_DISABLE_LINUX_UUID=true

in /etc/default/grub


-- 
Neil Bothwick

Top Oxymorons Number 8: Tight slacks

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-06 22:54 GMT+03:00 Neil Bothwick <neil@digimed.co.uk>:
> On Tue, 6 Sep 2016 21:38:07 +0300, gevisz wrote:
>
>> > It sounds like you are specifying the root device by device node and
>> > those have changed with the addition of a new drive. Using UUID or
>> > LABEL will avoid this problem.
>>
>> Thank you for the prompt reply!
>>
>> In my fstab, all the old drives are specified by UUID.
>> And the new one does not have UUID yet.
>>
>> But it seems that GRUB does not read fstab... :(
>
> It does not, because it has not loaded the kernel yet, so it cannot do
> anything on the system.

Oh, poor little Grand Unified Boot Loader!

It cannot do anything! Even to read fstab by its grub-mkconfig script!

P.S. I usually run grub-mkconfig when kernel is already loaded!
      And in my fstab all the disks are refered by UUID!

>> Where else should I specify them?
>
> grub.cfg in the kernel options.
>
>> Do you think that running
>> # grub-mkconfig -o /boot/grub/grub.cfg
>> with a new drive connected will be enough?
>
> grub-mkconfig should use UUIDs by default, unless you have uncommented
>
> #GRUB_DISABLE_LINUX_UUID=true

I did not. So, it is a bug in a almighty Grand Unified Boot Loader!

> in /etc/default/grub
>
>
> --
> Neil Bothwick
>
> Top Oxymorons Number 8: Tight slacks

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Alan McKinnon]

On 06/09/2016 23:05, gevisz wrote:
> 2016-09-06 22:54 GMT+03:00 Neil Bothwick <neil@digimed.co.uk>:
>> On Tue, 6 Sep 2016 21:38:07 +0300, gevisz wrote:


>> grub-mkconfig should use UUIDs by default, unless you have uncommented
>>
>> #GRUB_DISABLE_LINUX_UUID=true
> 
> I did not. So, it is a bug in a almighty Grand Unified Boot Loader!



or the MUCH more likely: you did it wrong.
That's something you seem to do a lot of.
You might want to look into that.
Also the bit where you listen to others who have done it right.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]

On Wed, 7 Sep 2016 00:05:32 +0300, gevisz wrote:

> >> But it seems that GRUB does not read fstab... :(  
> >
> > It does not, because it has not loaded the kernel yet, so it cannot do
> > anything on the system.  
> 
> Oh, poor little Grand Unified Boot Loader!
> 
> It cannot do anything! Even to read fstab by its grub-mkconfig script!

We were talking about GRUB the bootloader, not grub-mkconfig the Linux
program to write grub.cfg. As you were asking whether you should run
grub-mkconfig again, it seems reasonable to assume that you haven't run
it since adding the disk, not that it should make a difference.

> P.S. I usually run grub-mkconfig when kernel is already loaded!
>       And in my fstab all the disks are refered by UUID!
> 

grub-mkconfig doesn't care about the fstab of the running distro since it
scans your drives for all operating systems it can boot.

Either look in grub.cfg to see what it going on or post it here along
with the exact error messages so others may try for you.


-- 
Neil Bothwick

Too many clicks spoil the browse.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-07 0:32 GMT+03:00 Neil Bothwick <neil@digimed.co.uk>:
> On Wed, 7 Sep 2016 00:05:32 +0300, gevisz wrote:
>
>> >> But it seems that GRUB does not read fstab... :(
>> >
>> > It does not, because it has not loaded the kernel yet, so it cannot do
>> > anything on the system.
>>
>> Oh, poor little Grand Unified Boot Loader!
>>
>> It cannot do anything! Even to read fstab by its grub-mkconfig script!
>
> We were talking about GRUB the bootloader, not grub-mkconfig the Linux
> program to write grub.cfg. As you were asking whether you should run
> grub-mkconfig again, it seems reasonable to assume that you haven't run
> it since adding the disk, not that it should make a difference.
>
>> P.S. I usually run grub-mkconfig when kernel is already loaded!
>>       And in my fstab all the disks are refered by UUID!
>>
>
> grub-mkconfig doesn't care about the fstab of the running distro since it
> scans your drives for all operating systems it can boot.
>
> Either look in grub.cfg to see what it going on or post it here along
> with the exact error messages so others may try for you.
>

I have added the following line to the /etc/default/grub

GRUB_CMDLINE_LINUX="root=UUID=44***"

run

# grub-mkconfig -o /boot/grub/grub.cfg

and got in  the following entry

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Gentoo GNU/Linux' --class gentoo --class gnu-linux --class
gnu --class os $menuentry_id_option 'gnulinux-simple-44***' {
    load_video
    insmod gzio
    insmod part_msdos
    insmod ext2
    set root='hd1,msdos3'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos3
--hint-efi=hd1,msdos3 --hint-baremetal=ahci1,msdos3
--hint='hd1,msdos3'  44***
    else
      search --no-floppy --fs-uuid --set=root 44***
    fi
    echo    'Loading Linux 4.4.6-gentoo ...'
    linux    /boot/vmlinuz-4.4.6-gentoo root=/dev/sdb3 ro
}

wich, in my view, does not differ a lot from what was before.

The 44*** denotes the UUID of my boot partition.

Will try it tomorrow and report.

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 2029 bytes --]

On Wed, 7 Sep 2016 01:03:19 +0300, gevisz wrote:

> > grub-mkconfig doesn't care about the fstab of the running distro
> > since it scans your drives for all operating systems it can boot.
> >
> > Either look in grub.cfg to see what it going on or post it here along
> > with the exact error messages so others may try for you.
> >  
> 
> I have added the following line to the /etc/default/grub
> 
> GRUB_CMDLINE_LINUX="root=UUID=44***"

Why? Did you read the relevant section of the GRUB manual before doing
this?
 
> run
> 
> # grub-mkconfig -o /boot/grub/grub.cfg
> 
> and got in  the following entry
> 
> ### BEGIN /etc/grub.d/10_linux ###
> menuentry 'Gentoo GNU/Linux' --class gentoo --class gnu-linux --class
> gnu --class os $menuentry_id_option 'gnulinux-simple-44***' {
>     load_video
>     insmod gzio
>     insmod part_msdos
>     insmod ext2
>     set root='hd1,msdos3'
>     if [ x$feature_platform_search_hint = xy ]; then
>       search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos3
> --hint-efi=hd1,msdos3 --hint-baremetal=ahci1,msdos3
> --hint='hd1,msdos3'  44***
>     else
>       search --no-floppy --fs-uuid --set=root 44***
>     fi
>     echo    'Loading Linux 4.4.6-gentoo ...'
>     linux    /boot/vmlinuz-4.4.6-gentoo root=/dev/sdb3 ro
                                          ~~~~~~~~~~~~~~
> }
> 
> wich, in my view, does not differ a lot from what was before.

We'll have to take your word for that as you didn't post what you had
before, but things don't have to differ a lot to break.

However, the problem is clear in the menu you posted, it is using
root=/dev/sdb3. When you connect anther drive, they are renumbered and
that points to the wrong drive.

> The 44*** denotes the UUID of my boot partition.

Why obfuscate it? It's only a UUID not your online banking password.


-- 
Neil Bothwick

When you go to court you are putting yourself in the hands of 12 people
that were not smart enough to get out of jury duty.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Mike Gilbert]

On Tue, Sep 6, 2016 at 6:03 PM, gevisz <gevisz@gmail.com> wrote:
> 2016-09-07 0:32 GMT+03:00 Neil Bothwick <neil@digimed.co.uk>:
>> On Wed, 7 Sep 2016 00:05:32 +0300, gevisz wrote:
>>
>>> >> But it seems that GRUB does not read fstab... :(
>>> >
>>> > It does not, because it has not loaded the kernel yet, so it cannot do
>>> > anything on the system.
>>>
>>> Oh, poor little Grand Unified Boot Loader!
>>>
>>> It cannot do anything! Even to read fstab by its grub-mkconfig script!
>>
>> We were talking about GRUB the bootloader, not grub-mkconfig the Linux
>> program to write grub.cfg. As you were asking whether you should run
>> grub-mkconfig again, it seems reasonable to assume that you haven't run
>> it since adding the disk, not that it should make a difference.
>>
>>> P.S. I usually run grub-mkconfig when kernel is already loaded!
>>>       And in my fstab all the disks are refered by UUID!
>>>
>>
>> grub-mkconfig doesn't care about the fstab of the running distro since it
>> scans your drives for all operating systems it can boot.
>>
>> Either look in grub.cfg to see what it going on or post it here along
>> with the exact error messages so others may try for you.
>>
>
> I have added the following line to the /etc/default/grub
>
> GRUB_CMDLINE_LINUX="root=UUID=44***"
>
> run
>
> # grub-mkconfig -o /boot/grub/grub.cfg
>
> and got in  the following entry
>
> ### BEGIN /etc/grub.d/10_linux ###
> menuentry 'Gentoo GNU/Linux' --class gentoo --class gnu-linux --class
> gnu --class os $menuentry_id_option 'gnulinux-simple-44***' {
>     load_video
>     insmod gzio
>     insmod part_msdos
>     insmod ext2
>     set root='hd1,msdos3'
>     if [ x$feature_platform_search_hint = xy ]; then
>       search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos3
> --hint-efi=hd1,msdos3 --hint-baremetal=ahci1,msdos3
> --hint='hd1,msdos3'  44***
>     else
>       search --no-floppy --fs-uuid --set=root 44***
>     fi
>     echo    'Loading Linux 4.4.6-gentoo ...'
>     linux    /boot/vmlinuz-4.4.6-gentoo root=/dev/sdb3 ro
> }
>
> wich, in my view, does not differ a lot from what was before.
>
> The 44*** denotes the UUID of my boot partition.
>
> Will try it tomorrow and report.
>

grub-mkconfig is not finding an initramfs, as evidenced by the lack of
an "initrd" in in grub.cfg.

If it is unable to find an initramfs, it will always output
root=/dev/sdX instead of root=UUID=...

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Rich Freeman]

On Tue, Sep 6, 2016 at 11:36 PM, Mike Gilbert <floppym@gentoo.org> wrote:
>
> grub-mkconfig is not finding an initramfs, as evidenced by the lack of
> an "initrd" in in grub.cfg.
>
> If it is unable to find an initramfs, it will always output
> root=/dev/sdX instead of root=UUID=...
>

For whatever reason the three subsequent replies to this list ignored
the actual explanation of the cause of the problems, which was this
(not uncommon on this list it seems).

This is also why it is helpful to post actual config files when you
have problems.  The lines you consider most relevant aren't
necessarily the ones containing the clues.

When root=UUID=... was added manually to the command line, then the
kernel refused to boot at all, because the kernel itself doesn't
understand that syntax.

So, the next question becomes, how are you generating an initramfs,
and how is it named?  Pasting the output of "ls /boot" might be
helpful here.

-- 
Rich

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-07 12:36 GMT+03:00 Rich Freeman <rich0@gentoo.org>:
> On Tue, Sep 6, 2016 at 11:36 PM, Mike Gilbert <floppym@gentoo.org> wrote:
>>
>> grub-mkconfig is not finding an initramfs, as evidenced by the lack of
>> an "initrd" in in grub.cfg.
>>
>> If it is unable to find an initramfs, it will always output
>> root=/dev/sdX instead of root=UUID=...
>>
>
> For whatever reason the three subsequent replies to this list ignored
> the actual explanation of the cause of the problems, which was this
> (not uncommon on this list it seems).
>
> This is also why it is helpful to post actual config files when you
> have problems.  The lines you consider most relevant aren't
> necessarily the ones containing the clues.
>
> When root=UUID=... was added manually to the command line, then the
> kernel refused to boot at all, because the kernel itself doesn't
> understand that syntax.

Yes, when the "root=UUID=***" has been added manually to /etc/default/grub
in the wrong way, it appeared in the GRUB menu entry in the wrong way that
stopped GRUB from booting in any case...

> So, the next question becomes, how are you generating an initramfs,
> and how is it named?  Pasting the output of "ls /boot" might be
> helpful here.

I generate initramfs by
# genkernel --install initramfs
and the rename it to match the name of the kernel, eg,
initramfs-4.4.6-gentoo
vmlinuz-4.4.6-gentoo

But I think that this is unrelevant to the problem because of the following
explanation I have just posted. (If I am wrong here, please, let me know
and I will post all the conf files you will ask.)

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 even trying to look for the boot partition by its UUID 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 connected, 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?

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Raffaele BELARDI]

gevisz wrote:
> 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?

Why don't you ask to the GRUB designers? This is a GENTOO mailing list.

raffaele

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Rich Freeman]

On Wed, Sep 7, 2016 at 7:57 AM, gevisz <gevisz@gmail.com> wrote:
> 2016-09-07 12:36 GMT+03:00 Rich Freeman <rich0@gentoo.org>:
>> On Tue, Sep 6, 2016 at 11:36 PM, Mike Gilbert <floppym@gentoo.org> wrote:
>>>
>>> grub-mkconfig is not finding an initramfs, as evidenced by the lack of
>>> an "initrd" in in grub.cfg.
>>>
>>> If it is unable to find an initramfs, it will always output
>>> root=/dev/sdX instead of root=UUID=...
>>>
>>
>> For whatever reason the three subsequent replies to this list ignored
>> the actual explanation of the cause of the problems, which was this
>> (not uncommon on this list it seems).
>>
>> When root=UUID=... was added manually to the command line, then the
>> kernel refused to boot at all, because the kernel itself doesn't
>> understand that syntax.
>
> Yes, when the "root=UUID=***" has been added manually to /etc/default/grub
> in the wrong way, it appeared in the GRUB menu entry in the wrong way that
> stopped GRUB from booting in any case...

It doesn't matter how you add root=UUID=* to the kernel command line.
The kernel doesn't understand that syntax at all.  Your initramfs
probably does.

When you don't use an initramfs (and you aren't using one, even if you
think you are), the kernel reads the value of root= and mounts it as
root.  It doesn't understand the UUID syntax.

When you do use an initramfs then the kernel ignores the root=
setting, and the initramfs reads it and mounts root.  Typically these
do understand the UUID syntax, but of course that depends on what
initramfs you're using.

>
>> So, the next question becomes, how are you generating an initramfs,
>> and how is it named?  Pasting the output of "ls /boot" might be
>> helpful here.
>
> I generate initramfs by
> # genkernel --install initramfs
> and the rename it to match the name of the kernel, eg,
> initramfs-4.4.6-gentoo
> vmlinuz-4.4.6-gentoo

And if you read /etc/grub.d/10_linux you'll see that the script
doesn't look for an initramfs with the filename initramfs-<version>.

It will accept initramfs-<version>.img or initramfs-genkernel-<version>

It accepts 11 other variations of the filename, but not the one you picked.

So, grub-mkconfig doesn't think you have an initramfs, so it generated
a configuration file which:
1.  Doesn't load an initramfs (so any attempt to stick a root=UUID=*
option in there will fail).
2.  Just references the device name for root that it finds, since that
is the best it can do without an initramfs.

>
> But I think that this is unrelevant to the problem because of the following
> explanation I have just posted. (If I am wrong here, please, let me know
> and I will post all the conf files you will ask.)

No need, your filenames likely solved the problem.  Just tack a .img
on the end of that initramfs and you should be good after running
grub-mkconfig again.

>
> 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 even trying to look for the boot partition by its UUID on other
> hard drives!

Grub doesn't look for boot partitions at all.  Grub just reads the
configuration file and loads the kernel (and optionally initramfs)
that it finds in grub.cfg.  In your case the grub.cfg didn't list an
initramfs, so it didn't load one.

The initramfs generated by genkernel will look for a drive by UUID,
and as long as the device exists it will probably find it.  Obviously
if you're missing a kernel module needed to access the drive that
would stop it.  However, it doesn't care what order the devices are
numbered in.

>
> 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?
>

It already does this.  It just doesn't do it when it doesn't think
you're using an initramfs, because if it did it would make your system
unbootable, since the kernel doesn't know anything about UUIDs.

-- 
Rich

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-07 16:19 GMT+03:00 Rich Freeman <rich0@gentoo.org>:
> On Wed, Sep 7, 2016 at 7:57 AM, gevisz <gevisz@gmail.com> wrote:
>> 2016-09-07 12:36 GMT+03:00 Rich Freeman <rich0@gentoo.org>:
>>> On Tue, Sep 6, 2016 at 11:36 PM, Mike Gilbert <floppym@gentoo.org> wrote:
>>>>
>>>> grub-mkconfig is not finding an initramfs, as evidenced by the lack of
>>>> an "initrd" in in grub.cfg.
>>>>
>>>> If it is unable to find an initramfs, it will always output
>>>> root=/dev/sdX instead of root=UUID=...
>>>>
>>>
>>> For whatever reason the three subsequent replies to this list ignored
>>> the actual explanation of the cause of the problems, which was this
>>> (not uncommon on this list it seems).
>>>
>>> When root=UUID=... was added manually to the command line, then the
>>> kernel refused to boot at all, because the kernel itself doesn't
>>> understand that syntax.
>>
>> Yes, when the "root=UUID=***" has been added manually to /etc/default/grub
>> in the wrong way, it appeared in the GRUB menu entry in the wrong way that
>> stopped GRUB from booting in any case...
>
> It doesn't matter how you add root=UUID=* to the kernel command line.
> The kernel doesn't understand that syntax at all.  Your initramfs
> probably does.
>
> When you don't use an initramfs (and you aren't using one, even if you
> think you are),

I have removed all my initramfs files from the /boot and found out
that the system boots anyway. So, you are right.

Before doing this I was sure that it is not the case because back in 2013,
when I first installed Gentoo, the system refused to boot until I created
ininramfs...

> the kernel reads the value of root= and mounts it as
> root.  It doesn't understand the UUID syntax.
>
> When you do use an initramfs then the kernel ignores the root=
> setting, and the initramfs reads it and mounts root.  Typically these
> do understand the UUID syntax, but of course that depends on what
> initramfs you're using.
>
>>
>>> So, the next question becomes, how are you generating an initramfs,
>>> and how is it named?  Pasting the output of "ls /boot" might be
>>> helpful here.
>>
>> I generate initramfs by
>> # genkernel --install initramfs
>> and the rename it to match the name of the kernel, eg,
>> initramfs-4.4.6-gentoo
>> vmlinuz-4.4.6-gentoo
>
> And if you read /etc/grub.d/10_linux you'll see that the script
> doesn't look for an initramfs with the filename initramfs-<version>.
>
> It will accept initramfs-<version>.img or initramfs-genkernel-<version>
>
> It accepts 11 other variations of the filename, but not the one you picked.
>
> So, grub-mkconfig doesn't think you have an initramfs, so it generated
> a configuration file which:
> 1.  Doesn't load an initramfs (so any attempt to stick a root=UUID=*
> option in there will fail).
> 2.  Just references the device name for root that it finds, since that
> is the best it can do without an initramfs.
>
>>
>> But I think that this is unrelevant to the problem because of the following
>> explanation I have just posted. (If I am wrong here, please, let me know
>> and I will post all the conf files you will ask.)
>
> No need, your filenames likely solved the problem.  Just tack a .img
> on the end of that initramfs and you should be good after running
> grub-mkconfig again.

I did this, and now have the following GRUB menu entry in /boot/grub/grub:
menuentry 'Gentoo GNU/Linux' --class gentoo --class gnu-linux --class
gnu --class os $menuentry_id_option 'gnulinux-simple-44***' {
    load_video
    insmod gzio
    insmod part_msdos
    insmod ext2
    set root='hd2,msdos3'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos3
--hint-efi=hd2,msdos3 --hint-baremetal=ahci2,msdos3  44***
    else
      search --no-floppy --fs-uuid --set=root 44***
    fi
    echo    'Loading Linux 4.4.6-gentoo ...'
    linux    /boot/vmlinuz-4.4.6-gentoo root=UUID=44*** ro
    echo    'Loading initial ramdisk ...'
    initrd    /boot/initramfs-4.4.6-gentoo.img
}
where, again, 44*** stands for the UUID of my root-boot partition.

So, here you are, again, right.

>> 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 even trying to look for the boot partition by its UUID on other
>> hard drives!
>
> Grub doesn't look for boot partitions at all.  Grub just reads the
> configuration file and loads the kernel (and optionally initramfs)
> that it finds in grub.cfg.  In your case the grub.cfg didn't list an
> initramfs, so it didn't load one.
>
> The initramfs generated by genkernel will look for a drive by UUID,
> and as long as the device exists it will probably find it.  Obviously
> if you're missing a kernel module needed to access the drive that
> would stop it.  However, it doesn't care what order the devices are
> numbered in.
>
>>
>> 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?
>>
>
> It already does this.  It just doesn't do it when it doesn't think
> you're using an initramfs, because if it did it would make your system
> unbootable, since the kernel doesn't know anything about UUIDs.

But, here, I cannot agree with you because of the following:

What you have just said implies that I had not had a problem
booting the system after adding a new drive had I used initramfs
correctly. Well, I do agree that, after loading the initramfs, the system
may find the kernel to load with the help of initramfs that understands
UUID. However, how the GRUB could find the initramfs in the first place,
if it could not find the kerner allocated in the same directory as the
initramfs itself?

Moreover, in the GRUB menu entry provided above, the initramfs loads
already after the kernel. So, using the initramfs should be irrelevant to
the question of finding the kernel to load by GRUB.

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Rich Freeman]

On Wed, Sep 7, 2016 at 2:25 PM, gevisz <gevisz@gmail.com> wrote:
>
> What you have just said implies that I had not had a problem
> booting the system after adding a new drive had I used initramfs
> correctly. Well, I do agree that, after loading the initramfs, the system
> may find the kernel to load with the help of initramfs that understands
> UUID. However, how the GRUB could find the initramfs in the first place,
> if it could not find the kerner allocated in the same directory as the
> initramfs itself?

grub-mkconfig simply searches for a configurable list of filename
specifications which your initramfs didn't match.  Since /boot could
contain all sorts of files, with all sorts of naming conventions, it
obviously would be very difficult to accomodate any possible naming
convention.  We apparently do have it set up to search the filenames
generated by the initramfs tools we actually use, so as long as you
don't go renaming them you're probably fine.

At boot time grub doesn't search for anything.  It simply reads the
config file and does what it tells it.

>
> Moreover, in the GRUB menu entry provided above, the initramfs loads
> already after the kernel. So, using the initramfs should be irrelevant to
> the question of finding the kernel to load by GRUB.
>

Grub is loading the kernel in your case.  The kernel just isn't
mounting the root filesystem since there is no initramfs to tell it
how to do that.  Grub has nothing to do with mounting root at boot
time.

Grub also loads the initramfs before it ever executes the kernel.  The
kernel doesn't know how to load an initramfs from disk.  It expects it
to be in RAM when it runs.

The initramfs loaded by grub is just a cpio image that is copied into
RAM, and I believe the address gets passed as a kernel command line
argument (one you don't even see in grub, it appends it at runtime).
The kernel creates a ramfs, extracts the cpio image into the ramfs,
and executes init inside of it.  At that point the kernel is
essentially done with booting the system, the initramfs can mount and
pivot to a new root, or the whole system could just run off of an
initramfs until it shuts down.  This is why the kernel developers have
shunned kernel mounting logic/etc in favor of the initramfs; it moves
more of the logic into userspace where it is easier to
change/maintain/etc, and doesn't have to necessarily run with kernel
privs either.  Heck, your initramfs could go out on the network, pull
in another kernel image and initramfs, and kexec that (which I think
is basically the design of coreboot which is a linux-based
bootloader).


-- 
Rich

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-07 21:46 GMT+03:00 Rich Freeman <rich0@gentoo.org>:
> On Wed, Sep 7, 2016 at 2:25 PM, gevisz <gevisz@gmail.com> wrote:
>>
>> What you have just said implies that I had not had a problem
>> booting the system after adding a new drive had I used initramfs
>> correctly. Well, I do agree that, after loading the initramfs, the system
>> may find the kernel to load with the help of initramfs that understands
>> UUID. However, how the GRUB could find the initramfs in the first place,
>> if it could not find the kerner allocated in the same directory as the
>> initramfs itself?
>
> grub-mkconfig simply searches for a configurable list of filename
> specifications which your initramfs didn't match.  Since /boot could
> contain all sorts of files, with all sorts of naming conventions, it
> obviously would be very difficult to accomodate any possible naming
> convention.  We apparently do have it set up to search the filenames
> generated by the initramfs tools we actually use, so as long as you
> don't go renaming them you're probably fine.
>
> At boot time grub doesn't search for anything.  It simply reads the
> config file and does what it tells it.
>
>>
>> Moreover, in the GRUB menu entry provided above, the initramfs loads
>> already after the kernel. So, using the initramfs should be irrelevant to
>> the question of finding the kernel to load by GRUB.
>>
>
> Grub is loading the kernel in your case.  The kernel just isn't
> mounting the root filesystem since there is no initramfs to tell it
> how to do that.  Grub has nothing to do with mounting root at boot
> time.
>
> Grub also loads the initramfs before it ever executes the kernel.  The
> kernel doesn't know how to load an initramfs from disk.  It expects it
> to be in RAM when it runs.
>
> The initramfs loaded by grub is just a cpio image that is copied into
> RAM, and I believe the address gets passed as a kernel command line
> argument (one you don't even see in grub, it appends it at runtime).
> The kernel creates a ramfs, extracts the cpio image into the ramfs,
> and executes init inside of it.  At that point the kernel is
> essentially done with booting the system, the initramfs can mount and
> pivot to a new root, or the whole system could just run off of an
> initramfs until it shuts down.  This is why the kernel developers have
> shunned kernel mounting logic/etc in favor of the initramfs; it moves
> more of the logic into userspace where it is easier to
> change/maintain/etc, and doesn't have to necessarily run with kernel
> privs either.  Heck, your initramfs could go out on the network, pull
> in another kernel image and initramfs, and kexec that (which I think
> is basically the design of coreboot which is a linux-based
> bootloader).
> --
> Rich
>

Yes, with initramfs, system boots even if I remove a (non-boot :) disk
or add another one. I reply a bit later because needed some time to
check all the possible situations. Thank you for the help!

Now the problem solved indeed.

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-07 1:03 GMT+03:00 gevisz <gevisz@gmail.com>:
> 2016-09-07 0:32 GMT+03:00 Neil Bothwick <neil@digimed.co.uk>:
>> On Wed, 7 Sep 2016 00:05:32 +0300, gevisz wrote:
>>
>>> >> But it seems that GRUB does not read fstab... :(
>>> >
>>> > It does not, because it has not loaded the kernel yet, so it cannot do
>>> > anything on the system.
>>>
>>> Oh, poor little Grand Unified Boot Loader!
>>>
>>> It cannot do anything! Even to read fstab by its grub-mkconfig script!
>>
>> We were talking about GRUB the bootloader, not grub-mkconfig the Linux
>> program to write grub.cfg. As you were asking whether you should run
>> grub-mkconfig again, it seems reasonable to assume that you haven't run
>> it since adding the disk, not that it should make a difference.
>>
>>> P.S. I usually run grub-mkconfig when kernel is already loaded!
>>>       And in my fstab all the disks are refered by UUID!
>>>
>>
>> grub-mkconfig doesn't care about the fstab of the running distro since it
>> scans your drives for all operating systems it can boot.
>>
>> Either look in grub.cfg to see what it going on or post it here along
>> with the exact error messages so others may try for you.
>>
>
> I have added the following line to the /etc/default/grub
>
> GRUB_CMDLINE_LINUX="root=UUID=44***"
>
> run
>
> # grub-mkconfig -o /boot/grub/grub.cfg
>
> and got in /boot/grub/grub.cfg the following entry
>
> ### BEGIN /etc/grub.d/10_linux ###
> menuentry 'Gentoo GNU/Linux' --class gentoo --class gnu-linux --class
> gnu --class os $menuentry_id_option 'gnulinux-simple-44***' {
>     load_video
>     insmod gzio
>     insmod part_msdos
>     insmod ext2
>     set root='hd1,msdos3'
>     if [ x$feature_platform_search_hint = xy ]; then
>       search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos3
> --hint-efi=hd1,msdos3 --hint-baremetal=ahci1,msdos3
> --hint='hd1,msdos3'  44***
>     else
>       search --no-floppy --fs-uuid --set=root 44***
>     fi
>     echo    'Loading Linux 4.4.6-gentoo ...'
>     linux    /boot/vmlinuz-4.4.6-gentoo root=/dev/sdb3 ro
> }

Well, actually after adding

GRUB_CMDLINE_LINUX="root=UUID=44***"

line to the /etc/default/grub and running

# grub-mkconfig -o /boot/grub/grub.cfg

the last line in the /boot/grub/grub.cfg became

    linux    /boot/vmlinuz-4.4.6-gentoo-ntfs root=/dev/sdb3 ro root=UUID=44***

> The 44*** denotes the UUID of my boot partition.

after that the system stopped booting at all, complaining after the GRUB menu:
VFS: cannot open root device "UUID=44***" or ...
with and without the new drive attached. :(

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
 3) changing hd1 and ahci1 throughout the entry to hd3 and ahci3
     (currently I am not sure about the last number but will find it
out in the next boots)
     wich is strange as BIOS reports that the boot disk sits on the
0th IDE chanel and
     the other two (SATA) drives - on the 1st and 2nd IDE chanels.

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Alan McKinnon]

On 07/09/2016 08:22, gevisz wrote:
>  3) changing hd1 and ahci1 throughout the entry to hd3 and ahci3
>      (currently I am not sure about the last number but will find it
> out in the next boots)
>      wich is strange as BIOS reports that the boot disk sits on the
> 0th IDE chanel and
>      the other two (SATA) drives - on the 1st and 2nd IDE chanels.




No it is not strange at all, it is quite common. Refer to all the
replies other people gave you explaining that it does happen. Bios,
grub, kernel OS - 4 different things, 4 codebases, 4 opinions on how to
order things. And the kernel has never guaranteed any mapping at all
between device order on the bus and node names.

Deal with it, live with it.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

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.

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.


-- 
Neil Bothwick

Accordion: a bagpipe with pleats.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Dutch Ingraham]

On Tue, Sep 06, 2016 at 10:32:35PM +0100, Neil Bothwick wrote:
> On Wed, 7 Sep 2016 00:05:32 +0300, gevisz wrote:
> 
> 
> grub-mkconfig doesn't care about the fstab of the running distro since it
> scans your drives for all operating systems it can boot.
> 
Sorry if I missed something in this tome, but I was under the impression that 
a seperate utility, os-prober (or something similar), was needed to scan outside
of the current partition.  Some distros do not include this type of utility by 
default, but it has been 3 years since I installed my Gentoo and I just don't
remember.  Is this off-topic?

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

On Tue, 6 Sep 2016 18:22:54 -0500, Dutch Ingraham wrote:

> > grub-mkconfig doesn't care about the fstab of the running distro
> > since it scans your drives for all operating systems it can boot.
> >   
> Sorry if I missed something in this tome, but I was under the
> impression that a seperate utility, os-prober (or something similar),
> was needed to scan outside of the current partition.  Some distros do
> not include this type of utility by default, but it has been 3 years
> since I installed my Gentoo and I just don't remember.  Is this
> off-topic?

os-prober scans for Windows and other non-Linux installations.


-- 
Neil Bothwick

Eat shit - 50 million flies can't be wrong
Use Microsoft . . . . .

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Dutch Ingraham]

On Wed, Sep 07, 2016 at 12:38:40AM +0100, Neil Bothwick wrote:
> On Tue, 6 Sep 2016 18:22:54 -0500, Dutch Ingraham wrote:
> 
> > > grub-mkconfig doesn't care about the fstab of the running distro
> > > since it scans your drives for all operating systems it can boot.
> > >   
> > Sorry if I missed something in this tome, but I was under the
> > impression that a seperate utility, os-prober (or something similar),
> > was needed to scan outside of the current partition.  Some distros do
> > not include this type of utility by default, but it has been 3 years
> > since I installed my Gentoo and I just don't remember.  Is this
> > off-topic?
> 
> os-prober scans for Windows and other non-Linux installations.

That's true, but it seems to imply it does not scan for Linux, which is not true
to my understanding.

os-prober is just a shell script, but a little dense for me to make conclusions
of; maybe you can make sense of it, if you have it.  However, the Ubuntu people 
say this:

"30_os-prober This script uses os-prober to search for Linux and other operating 
systems and places the results in the GRUB 2 menu.

   1.  The file's sections include options for Windows, Linux, OSX, and Hurd."

The full quote is here:
https://help.ubuntu.com/community/Grub2/Setup

My point was just to see if this information was helpful to the OP.  Like I
said, I kind-of lost track of this thread.  If it's not helpful, that's fine.