Problem with booting newly compiled kernel

Problem with booting newly compiled kernel

[Prasad Joshi]

Hello,

I seem to be always getting stuck in the new kernel booting. The
problem is with mounting of the root file system. I don't have the log
of the messages but, I guess, these were the messages reported

VFS: Cannot open root device ............
Please append a correct "root=" boot option; here are the available partitions:
Device: sda driver: sd
....... list of all partitions on sda, including correct size, offset
of each parition  .......
Device sdb driver: sr

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Backtrace:

It reported the correct list of sda partitions, including the driver
name as sd. I have a SATA disk and the root partition has ext4 file
system. The ext2/3/4 code is compiled as a part of the kernel.

$ df -kh /
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             459G   13G  423G   3% /


As far as I can understand, as it is showing the correct list of
partitions, the problem is not with the block device driver. But I am
not sure, why it is failing to mount the file system when ext4 is also
part of the kernel.


grub.cfg file.

menuentry 'Ubuntu, with Linux 2.6.37-rc6+' --class ubuntu --class
gnu-linux --class gnu --class os {
        recordfail
        insmod part_msdos
        insmod ext2
        set root='(hd0,msdos5)'
        search --no-floppy --fs-uuid --set ab9dfe8f-8e58-43ca-b16f-a42e0f02da72
        linux   /vmlinuz-2.6.37-rc6+
root=UUID=01432597-18e7-4609-9f85-3fad1d762ddc ro iommu=1
        initrd  /initrd.img-2.6.37-rc6+
}

menuentry 'Ubuntu, with Linux 2.6.35-22-generic' --class ubuntu
--class gnu-linux --class gnu --class os {
        recordfail
        insmod part_msdos
        insmod ext2
        set root='(hd0,msdos5)'
        search --no-floppy --fs-uuid --set ab9dfe8f-8e58-43ca-b16f-a42e0f02da72
        linux   /vmlinuz-2.6.35-22-generic
root=UUID=01432597-18e7-4609-9f85-3fad1d762ddc ro  iommu=1 quiet
splash
        initrd  /initrd.img-2.6.35-22-generic
}

The kernel 2.6.35-22-generic boots correctly.

Thanks and Regards,
Prasad

Problem with booting newly compiled kernel

[Alexandre Courbot]

> ? ? ? ?linux ? /vmlinuz-2.6.37-rc6+
> root=UUID=01432597-18e7-4609-9f85-3fad1d762ddc ro iommu=1

Try replacing root=UUID=01432597-18e7-4609-9f85-3fad1d762ddc by the
simpler root=/dev/sdaX. I had similar problems some time ago - for
some reason, my kernel did not like UUIDs.

Alex.

Problem with booting newly compiled kernel

[Prasad Joshi]

On Tue, Dec 21, 2010 at 1:37 AM, Alexandre Courbot <gnurou@gmail.com> wrote:
>> ? ? ? ?linux ? /vmlinuz-2.6.37-rc6+
>> root=UUID=01432597-18e7-4609-9f85-3fad1d762ddc ro iommu=1
>
> Try replacing root=UUID=01432597-18e7-4609-9f85-3fad1d762ddc by the
> simpler root=/dev/sdaX. I had similar problems some time ago - for
> some reason, my kernel did not like UUIDs.

bravo Alexandre :)
It solved the problem. I am really thankful to you.

>
> Alex.
>

Problem with booting newly compiled kernel

[Shreyansh Jain]

Hi List,

On Tue, Dec 21, 2010 at 7:22 PM, Prasad Joshi <prasadjoshi124@gmail.com> wrote:
> On Tue, Dec 21, 2010 at 1:37 AM, Alexandre Courbot <gnurou@gmail.com> wrote:
>>> ? ? ? ?linux ? /vmlinuz-2.6.37-rc6+
>>> root=UUID=01432597-18e7-4609-9f85-3fad1d762ddc ro iommu=1
>>
>> Try replacing root=UUID=01432597-18e7-4609-9f85-3fad1d762ddc by the
>> simpler root=/dev/sdaX. I had similar problems some time ago - for
>> some reason, my kernel did not like UUIDs.
>
> bravo Alexandre :)
> It solved the problem. I am really thankful to you.
>

