| View previous topic :: View next topic |
| Author |
Message |
GBob
Tux's lil' helper
Joined: 13 Nov 2004
Posts: 110
Location: Portland, Oregon
|
 Posted: Sat Feb 27, 2010 8:00 pm Post subject: Issue with ramfs During Boot |
 |
|
So I was getting /dev/hda3 is not a valid root device during boot. I went into the shell and started poking around, since I know the /dev/hda3 is actually valid.
It turns out /dev in the ramdisk is unpopulated. I used mknod to make /dev/hda3, but I know that something is screwed up in my kernel. Any pointers?
_________________
rank[0]-=('n'-'d');
rank[3]-=('b'-'d');
It is better to say nothing and have people think your are an idiot,
Than open your mouth and remove all doubt. |
|
| Back to top |
|
 |
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23076
|
| Posted: Sat Feb 27, 2010 10:12 pm Post subject: |
|
|
| Most likely, /dev/hda3 is not the device node you want, and it became invalid because you switched to the newer libata drivers. These drivers are preferred over the older IDE drivers. The libata drivers create sdX, rather than hdX, nodes. |
|
| Back to top |
|
|
GBob
Tux's lil' helper
Joined: 13 Nov 2004
Posts: 110
Location: Portland, Oregon
|
| Posted: Sat Feb 27, 2010 10:27 pm Post subject: |
|
|
| Hu wrote: | | Most likely, /dev/hda3 is not the device node you want, and it became invalid because you switched to the newer libata drivers. These drivers are preferred over the older IDE drivers. The libata drivers create sdX, rather than hdX, nodes. |
Actually, it is what I want. It is what I have used for the last 5+ years, and switching all scripts and then re training my brain is more effort than the updated drivers are worth.
Was there something wrong with continuing to use the old lettering scheme? How would it have hurt things to keep using them? And if my IDE drives suddenly become part of the sd scheme, won't that mess up my fstab since I have sata and pata drives?
Regardless, the point is moot, as the initfs (or ramfs) doesn't list any drives including sdX drives. It lists console tty and a few other things. None of my drives show up. I mean I have 4 sata drives, 1 IDE and 1 cdrom, the dev directory just isn't populated with my hardware. If I had to guess, it is because most of the time udev populates those entries, but it is not part of the ramfs.
_________________
rank[0]-=('n'-'d');
rank[3]-=('b'-'d');
It is better to say nothing and have people think your are an idiot,
Than open your mouth and remove all doubt. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23076
|
| Posted: Sun Feb 28, 2010 12:51 am Post subject: |
|
|
| GBob wrote: | | Hu wrote: | | Most likely, /dev/hda3 is not the device node you want, and it became invalid because you switched to the newer libata drivers. These drivers are preferred over the older IDE drivers. The libata drivers create sdX, rather than hdX, nodes. |
Actually, it is what I want. It is what I have used for the last 5+ years, and switching all scripts and then re training my brain is more effort than the updated drivers are worth. |
Do not be so sure that the newer drivers are not worthwhile. I had a laptop that was barely usable due to I/O latency with the old IDE drivers, but it was quite pleasant with the newer libata drivers. How many scripts do you have that updating them is a big deal?
| GBob wrote: | | Was there something wrong with continuing to use the old lettering scheme? How would it have hurt things to keep using them? And if my IDE drives suddenly become part of the sd scheme, won't that mess up my fstab since I have sata and pata drives? |
No, there was nothing inherently wrong with the old scheme. It does not directly hurt to use the old names, but the renaming is a side effect of routing through a completely different code path that has a different set of rules. Yes, it will require an fstab change when you switch to the libata drivers.
| GBob wrote: | | Regardless, the point is moot, as the initfs (or ramfs) doesn't list any drives including sdX drives. It lists console tty and a few other things. None of my drives show up. I mean I have 4 sata drives, 1 IDE and 1 cdrom, the dev directory just isn't populated with my hardware. If I had to guess, it is because most of the time udev populates those entries, but it is not part of the ramfs. |
That sounds reasonable. Unless you took specific action to populate the initramfs with a dynamic device manager, its /dev will have only the static nodes you manually created.
The path forward depends on whether you need an initramfs. If you do not need one, then just remove it, fix your root= line to specify the root device, and things should work. If you do need an initramfs, you will need to populate /dev in it. You can do this either via a dynamic device manager or via your own init script inside the initramfs. You may be able to statically populate the initramfs at creation time, if your needs are simple enough. |
|
| Back to top |
|
|
GBob
Tux's lil' helper
Joined: 13 Nov 2004
Posts: 110
Location: Portland, Oregon
|
| Posted: Sun Feb 28, 2010 6:59 pm Post subject: |
|
|
| Hu wrote: | | GBob wrote: | | Regardless, the point is moot, as the initfs (or ramfs) doesn't list any drives including sdX drives. It lists console tty and a few other things. None of my drives show up. I mean I have 4 sata drives, 1 IDE and 1 cdrom, the dev directory just isn't populated with my hardware. If I had to guess, it is because most of the time udev populates those entries, but it is not part of the ramfs. |
That sounds reasonable. Unless you took specific action to populate the initramfs with a dynamic device manager, its /dev will have only the static nodes you manually created.
The path forward depends on whether you need an initramfs. If you do not need one, then just remove it, fix your root= line to specify the root device, and things should work. If you do need an initramfs, you will need to populate /dev in it. You can do this either via a dynamic device manager or via your own init script inside the initramfs. You may be able to statically populate the initramfs at creation time, if your needs are simple enough. |
Wow. A cogent, coherent response. Thank you.  So if I understand what you're saying (and since you went from basic level to to kernel maintainer level in 1 post I may not understand perfectly) that modifying the root parameter in grub and removing the initramfs line should take care of my problem? I tried the first step but not in conjunction with the second step and the results were less than stellar.
| Hu wrote: | | GBob wrote: | | Hu wrote: | | Most likely, /dev/hda3 is not the device node you want, and it became invalid because you switched to the newer libata drivers. These drivers are preferred over the older IDE drivers. The libata drivers create sdX, rather than hdX, nodes. |
Actually, it is what I want. It is what I have used for the last 5+ years, and switching all scripts and then re training my brain is more effort than the updated drivers are worth. |
Do not be so sure that the newer drivers are not worthwhile. I had a laptop that was barely usable due to I/O latency with the old IDE drivers, but it was quite pleasant with the newer libata drivers. How many scripts do you have that updating them is a big deal? |
Ah, I don't have latency issues, and things have been humming a long nicely for a very long time. Additionally almost all my drive usage is via the sata drives, the pata is just my boot drive any more (with the exception of the DVD drive).
I've had more than my share of issues with getting the DVD drive stable and able to read a whole DVD. (For example packet writing caused issues where only the first layer of a dual layer DVD was readable.) And now that I've finally got them worked out, a new driver seems like a new set of headaches.
That said, you asked how many scripts, the answer is I don't know. And while I probably could find them all, it seems like a better way would be to symlink back so that if I missed anything I'd still be okay. What really would be the ideal solution, would be if you could actually define what dev device should show up on a per device basis.
| Hu wrote: | | GBob wrote: | | Was there something wrong with continuing to use the old lettering scheme? How would it have hurt things to keep using them? And if my IDE drives suddenly become part of the sd scheme, won't that mess up my fstab since I have sata and pata drives? |
No, there was nothing inherently wrong with the old scheme. It does not directly hurt to use the old names, but the renaming is a side effect of routing through a completely different code path that has a different set of rules. Yes, it will require an fstab change when you switch to the libata drivers. |
I'd like to thank you for explaining the piece of the drive lettering. This is a particular sore spot with me, as different versions of lirc, v4l, alsa, and other base level devices seem to change (location and name) without much thought. These changes put an undue burden on the user. I'm not oblivious to the pain of keeping backwards compatibility, I mean my day job is writing software and maintaining backwards compatibility is a big part of that; however, it really is essential to keeping a stable system.
For example, what really saved my rear during this last set of issues was being able to boot into previous kernels and then recompiling my current kernel. When block names for devices change, and the fstab changes, I lose my safety net. That is the biggest reason why I'd prefer to stay on the current system.
That said, while researching I saw devices by name. I don't know how far back that support goes, and there is the problem of having a recovery kernel with a feature (and making sure it works) before switching over to it in my boot kernel. Device by name looks like a good solution to a continuing problem of constant device name changes. Too bad it only appears to work for file systems.
_________________
rank[0]-=('n'-'d');
rank[3]-=('b'-'d');
It is better to say nothing and have people think your are an idiot,
Than open your mouth and remove all doubt. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23076
|
| Posted: Sun Feb 28, 2010 8:26 pm Post subject: |
|
|
| GBob wrote: | | Wow. A cogent, coherent response. Thank you. So if I understand what you're saying (and since you went from basic level to to kernel maintainer level in 1 post I may not understand perfectly) that modifying the root parameter in grub and removing the initramfs line should take care of my problem? I tried the first step but not in conjunction with the second step and the results were less than stellar. |
Yes, if you have compiled all required support into the kernel. If your rootfs needs a module in order to drive the relevant block device or to interpret the filesystem on that block device, then you will need the initramfs until you can rebuild your kernel to include those features. I do not know enough about your hardware, filesystems, and kernel configuration to be able to say whether you meet this requirement. The safest way to test this would be to add a new grub entry that behaves the way you summarized, and try booting it. If it works, then you can make it default and be done. If not, you can reboot back to the kernel+initramfs and try to fix the failure. If it fails, feel free to post back for assistance. We will need the output of sfdisk -l ; file -s /dev/[hs]d[a-d]{,?} ; nl /etc/fstab ; nl /boot/grub/grub.conf ; zgrep -E '^[^#].*_FS' /proc/config.gz ; zcat /proc/config.gz | sed -n -e '/CONFIG_IDE/,/FireWire/ { /^[^#]/p } '. Sorry for such a long command. What it does:
sfdisk: list partitions on available disks
file: examine magic numbers on available disks and partitions to show probable file types
nl: print some configuration files, with line numbers
zgrep: print non-comment _FS related lines from your config
sed: print non-comment lines occurring between the first and second expressions, which should approximately show your built-in hard disk drivers
| GBob wrote: | Ah, I don't have latency issues, and things have been humming a long nicely for a very long time. Additionally almost all my drive usage is via the sata drives, the pata is just my boot drive any more (with the exception of the DVD drive).
I've had more than my share of issues with getting the DVD drive stable and able to read a whole DVD. (For example packet writing caused issues where only the first layer of a dual layer DVD was readable.) And now that I've finally got them worked out, a new driver seems like a new set of headaches. |
Fair enough. The laptop I mentioned used the affected drive as its sole hard drive, so latency issues there were very unpleasant, and there were no fancy features to worry about breaking when I changed drivers.
| GBob wrote: | | And while I probably could find them all, it seems like a better way would be to symlink back so that if I missed anything I'd still be okay. What really would be the ideal solution, would be if you could actually define what dev device should show up on a per device basis. |
You can do this with udev rules. However, if the devices need to be named a particular way before udev has a chance to run and fix them, that gets more complicated.
| GBob wrote: | | I'd like to thank you for explaining the piece of the drive lettering. This is a particular sore spot with me, as different versions of lirc, v4l, alsa, and other base level devices seem to change (location and name) without much thought. These changes put an undue burden on the user. I'm not oblivious to the pain of keeping backwards compatibility, I mean my day job is writing software and maintaining backwards compatibility is a big part of that; however, it really is essential to keeping a stable system. |
Agreed. Fortunately, aside from your current troubles, most unwanted device renames can be countered with the right udev rule.
| GBob wrote: | | For example, what really saved my rear during this last set of issues was being able to boot into previous kernels and then recompiling my current kernel. When block names for devices change, and the fstab changes, I lose my safety net. That is the biggest reason why I'd prefer to stay on the current system. |
True, but things are not as bad as you think. With the right root=, you can probably come up to single user mode even if fstab is wrong. From there, you can mount other filesystems by hand to get a full filesystem, and do your recovery from there. It is certainly less convenient than the method you have followed to date, but it can be done.
If you are concerned about safety, I suggest getting a bootable CD, a netbootable image, or some other means of booting the hardware when the contents of the drive are completely broken. Consider how much trouble it could be to fix the system if glibc was damaged. No installed dynamically linked programs could be started. In a pinch, you could use init= to run a statically linked busybox, but that environment is very minimal, and may lack sufficient tools to perform complex recovery. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
