custom kernel without initrd and with udev
 

Howdy,

While surely no expert I've been building my own kernels for
a long time with little trouble but with a recent install of
'Squeeze' I'm stumped. I've built, reconfigured, built again for
several days now. No joy. I've spent hours Googling for any and
everybody's thoughts on the error: 'Kernel panic - not syncing:
VFS: Unable to mount root fs on unknown-block(0,0)' with little luck.

Some one did suggest I decompile the initrd that shipped with
the install. On doing that I discovered that the device files for
the harddrive are created before the drive is mounted. Booting an
'Etch' partition I see that Squeeze's /dev/ is all but empty when
Squeeze is not running which may have something to do with the
failure to mount the root partition.

Is anyone running a custom kernel without an initrd with udev?
Any tips, pointers will be appreciated.

Thanks,
Mike
--
Satisfied user of Linux since 1997.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120706230814.GA2351@playground

custom kernel without initrd and with udev
 

On 07/07/12 00:08, Mike McClain wrote:

Howdy,

While surely no expert I've been building my own kernels for
a long time with little trouble but with a recent install of
'Squeeze' I'm stumped. I've built, reconfigured, built again for
several days now. No joy. I've spent hours Googling for any and
everybody's thoughts on the error: 'Kernel panic - not syncing:
VFS: Unable to mount root fs on unknown-block(0,0)' with little luck.

Some one did suggest I decompile the initrd that shipped with
the install. On doing that I discovered that the device files for
the harddrive are created before the drive is mounted. Booting an
'Etch' partition I see that Squeeze's /dev/ is all but empty when
Squeeze is not running which may have something to do with the
failure to mount the root partition.

Is anyone running a custom kernel without an initrd with udev?


Yes, I am. Although I believe there are some circumstances where this
may not be possible. eg. where something else needs to be started in
order to mount the root filesystem first.


Some of my older machines (kept running for sentimental reasons) need an
old ATA/IDE driver that the current Debian kernels do not include.



Any tips, pointers will be appreciated.


Make sure that *all* filesystem and device drivers for your root
partition are compiled directly into the kernel - not as modules.


Look at what modules are used from your initrd and compile those into
your kernel


In fact, if you are building a kernel specifically for one box (or a set
of similar boxen), it is a good idea to have all/most hardware drivers
built-in. I only have external peripherals (USB/cardbus devices) built
as modules.


--
Dom


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4FF7B35A.8090009@rpdom.net">http://lists.debian.org/4FF7B35A.8090009@rpdom.net

custom kernel without initrd and with udev
 

Hello,

Dom a écrit :
> On 07/07/12 00:08, Mike McClain wrote:
>>
>> While surely no expert I've been building my own kernels for
>> a long time with little trouble but with a recent install of
>> 'Squeeze' I'm stumped. I've built, reconfigured, built again for
>> several days now. No joy. I've spent hours Googling for any and
>> everybody's thoughts on the error: 'Kernel panic - not syncing:
>> VFS: Unable to mount root fs on unknown-block(0,0)' with little luck.

What are the lines preceding the error ?

>> Is anyone running a custom kernel without an initrd with udev?

Yes, I am. I am also running a custom kernel without an initrd and
without udev (which was one purpose of the custom kernel, no dependency
on udev).

> Yes, I am. Although I believe there are some circumstances where this
> may not be possible. eg. where something else needs to be started in
> order to mount the root filesystem first.

Such circumstances include :
- root is on a software RAID (md) volume with 1.x meta-data
- root is on an LVM volume
- root is on an encrypted volume
- root is specified by the bootloader as a LABEL or UUID

>> Any tips, pointers will be appreciated.
>
> Make sure that *all* filesystem and device drivers for your root
> partition are compiled directly into the kernel - not as modules.

Also make sure that the root= option passed by the bootloader to the
kernel command line specifies the root as a device name /dev/sdXY and
not as a LABEL or UUID which the kernel does not understand.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FF7FE6A.6070803@plouf.fr.eu.org">http://lists.debian.org/4FF7FE6A.6070803@plouf.fr.eu.org

custom kernel without initrd and with udev
 

Hi Dom,


Thanks for your suggestions and letting me know this is still possible.

On Sat, Jul 07, 2012 at 04:56:10AM +0100, Dom wrote:
> On 07/07/12 00:08, Mike McClain wrote:
<snip>
> > Is anyone running a custom kernel without an initrd with udev?
>
> Yes, I am. Although I believe there are some circumstances where
> this may not be possible. eg. where something else needs to be
> started in order to mount the root filesystem first.

How do you get around the fact that udev is not running yet?
May I see what your entry in grub.cfg looks like for this kernel?

> Some of my older machines (kept running for sentimental reasons)
> need an old ATA/IDE driver that the current Debian kernels do not
> include.

I ran into a similar situation with a video card that xorg didn't support
and kept using woody drivers up through etch until that box died.