Sorry to hijack your thread, but I thought this is the most opportune
time to ask my query.

@Prasad Nice to know that this suggestion solved the issue. I too have
found this issue very irritating but could never understand by UUID
were not recognized (where as my distro kernel recognizes them very
well).

a. Does any have any idea which component causes this issue. As to,
what am I missing while compiling a new kernel that it doesn't
recognize the UUID of a dev disk?

b. Also, who generates these UUID - is it a disk property (like, ROM
signature or stuff?), or this is some udev magic?

Thanks to anyone who can provide any hint about this.

-
Shreyansh

Problem with booting newly compiled kernel

[Prasad Joshi]

On Tue, Dec 21, 2010 at 6:16 PM, Shreyansh Jain <shrey.linux@gmail.com> wrote:
> Hi List,
>
> On Tue, Dec 21, 2010 at 7:22 PM, Prasad Joshi <prasadjoshi124@gmail.com> wrote:
>> On Tue, Dec 21, 2010 at 1:37 AM, Alexandre Courbot <gnurou@gmail.com> wrote:
>>>> ? ? ? ?linux ? /vmlinuz-2.6.37-rc6+
>>>> root=UUID=01432597-18e7-4609-9f85-3fad1d762ddc ro iommu=1
>>>
>>> Try replacing root=UUID=01432597-18e7-4609-9f85-3fad1d762ddc by the
>>> simpler root=/dev/sdaX. I had similar problems some time ago - for
>>> some reason, my kernel did not like UUIDs.
>>
>> bravo Alexandre :)
>> It solved the problem. I am really thankful to you.
>>
>
> Sorry to hijack your thread, but I thought this is the most opportune
> time to ask my query.
>
> @Prasad Nice to know that this suggestion solved the issue. I too have
> found this issue very irritating but could never understand by UUID
> were not recognized (where as my distro kernel recognizes them very
> well).

The default kernel with Ubuntu 10.10 too recognized the UUID.

>
> a. Does any have any idea which component causes this issue. As to,
> what am I missing while compiling a new kernel that it doesn't
> recognize the UUID of a dev disk?

The function responsible for mounting the root file system is
prepare_namespace()

void __init prepare_namespace(void)
{

    if (saved_root_name[0]) {
        root_device_name = saved_root_name;
        if (!strncmp(root_device_name, "mtd", 3) ||
            !strncmp(root_device_name, "ubi", 3)) {
            mount_block_root(root_device_name, root_mountflags);
            goto out;
        }
        ROOT_DEV = name_to_dev_t(root_device_name);
        if (strncmp(root_device_name, "/dev/", 5) == 0)
            root_device_name += 5;
    }

...
    mount_root();
}

The function name_to_dev_t is responsible for finding out the correct
major and minor numbers for the root device. The function also works
on UUID. IMHO, the function is responsible for doing it is
devt_from_partuuid, though I did not look into the details.

>
> b. Also, who generates these UUID - is it a disk property (like, ROM
> signature or stuff?), or this is some udev magic?
>

IMHO, this is fixed for every device during manufacturing.

> Thanks to anyone who can provide any hint about this.
>
> -
> Shreyansh
>

Problem with booting newly compiled kernel

[John Mahoney]

>> b. Also, who generates these UUID - is it a disk property (like, ROM
>> signature or stuff?), or this is some udev magic?
>>
>
> IMHO, this is fixed for every device during manufacturing.
>

