Kernel panics with «Cannot open root device» error, where do I append the «root=» option?
whenever I try to boot with linux kernel 3.0.0.13 (the one installed by the upgrades) I get a Kernel Panic error: VFS: Cannot open root device «sda1» or unknown block (0,0) Please append a correct «root mt24 mb12″>
Same problem here. The main difference I observe is that up to 3.0.0.12, the grub conf tries to identify the hard disk using its UUID, 3.0.0.13 now uses /dev/sda6 .. weird .
3 Answers 3
You haven’t provided much information with logs and such to proceed with but I am guessing most probably this error you’re facing is because the kernel is confused by a IDE/SATA drive. Doing a quick Google search led me to link 1, link 2, link 3
Most likely one of the most occurring issue (but once you solved it, you most likely are never going to see it again):
Unable to mount root fs on unknown-block(0,0)
VFS: Cannot open root device "sda3" or unknown-block(8,3) Please append a correct "root http://kmuto.jp/debian/hcl/">http://kmuto.jp/debian/hcl/. The site will show you which kernel drivers you need to select for your system. Within the menuconfig, you can type "/" to open the search function, and type in the driver name to find out where it resides. # lspci -n
Check if you have built in (and not as a module) support for the file system(s) you use.
Say your root file system uses btrfs (which I definitely don't recommend) but you didn't select it, or selected it to be built as a module, then you'll get the error you see. Make sure the file system support is built in the kernel.
Check if the kernel parameter for root= is pointing to the correct partition.
This isn't as stupid as it sounds. When you are booted with one kernel, it might list your disks as being /dev/sda whereas your (configured) kernel is expecting it to be /dev/hda. This is not because kernels are inconsistent with each other, but because of the drivers used: older drivers use the hda syntax, newer sda.
Try switching hda with sda (and hdb with sdb, and . ).
Also, recent kernels give an overview of the partitions they found on the device told. If it does, it might help you identify if you misselected a partition (in the example given at the beginning of this section, only two partitions are found whereas the kernel was instructed to boot the third). If it doesn't, it is most likely because the kernel doesn't know the device to begin with (so it can't attempt to display partitions).
Check if the kernel that is being boot by the boot loader is the correct kernel. I have seen people who, after building a first kernel (which doesn't boot), forget that they have to mount /boot before the overwrite the kernel with a new one. As a result, they copy the kernel to the root file system (/) whereas the boot loader still expects the kernel image to be on the /boot partition.
)" data-controller="se-share-sheet" data-se-share-sheet-title="Share a link to this answer" data-se-share-sheet-subtitle="" data-se-share-sheet-post-type="answer" data-se-share-sheet-social="facebook twitter " data-se-share-sheet-location="2" data-se-share-sheet-license-url="https%3a%2f%2fcreativecommons.org%2flicenses%2fby-sa%2f3.0%2f" data-se-share-sheet-license-name="CC BY-SA 3.0" data-s-popover-placement="bottom-start">Share
Hi, it passed a lot of time, but thanks. I had a faulty CD-Rom, removing that everything worked fine!
– lucacerone
Mar 13, 2012 at 17:36
Link 1, Link 4 and Link 5 are all dead now.
– Questionmark
Mar 4, 2019 at 17:04
Add a comment|
1
It's possible this error could be related to the initrd image being too large.
A solution to this can be accomplished by changing the compression method and removing debug symbols from object files:
# Strip unneeded symbols of object files $ cd /lib/modules/5.4.5-rt3 # or your new kernel $ sudo find . -name *.ko -exec strip --strip-unneeded <> + # Change the compression format $ sudo vi /etc/initramfs-tools/initramfs.conf # Modify COMPRESS=lz4 to COMPRESS=xz (line 53) COMPRESS=xz
I have a little problem. I install this module into my kernel and its written under /proc When I try to open() it from user mode I get the following message:
static int module_permission(struct inode *inode, int op, struct nameidata *foo) < //if its write if ((op == 2)&&(writer == DOESNT_EXIST))< writer = EXIST ; return 0; >//if its read if (op == 4 ) < numOfReaders++; return 0; >return -EACCES; > int procfs_open(struct inode *inode, struct file *file) < try_module_get(THIS_MODULE); return 0; >static struct file_operations File_Ops_4_Our_Proc_File = < .read = procfs_read, .write = procfs_write, .open = procfs_open, .release = procfs_close, >; static struct inode_operations Inode_Ops_4_Our_Proc_File = < .permission = module_permission, /* check for permissions */ >; int init_module() < /* create the /proc file */ Our_Proc_File = create_proc_entry(PROC_ENTRY_FILENAME, 0644, NULL); /* check if the /proc file was created successfuly */ if (Our_Proc_File == NULL)< printk(KERN_ALERT "Error: Could not initialize /proc/%s\n", PROC_ENTRY_FILENAME); return -ENOMEM; >Our_Proc_File->owner = THIS_MODULE; Our_Proc_File->proc_iops = &Inode_Ops_4_Our_Proc_File; Our_Proc_File->proc_fops = &File_Ops_4_Our_Proc_File; Our_Proc_File->mode = S_IFREG | S_IRUGO | S_IWUSR; Our_Proc_File->uid = 0; Our_Proc_File->gid = 0; Our_Proc_File->size = 80; //i added init the writewr status writer = DOESNT_EXIST; numOfReaders = 0 ; printk(KERN_INFO "/proc/%s created\n", PROC_ENTRY_FILENAME); return 0; >
lsusb - I get always Couldn't open device. Is this normal?
When I write lsusb -v I always get "Couldn't open device, some information will be missing" Is this normal to get for each bus? P.S: I was trying to read from a laser scanner which is connected via USB. But I was getting "couldn't open serial port". And I wanted to check the port with lsusb and I saw that it's written "Couldn't open device" on every one of these usb ports. Even for my mouse it says "Couldn't open" but it's working.
2 Answers 2
Yes it is. You are asking for hardware information so some information might need sudo. See the difference between the 2 .
rinzwind@schijfwereld:~$ lsusb -v | grep device Couldn't open device, some information will be missing Couldn't open device, some information will be missing Couldn't open device, some information will be missing Couldn't open device, some information will be missing
and when using sudo it disappears though you will get other notices:
rinzwind@schijfwereld:~$ sudo lsusb -v | grep device can't get debug descriptor: Resource temporarily unavailable Lowest fully-functional device speed is SuperSpeed (5Gbps) can't get debug descriptor: Resource temporarily unavailable Device Qualifier (for other device speed): can't get device qualifier: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable can't get device qualifier: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable
this may have helped the poster, but this is not always the answer to the question of "why am I getting 'could not open device - some information may be missing'. " - I run lsusb logged as root via systemd daemon (I can manually reproduce the problem by running sudo su root and later lsusb -vd
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize0 64 idVendor 0x1d6b Linux Foundation idProduct 0x0002 2.0 root hub bcdDevice 5.19 iManufacturer 3 Linux 5.19.0-46-generic ehci_hcd iProduct 2 EHCI Host Controller iSerial 1 0000:00:1d.0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0019 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12
You must log in to answer this question.
Related
Hot Network Questions
Subscribe to RSS
To subscribe to this RSS feed, copy and paste this URL into your RSS reader.
Ubuntu and the circle of friends logo are trade marks of Canonical Limited and are used under licence.
By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.
Kernel Panic: VFS cannot open root device or unknown block error -6
Note that this is Kubuntu (KDE Ubuntu) I've been having a problem for a while where if I turn on the computer, it just takes me to a black screen. It sticks there with no output and no hint of what's going on except that the Caps Lock indicator light on my keyboard flashes on and off (weird, right?) If I then turn off the computer (by holding down the power button for a few seconds), and turn it back on, I get a boot menu where I can choose 'Advanced options for Ubuntu', and that lists different versions, recovery modes, some of which work just fine. That's what I've bee doing for the two weeks or so I've had this problem, and it worked until just now. The alternative options only booted me into the command line. I was able to fix this with this solution, so now I'm typing this from my desktop. I'm reluctant to turn off the computer in case it happens again, and I'd like to just tear out the root of the problem. Screenshot of error:
Caps lock blinking is a sign of kernel panic -- fatal crash of the Linux that runs Ubuntu. Try opening /etc/default/grub with a text editor as root and change GRUB_CMDLINE_LINUX_DEFAULT="splash quiet" to GRUB_CMDLINE_LINUX_DEFAULT="nosplash debug --verbose" . That way you can see exactly what's causing the panic during boot. Then run in terminal sudo update-grub and shut it off. When you turn it back on you should see messages about everything the kernel is doing. See what errors you get just before the crash.
