Problem with booting newly compiled kernel
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
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.
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.
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
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
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
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
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
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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
participants (5)
-
Alexandre Courbot -
John Mahoney -
Mandeep Sandhu -
Prasad Joshi -
Shreyansh Jain