Trying to compile a new kernel and getting this on boot
could not find filesystem /dev/root
It boots up fine with the stock FC6 kernel. What am I missing? Thanks in
advance.
Vous m'avez dit r?cemment :
> Trying to compile a new kernel and getting this on boot
>
> could not find filesystem /dev/root
sure it doesn't spit only this to you. Does it panic ? and do FC6
kernels use an initrd (I guess so) ?
> It boots up fine with the stock FC6 kernel. What am I missing?
many reasons can prevent you from booting a vanilla kernel on modern distros
try to figure out what is really exec'ed _after_ the kernel
initialization and _before_ init execution
(hint: initramfs)
--
Mathieu Segaud
On Mon, 2006-11-06 at 11:18 +0100, Mathieu SEGAUD wrote:
> Vous m'avez dit récemment :
>
> > Trying to compile a new kernel and getting this on boot
> >
> > could not find filesystem /dev/root
>
> sure it doesn't spit only this to you. Does it panic ? and do FC6
> kernels use an initrd (I guess so) ?
they do and it's more or less required there (for mount-by-label and
many other things).
But it's easy to do.
In fact, if you use "make install" as the last step in your build
process, the kernel build process will
1) copy the bzImage over to /boot for you
2) make an initrd for your system
3) add the kernel and initrd to grub for you
this is a very convenient step that makes it very robust to do, and
beats doing the manual thing even if you wouldn't do an initrd in terms
of convenience..
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
Arjan van de Ven wrote:
> On Mon, 2006-11-06 at 11:18 +0100, Mathieu SEGAUD wrote:
>
>> Vous m'avez dit récemment :
>>
>>
>>> Trying to compile a new kernel and getting this on boot
>>>
>>> could not find filesystem /dev/root
>>>
>> sure it doesn't spit only this to you. Does it panic ? and do FC6
>> kernels use an initrd (I guess so) ?
>>
>
> they do and it's more or less required there (for mount-by-label and
> many other things).
>
> But it's easy to do.
> In fact, if you use "make install" as the last step in your build
> process, the kernel build process will
> 1) copy the bzImage over to /boot for you
> 2) make an initrd for your system
> 3) add the kernel and initrd to grub for you
>
> this is a very convenient step that makes it very robust to do, and
> beats doing the manual thing even if you wouldn't do an initrd in terms
> of convenience..
>
Yes - I run make - make modules_install - make install. It creates the
initrd files and it alters grub. The stock kernel works and in the past
compiling my own kernel this way worked. I even started with Fedora's
.config file. to make sure I'm compiling the same stuff.
On Monday, 6 November 2006 02:54, Marc Perkel wrote:
> Trying to compile a new kernel and getting this on boot
>
> could not find filesystem /dev/root
Which kernel?
Rafael J. Wysocki wrote:
> On Monday, 6 November 2006 02:54, Marc Perkel wrote:
>
>> Trying to compile a new kernel and getting this on boot
>>
>> could not find filesystem /dev/root
>>
>
> Which kernel?
>
2.6.19rc4
On Monday, 6 November 2006 22:18, Marc Perkel wrote:
>
> Rafael J. Wysocki wrote:
> > On Monday, 6 November 2006 02:54, Marc Perkel wrote:
> >
> >> Trying to compile a new kernel and getting this on boot
> >>
> >> could not find filesystem /dev/root
> >>
> >
> > Which kernel?
> >
>
> 2.6.19rc4
What is the last working version?
Rafael J. Wysocki wrote:
> On Monday, 6 November 2006 22:18, Marc Perkel wrote:
>
>> Rafael J. Wysocki wrote:
>>
>>> On Monday, 6 November 2006 02:54, Marc Perkel wrote:
>>>
>>>
>>>> Trying to compile a new kernel and getting this on boot
>>>>
>>>> could not find filesystem /dev/root
>>>>
>>>>
>>> Which kernel?
>>>
>>>
>> 2.6.19rc4
>>
>
> What is the last working version?
>
Last one I tried that worked other than the stock kernel is 2.6.18 but
I've upgraded from FC5 to FC6 since then.
Marc Perkel wrote:
>
>
> Rafael J. Wysocki wrote:
>
>> On Monday, 6 November 2006 22:18, Marc Perkel wrote:
>>
>>
>>> Rafael J. Wysocki wrote:
>>>
>>>
>>>> On Monday, 6 November 2006 02:54, Marc Perkel wrote:
>>>>
>>>>
>>>>> Trying to compile a new kernel and getting this on boot
>>>>>
>>>>> could not find filesystem /dev/root
>>>>>
>>>>
>>>> Which kernel?
>>>>
>>>
>>> 2.6.19rc4
>>>
>>
>>
>> What is the last working version?
>>
>
>
> Last one I tried that worked other than the stock kernel is 2.6.18 but
> I've upgraded from FC5 to FC6 since then.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
I ran into the same problem when using an FC-6 .config file compiling 2.6.19-rc4. In my case, the problem was that the configuration options for Serial ATA have changed since 2.6.18 (which the FC-6 config is based on). I had to manually go in to the config (with make menuconfig) and turn on the SATA device that I have. What kind of SATA controller do you have, and what does your .config look like?
Chris Lalancette
Chris Lalancette wrote:
> Marc Perkel wrote:
>
>> Rafael J. Wysocki wrote:
>>
>>
>>> On Monday, 6 November 2006 22:18, Marc Perkel wrote:
>>>
>>>
>>>
>>>> Rafael J. Wysocki wrote:
>>>>
>>>>
>>>>
>>>>> On Monday, 6 November 2006 02:54, Marc Perkel wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Trying to compile a new kernel and getting this on boot
>>>>>>
>>>>>> could not find filesystem /dev/root
>>>>>>
>>>>>>
>>>>> Which kernel?
>>>>>
>>>>>
>>>> 2.6.19rc4
>>>>
>>>>
>>> What is the last working version?
>>>
>>>
>> Last one I tried that worked other than the stock kernel is 2.6.18 but
>> I've upgraded from FC5 to FC6 since then.
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
> I ran into the same problem when using an FC-6 .config file compiling 2.6.19-rc4. In my case, the problem was that the configuration options for Serial ATA have changed since 2.6.18 (which the FC-6 config is based on). I had to manually go in to the config (with make menuconfig) and turn on the SATA device that I have. What kind of SATA controller do you have, and what does your .config look like?
>
> Chris Lalancette
>
I'm looking at it now. that is very likely it. I'm using nv_sata
Hello,
> > I ran into the same problem when using an FC-6 .config file
> compiling 2.6.19-rc4. In my case, the problem was that the
> configuration options for Serial ATA have changed since
> 2.6.18 (which the FC-6 config is based on). I had to
> manually go in to the config (with make menuconfig) and turn
> on the SATA device that I have. What kind of SATA controller
> do you have, and what does your .config look like?
I also had nearly the same problem when moving from FC5 kernel to a
stock vanilla kernel : FC5 is heavily relying on modules, and my vanilla
kernel was compiled with everything built-in and no modules.
This is definitely changing the order in which drivers and disks are
discovered
and resulted in drives changing devices :
FC5 Vanilla
/dev/sda <---> /dev/sdb
/dev/sdb <---> /dev/sdc
/dev/sdc <---> /dev/sda
This is a real pain, though people will tell you that udev is supposed
to take care of this... My problem was just that I _don't_ want udev
on my machine...
So, check also this point...
Regards,
Paul
>I also had nearly the same problem when moving from FC5 kernel to a
>stock vanilla kernel : FC5 is heavily relying on modules, and my vanilla
>kernel was compiled with everything built-in and no modules.
>This is definitely changing the order in which drivers and disks are
>discovered
The order in which disks are discovered, is basically
(1) what module (let's take the "core kernel" as a module too) is loaded
first (core kernel always comes first)
(2) running order of the __init functions in a specific module;
running order mostly defined by linking order
>and resulted in drives changing devices :
>FC5 Vanilla
>/dev/sda <---> /dev/sdb
>/dev/sdb <---> /dev/sdc
>/dev/sdc <---> /dev/sda
>
>This is a real pain, though people will tell you that udev is supposed
>to take care of this... My problem was just that I _don't_ want udev
>on my machine...
If you don't want udev, make an initramfs, build your disk driver as
modules, and load them in the order you want your disks numbered.
udev or initramfs, you ought to choose at least one.
>So, check also this point...
-`J'
--
Hello,
> The order in which disks are discovered, is basically
> (1) what module (let's take the "core kernel" as a module
> too) is loaded first (core kernel always comes first)
> (2) running order of the __init functions in a specific module;
> running order mostly defined by linking order
Yes... What is painful is that moving from a configuration with modules
to a configuration without modules, this can change.
> >and resulted in drives changing devices :
> >FC5 Vanilla
> >/dev/sda <---> /dev/sdb
> >/dev/sdb <---> /dev/sdc
> >/dev/sdc <---> /dev/sda
> If you don't want udev, make an initramfs, build your disk driver as
> modules, and load them in the order you want your disks numbered.
>
> udev or initramfs, you ought to choose at least one.
Nope, you don't. I'm now using a kernel without modules for what's disk
related, and unless people (read kernel developpers) change something
in the init order, I'm now with a stable environment, without udev or
initramfs.
Paul
>> If you don't want udev, make an initramfs, build your disk driver as
>> modules, and load them in the order you want your disks numbered.
>>
>> udev or initramfs, you ought to choose at least one.
>
>Nope, you don't. I'm now using a kernel without modules for what's disk
>related, and unless people (read kernel developpers) change something
Yeah, "unless". But the kernel should be considered fuzzy logic in
this area :) after all, it does not even need a kernel developer -- a
binutils contributor might also change something that results in a
change of link order.
On the other side, you can run udev _once_ to create device nodes like
/dev/disk/by-label/ to allow at least correct booting (possibly using
LABEL=) Once the box is up, one can always figure out which drive is
which by looking at fdisk or other info. (Gets a little hard when
they're all the same manufacturer and type, but then again, LABEL=
will work without udev in the "normal" userspace.)
>in the init order, I'm now with a stable environment, without udev or
>initramfs.
>
>Paul
>
-`J'
--
I figured out the problem. the SATA drivers weren't being compiled.
That's because the menu system was rearanged. May I suggest that if you
are going to change the structure that you include some upgrade mapping
so that if old items are mapped to new items and people like me won't
waste many hours just to find out that what I though was selected isn't.
menuconfig needs to be upgrade smart.
Hello,
> Yeah, "unless". But the kernel should be considered fuzzy logic in
> this area :) after all, it does not even need a kernel developer -- a
> binutils contributor might also change something that results in a
> change of link order.
Right... but I do change my kernel more often than my binutils ;)
> On the other side, you can run udev _once_ to create device
> nodes like
> /dev/disk/by-label/ to allow at least correct booting (possibly using
> LABEL=) Once the box is up, one can always figure out which drive is
> which by looking at fdisk or other info. (Gets a little hard when
> they're all the same manufacturer and type, but then again, LABEL=
> will work without udev in the "normal" userspace.)
I may give it a try... Using uuid could also be an option but I'm not
sure this can be configured thru fstab...
Paul
>> On the other side, you can run udev _once_ to create device
>> nodes like
>> /dev/disk/by-label/ to allow at least correct booting (possibly using
>> LABEL=) Once the box is up, one can always figure out which drive is
>> which by looking at fdisk or other info. (Gets a little hard when
>> they're all the same manufacturer and type, but then again, LABEL=
>> will work without udev in the "normal" userspace.)
>
>I may give it a try... Using uuid could also be an option but I'm not
>sure this can be configured thru fstab...
To mount disks using LABEL= or UUID=, as far as I know, you need either
blkid or guessfstype, or a /dev/disk/by-{label,uuid}/ symlink. This
should work even when there is no udev running.
-`J'
--