> >Any tips, pointers will be appreciated.
>
> Make sure that *all* filesystem and device drivers for your root
> partition are compiled directly into the kernel - not as modules.
>
> Look at what modules are used from your initrd and compile those
> into your kernel
>
> In fact, if you are building a kernel specifically for one box (or a
> set of similar boxen), it is a good idea to have all/most hardware
> drivers built-in. I only have external peripherals (USB/cardbus
> devices) built as modules.

Good points and that's what I'm trying to do.

Thanks again,
Mike
--
Satisfied user of Linux since 1997.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120707154636.GA29370@playground

custom kernel without initrd and with udev
 

On Fri, 06 Jul 2012 19:08:14 -0400 (EDT), Mike McClain wrote:
>
> While surely no expert I've been building my own kernels for
> a long time with little trouble but with a recent install of
> 'Squeeze' I'm stumped. I've built, reconfigured, built again for
> several days now. No joy. I've spent hours Googling for any and
> everybody's thoughts on the error: 'Kernel panic - not syncing:
> VFS: Unable to mount root fs on unknown-block(0,0)' with little luck.
>
> Some one did suggest I decompile the initrd that shipped with
> the install. On doing that I discovered that the device files for
> the harddrive are created before the drive is mounted. Booting an
> 'Etch' partition I see that Squeeze's /dev/ is all but empty when
> Squeeze is not running which may have something to do with the
> failure to mount the root partition.
>
> Is anyone running a custom kernel without an initrd with udev?
> Any tips, pointers will be appreciated.

It's getting harder and harder to get along without an initrd these
days. Why is it so important to you not to use one? As others
have pointed out, using a UUID or LABEL specification for the root
file system makes it impossible to get the root file system mounted
if you don't use an initrd. And with modern Linux kernels, I don't
recommend using a traditional device specification, such as /dev/sda1,
because the assignment of kernel minor device numbers and user space
device names no longer can be counted on to occur in any particular
order. It may vary from one boot to the next. My advice is to
"bite the bullet" and convert, permanently, to using an initrd.

By the way, you may find my kernel-building web page useful:

http://users.wowway.com/~zlinuxman/Kernel.htm

