SO I have this wireless card from EnGenius. It is supposed to be supported by ath5k from the madwifi project. It did not work. I did some searching on the net and found a post that said the drive in 2.6.27 had been updated to fix this problem. Fine I downloaded the source and did a make oldconfig from the existing config file for the default kernel that in in /boot. I did change one thing I used a high definition timer and made it premptable. I wrote a new entry in menulist to boot my newly compiled kernel.
During the boot process the kernel can’t find the drive as it is listed in fstab, /dev/drive/by-id/XXX. Whats the deal? It’s looking for the old, or at least ordering that I am used to, of /dev/hda. If the changes to the reordering of the drives was at the kernel level how come the latest kernel doesn’t know anything about them?
Any ideas?
P.S.
If I come across as being to harsh it’s nothing personal. It’s just my personality after having gone through a lot of stuff in my life that made me fairly hard and rough around the edges. So if I offend you I will apologize in advance.
I can not solve your problem as I do not understand fully what is wrong, but I can try to give some information in some aspects you mention. This may help in further understanding about what is wrong.
When you say that the kernel does not see your drive but it is in your fstab that may be a misunderstanding. Your fstab is only used after your kernel is running and after it has found out about hardware connected.
The use of drive-by-id notation instead of the old hda is nothing to worry about. If you look in /dev/disk/id-… you will see that these are all links to to good old /dev/hda (or /dev/sda). You can use either of these by-… names in mounting or fstab so the correct disk is mounted regardless where it is hardwarewise today. Which maybe very usefull in an environment where people (dis)connect disks very often.
No harshness noted! So wouldn’t worry about that!
Maybe shouting * GROUP HUG! * every now and then might help… but that’s a whole different story…
As Hcw already mentioned, it’s not too clear as what the issue is you’re running into?
Are you running openSUSE 11.1? Or have you applied some 2.6.27 kernel to a running 11.0 setup?
As I’ve seen mentioned in the factory mailing lists, some extra drivers have been ported into the 2.6.27 version - but you’ll need the latest revision that includes them. I don’t have a list of which exact drivers are in there…
You could try dropping a mail in the factory mailing list for that info.
The drive-by-ID you mention… is that your wireless device?? Why would it be seen as storage? Or do you mean your disk is not being recognised correctly when booting with the new kernel?
dragondaddy wrote:
> During the boot process the kernel can’t find the drive as it is listed
> in fstab, /dev/drive/by-id/XXX. Whats the deal? It’s looking for the
> old, or at least ordering that I am used to, of /dev/hda. If the
> changes to the reordering of the drives was at the kernel level how come
> the latest kernel doesn’t know anything about them?
It seems as if you manually added the kernel to /boot and did your own edit of
the GRUB menu. That is not necessary. After you do the “make” of the kernel, you
should follow that with “sudo make modules_install install”, which does
everything you need. In particular, it makes the initial ram disk image that is
called initrd.
The reason you need the “sudo” in the installation line is because you should
never build the new kernel as root.
If you did, in fact, do the installation correctly, then you are missing some
disk modules. Issue the command “make xconfig” and click on “ATA/ATAPI…” under
“Device Drivers”. Select everything except “Support for SATA”. Next click on
“Serial ATA …” and select everything there.
The later kernels now put most disk drives under /dev/sda, not /dev/hda, and
that is where you will find your drives.
In this particular area, there are others here whom I can barely stand in the shadow of. I defer . . .
I read the question to mean that the kernel fails to find the root partition to mount, or it is the mount itself that fails. Which would mean that grub initially found the kernel to call.
My take would be the same as Larry’s. The kernel will need libata and scsi compiled in, matching the kernel version. And of course a rebuilt matching initrd with the necessary controller modules (check /etc/sysconfig/kernel).
So I did a few other things. In the beginning I didn’t use an initial ram disk, initrd, because everything needed to access the root partition was in the kernel. But I did read the man page for mkinitrd and found this:
“While in the old days the Linux kernel was responsible for mounting the rootfilesystem and running /sbin/init, all the work is now done by the “/init” script.”
So I thought I would just go ahead and make a ram disk. I made one from the command line and put it in my entry in menu.lst. Now I get a different error. The system runs up until it tries to find /dev/disk/by0id/scsi-SATA-IC35L090AVV207-_VNVC06G3GYHJLL-part1. It waits for awhile and tells me that this doesn’t show up. The system asks if it should wait some more (Y/n). SO I say no. This drops me to a command line of the initial filesystem created by initrd. I do an ls -l of /dev/disk/by-id and notice that there is no scsi-SATA-IC35L090AVV207-_VNVC06G3GYHJLL-part1 but there is one that is ata-SATA-IC35L090AVV207-_VNVC06G3GYHJLL-part1 and it is a link to hda1. Just like I have been using forever.
When I set this up I didn’t run make install. I’m not all that trusting of scripts that can F-up my menu.lst. But I haven’t been getting very far so I backed up my menu.lst and ran make install. It did exactly what I did by hand except it named things a little differently, no big deal. I booted the entry created by make install and got exactly what I had when I booted the entry I made. The kernel is not converting the IDE drives, hda, to scsi drives, sda.
Now I can solve this by just changing fstab. But that would break the other kernels in menu.lst.
It would be very cool if I could have two different fstabs, named fstab1 and fstab2. Then during boot I could copy the one I need for the kernel that is loading to just fstab. But this would have to be done inside grub. There is a way to embed a script inside grub for things such as this but it means I would have to recompile with the proper switch and then reinstall grub.
Well at this point it’s getting clear that I am moving far away from the initial task of getting my high output wireless card driver working, way to many hoops to jump through. So I think I will give ndiswrapper a try before I go into recompiling grub.
But I think it is clear that the kernel does not change ide drives to scsi drives. That is being done somewhere inside suse not in the kernel.
But I think it is clear that the kernel does not change ide drives to scsi drives. That is being done somewhere inside suse not in the kernel.
Wrong again. IIRC being done in libata. The change was in ~2.6.2 kernel and impacted other communities, too. The Ubuntu forums are full of questions about this as it took users there by surprise, just as it did openSUSE users.