I believe the UUID is created per partition/file system and are
created when creating the file system for a partition.  If anyone even
had their drive changed from /dev/hda to /dev/sda due to linux
changing how they labeled ide drives they will know why people use
UUID instead of the device name .  Also, it is not guaranteed that
they drives will always come up in the same order between kernel
releases(This is my personal opinion).

--
John

Problem with booting newly compiled kernel

[Prasad Joshi]

On Tue, Dec 21, 2010 at 8:43 PM, John Mahoney <jmahoney@waav.com> wrote:
>>> b. Also, who generates these UUID - is it a disk property (like, ROM
>>> signature or stuff?), or this is some udev magic?
>>>
>>
>> IMHO, this is fixed for every device during manufacturing.
>>
>
> I believe the UUID is created per partition/file system and are
> created when creating the file system for a partition. ?If anyone even
> had their drive changed from /dev/hda to /dev/sda due to linux
> changing how they labeled ide drives they will know why people use
> UUID instead of the device name . ?Also, it is not guaranteed that
> they drives will always come up in the same order between kernel
> releases(This is my personal opinion).
>

I think you are correct, it is assigned when a file system is created.
It is a tunable parameter which can be chnaged using tune2fs -U
command.
A new UUID can be generated using command uuidgen.

> --
> John
>

Problem with booting newly compiled kernel

[Shreyansh Jain]

Hi,

On Wed, Dec 22, 2010 at 2:58 AM, Prasad Joshi <prasadjoshi124@gmail.com> wrote:
> On Tue, Dec 21, 2010 at 8:43 PM, John Mahoney <jmahoney@waav.com> wrote:
>>>> b. Also, who generates these UUID - is it a disk property (like, ROM
>>>> signature or stuff?), or this is some udev magic?
>>>>
>>>
>>> IMHO, this is fixed for every device during manufacturing.
>>>
>>
>> I believe the UUID is created per partition/file system and are
>> created when creating the file system for a partition. ?If anyone even
>> had their drive changed from /dev/hda to /dev/sda due to linux
>> changing how they labeled ide drives they will know why people use
>> UUID instead of the device name . ?Also, it is not guaranteed that
>> they drives will always come up in the same order between kernel
>> releases(This is my personal opinion).
>>
>
> I think you are correct, it is assigned when a file system is created.
> It is a tunable parameter which can be chnaged using tune2fs -U
> command.
> A new UUID can be generated using command uuidgen.

Would that mean that there has to be a table stored somewhere which
provides this kind of mapping? In that case, as this table is required
at the boot time, even before the bootable harddisk is detected which
could have stored such a table persitently, is this table written
somewhere in the initramfs?

>
>> --
>> John
>>
>

-
Shreyansh

Problem with booting newly compiled kernel

[Mandeep Sandhu]

>>> I believe the UUID is created per partition/file system and are
>>> created when creating the file system for a partition. ?If anyone even
>>> had their drive changed from /dev/hda to /dev/sda due to linux
>>> changing how they labeled ide drives they will know why people use
>>> UUID instead of the device name . ?Also, it is not guaranteed that
>>> they drives will always come up in the same order between kernel
>>> releases(This is my personal opinion).
>>>
>>
>> I think you are correct, it is assigned when a file system is created.
>> It is a tunable parameter which can be chnaged using tune2fs -U
>> command.
>> A new UUID can be generated using command uuidgen.
>
> Would that mean that there has to be a table stored somewhere which
> provides this kind of mapping? In that case, as this table is required
> at the boot time, even before the bootable harddisk is detected which
> could have stored such a table persitently, is this table written
> somewhere in the initramfs?

I think UDEV manages persistent naming of devices for you. The
mappings that you talk of are managed as udev rules. Reading more on
udev might give you a better idea. I don't know the exact details so
I'll point you to link I've planning to read for some time! :)
http://reactivated.net/writing_udev_rules.html

CMIIW.

Regards,
-mandeep


>
>>
>>> --
>>> John
>>>
>>
>
> -
> Shreyansh
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>