--
.'`. Stephen Powell
: :' :
`. `'`
`-


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 528777112.144205.1341676438114.JavaMail.root@md01. wow.synacor.com">http://lists.debian.org/528777112.144205.1341676438114.JavaMail.root@md01. wow.synacor.com

custom kernel without initrd and with udev
 

Hi Pascal,
Thanks for your input.

On Sat, Jul 07, 2012 at 11:16:26AM +0200, Pascal Hambourg wrote:
> Hello,
>
> Dom a ?crit :
> > On 07/07/12 00:08, Mike McClain wrote:
> >>
> >> While surely no expert I've been building my own kernels for
> >> a long time with little trouble but with a recent install of
> >> 'Squeeze' I'm stumped. I've built, reconfigured, built again for
> >> several days now. No joy. I've spent hours Googling for any and
> >> everybody's thoughts on the error: 'Kernel panic - not syncing:
> >> VFS: Unable to mount root fs on unknown-block(0,0)' with little luck.
>
> What are the lines preceding the error ?

VFS: Cannot open root device "sdb5" or unknown-block(0,0)
Please append correct "root=" boot option; here are available partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Note that there are no 'available partitions' listed though before I reach this
point the grub commandline will show that all partitions on both drives are
recognized by grub.

>
> >> Is anyone running a custom kernel without an initrd with udev?
>
> Yes, I am. I am also running a custom kernel without an initrd and
> without udev (which was one purpose of the custom kernel, no dependency
> on udev).

So you are running two systems one with udev and one without?
If so, on the one without did you populate /dev by hand?
On the one with udev what does your grub.cfg entry look like?

>
> > Yes, I am. Although I believe there are some circumstances where this
> > may not be possible. eg. where something else needs to be started in
> > order to mount the root filesystem first.
>
> Such circumstances include :
> - root is on a software RAID (md) volume with 1.x meta-data
> - root is on an LVM volume
> - root is on an encrypted volume

The above don't apply but this next one got me.

> - root is specified by the bootloader as a LABEL or UUID
>
> >> Any tips, pointers will be appreciated.
> >
> > Make sure that *all* filesystem and device drivers for your root
> > partition are compiled directly into the kernel - not as modules.
>
> Also make sure that the root= option passed by the bootloader to the
> kernel command line specifies the root as a device name /dev/sdXY and
> not as a LABEL or UUID which the kernel does not understand.

Thanks again for your input,
Mike
--
Satisfied user of Linux since 1997.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120707161114.GB29370@playground

custom kernel without initrd and with udev
 

On 07/07/12 16:53, Stephen Powell wrote:

On Fri, 06 Jul 2012 19:08:14 -0400 (EDT), Mike McClain wrote:


Is anyone running a custom kernel without an initrd with udev?
Any tips, pointers will be appreciated.


It's getting harder and harder to get along without an initrd these
days. Why is it so important to you not to use one? As others
have pointed out, using a UUID or LABEL specification for the root
file system makes it impossible to get the root file system mounted
if you don't use an initrd.


I didn't know that.

It seems my kernel doesn't either, because it is working just fine with
UUIDs and no initrd ;-)


I agree there are issues with labels though, which is a pity.

--
Dom


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4FF86987.2010806@rpdom.net">http://lists.debian.org/4FF86987.2010806@rpdom.net

custom kernel without initrd and with udev
 

Hi Stephen,
On Sat, Jul 07, 2012 at 11:53:58AM -0400, Stephen Powell wrote:
<snip>
> http://users.wowway.com/~zlinuxman/Kernel.htm
Thanks, I'll take a look at that.
Mike
--
Satisfied user of Linux since 1997.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120707173437.GA29715@playground

custom kernel without initrd and with udev
 

On Sat, 07 Jul 2012 12:53:27 -0400 (EDT), Dom wrote:
> On 07/07/12 16:53, Stephen Powell wrote:
>> It's getting harder and harder to get along without an initrd these
>> days. Why is it so important to you not to use one? As others
>> have pointed out, using a UUID or LABEL specification for the root
>> file system makes it impossible to get the root file system mounted
>> if you don't use an initrd.
>
> I didn't know that.
>
> It seems my kernel doesn't either, because it is working just fine with
> UUIDs and no initrd ;-)
>
> I agree there are issues with labels though, which is a pity.

In a typical Debian boot, a root file system of some sort is mounted
three times: the first is the mount of the initial RAM file system,
specified by the boot loader. (In LILO, it is the "initrd" configuration
file statement.) The second is the mount of the permanent root file
system read-only, also specified by the boot loader. (In LILO, it is the
"root" configuration file statement.) The third is the mount of the
permanent root file system read/write, as specified in /etc/fstab.
Obviously, if you're not using an initial RAM file system, there are only
two mounts of the root file system. The one I'm talking about is the
first read-only one specified by the boot loader. I don't see how a
UUID specification is going to work there if there is no initial RAM file
system.

It may be possible to build modules into the kernel, so that an initial
RAM file system is not needed to load kernel modules from. But a user-
space process, such as udev, cannot be started until there is some kind
of root file system to read it from. One can't build a user-space process
into the kernel! I can believe that a UUID specification in /etc/fstab
would work, but I can't see how a UUID specification in the boot loader
would work. It is my understanding that udev is responsible for reading
the UUIDs and LABELs and creating the corresponding block special files
in /dev and symbolic links to them in /dev/disk. If there is no initrd,
how can udev be started? I don't see how this can work. Are you sure
that a UUID specification is being used in the boot loader, as well as
in /etc/fstab?

--
.'`. Stephen Powell
: :' :
`. `'`
`-


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 113719236.146733.1341683396826.JavaMail.root@md01. wow.synacor.com">http://lists.debian.org/113719236.146733.1341683396826.JavaMail.root@md01. wow.synacor.com

custom kernel without initrd and with udev
 

On 07/07/12 18:49, Stephen Powell wrote:

On Sat, 07 Jul 2012 12:53:27 -0400 (EDT), Dom wrote:

On 07/07/12 16:53, Stephen Powell wrote:

It's getting harder and harder to get along without an initrd these
days. Why is it so important to you not to use one? As others
have pointed out, using a UUID or LABEL specification for the root
file system makes it impossible to get the root file system mounted
if you don't use an initrd.


I didn't know that.

It seems my kernel doesn't either, because it is working just fine with
UUIDs and no initrd ;-)

I agree there are issues with labels though, which is a pity.


It may be possible to build modules into the kernel, so that an initial
RAM file system is not needed to load kernel modules from. But a user-
space process, such as udev, cannot be started until there is some kind
of root file system to read it from. One can't build a user-space process
into the kernel! I can believe that a UUID specification in /etc/fstab
would work, but I can't see how a UUID specification in the boot loader
would work. It is my understanding that udev is responsible for reading
the UUIDs and LABELs and creating the corresponding block special files
in /dev and symbolic links to them in /dev/disk. If there is no initrd,
how can udev be started? I don't see how this can work. Are you sure
that a UUID specification is being used in the boot loader, as well as
in /etc/fstab?


Ah, I see that my grub.cfg (grub2) is using root=/dev/hda1 for the
"linux" entry, despite GRUB_DISABLE_LINUX_UUID=true being commented out
in /etc/default/grub on that box. I'm not sure why.


The "search" entry has "--set=root bad6c13d-19f0-47ad-bc6e-542a911d4178"
in it, which is the UUID of the root partition.


I wonder why, as I'm sure I didn't edit it manually. Maybe the grub
setup is smart enough to realise?


I just ran update-grub to check and it produced the same entries.

--
Dom


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4FF88EDB.3010507@rpdom.net">http://lists.debian.org/4FF88EDB.3010507@rpdom.net