Thanks for the info ethernut.
I'm thinking you and cecil are on the right track. It's probably the moment that KnoppMyth tries to mount the raid array that causes the hang. Although I'm not sure how it knows where and how to mount the raid array because I installed KnoppMyth without the raid array disks plugged in. Now, simply plugging in the sata drives and booting causes the Kernel panic. At the moment, I can only boot to the smaller ide drive with the power to the sata drives unplugged.

So the machine will boot from the ide drive with the raid card in the pci slot, but with the power to the sata drives unplugged. I think that means that the system can recognize the raid card and is using the proper module. Booting up with the sata drives' power unplugged and running "lspci", lists the 3ware card like this:

00:10.0 RAID bus controller: 3ware Inc 9xxx-series SATA-RAID

lsmod gives:

3w_9xxx 32644 0

I guess this means that the proper module is being loaded?
Thank you for clearing up cecil's directions. I'm going to poke around right now and see what I can do with them...

What that probably means is that when you plug in the RAID drives your bios boot order forces the RAID array to be first, thus it ignores the small drive and tries to boot off the array, thus you get what started this whole thread.

Try going into your bois and making the small drive higher up on the boot order than the RAID array and see if it'll boot from the small drive.. If it does, then see my previous post and let us know!

_________________
Knoppmyth 7.02 Kernel 2.6.39-LINHES
[MBE] SilverStone LC-10 HTPC Case, Asus M2NPV-VM, AMD X2 4200+, 1G RAM, Nvidia 9500 PCIe, PVR500 and a HD-PVR - Rockin VDPAU

Ethernut, you were exactly right! The scsi array was listed first in the boot sequence so I was actually trying to boot from the array whenever I plugged it in. Moving the ide drive higher in the sequence was the ticket. Yeesh, I should have realized that.

I was able to unmount /myth by switching to runlevel 1 (telinit 1) and then mount the array to /myth with "mount /dev/sda1 /myth". I had to first erase the partitions on the raid array that I had created during the previous KnoppMyth installs. (In fdisk, I deleted all the partitions and created a new partition of the whole free space, type 83. Then I used "mkfs.ext3 /dev/sda1" to create a filesystem on the array. That took a little while.

root@odaiko:/home/xuxa# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/hda1 4.7G 1.7G 2.8G 38% /
tmpfs 251M 4.0K 251M 1% /dev/shm
/dev/sda1 1.4T 198M 1.3T 1% /myth

Looks pretty good, eh?! The ide drive is actually rather large (100gb) so I might just leave /myth on that drive and simply move the videos I want to keep over to the raid array mounted elsewhere (/data or something) for long-term storage.

So I think I'm getting close. Thank you ethernut! Now I can try and figure out how to configure the tuner stuff. Yahoo!

I am having the exact same problem.
My system: MOBO: Foxconn 955X7AA, CPU:Pentium D 820, RAM: 2 x 512MB 240-Pin DDR2 SDRAM DDR2 667, HD: SAMSUNG SpinPoint T Series HD400LJ 400GB 7200 RPM SATA 3.0Gb/s

After install (R5E50), and upon reboot and start of linux I first get an error message intel_rng: FWH not detected.

After a screen with colorful text, I get the same error as in this post (Suspend2 2.2.8.4: Missing or invalid storage location)

I tried to do the fix Cecil provided:



But the "chroot /mnt/hda1" did not work: "Chroot: cannot change root directory to /mnt/hda1: no such file or directory"

What am I doing wrong?

_________________
Lars

Following directions too literally, without paying attention to what they're doing. Pay attention to the letters highlighted in bold below.

Having just mounted device sda1 on a mount point with a similar name it doesn't do much good to chroot to (the nonexistant) directory hda1. You should do this there instead.

Thanks tjc,
I am so new to Linux I had to google how to use vi...
I just tried the fix, and came so far as to add the line to linuxrc.
But after typing "cp /path/to/3mware.ko modules/" I get this error message:
"cannot stat 'path/to/3mware.ko': no such file or directory.
Am I doing another stupid newby mistake?
Does it have anything to do with the module name (and what is that?)

Thanks for your help!

_________________
Lars

The bit in bold were some handwaving instructions not an actual directiory name...

Ah, I see. So how can I find out which directory 3mware.ko is in?

Thanks again

_________________
Lars

You can start with this command: find / -name 3mware.ko -print

if you are using the newest version it would be


cp /lib/modules/2.6.18-chw-13/kernel/drivers/scsi/3w-9xxx.ko modules/

_________________
Marty

Long live Myth and Knoppmyth!!!!!

Hello, I'm having the same problem as xuxa. Same errors after initial installation to a partition on a raid.

I have a PERC 4/DC raid controller, and I tried the steps recommended by cecil for injecting the modules at boot, substituting the modules for my card (megaraid, megaraid_mbox, and megaraid_mm I believe). I followed all the steps and was sure to add the appropriate modprobes to linuxrc and copy the .ko files into the modules directory. Still no go.

In the past I have recompiled my kernel after doing the initial installation and have gotten this card working under R5C7. Unfortunately I've done this several times, as my R5C7 installs seem to consume themselves after 2-3 months. R5D1's kernel had some issues I was told with the PERC 4/DC so I skipped that version.

Since R5E50 no longer includes the kernal source, I downloaded the .deb from the FTP site, installed it, and tried to recompile the kernel. It quit with an error message fairly quickly about not being able to find a file (the file that is missing is not even in the path to the source, so I don't know what it wants).

Now I'm stuck as to what to try next. Sorry this is all in the abstract, I am not in front of my server right now, and cannot post exact error messages. Is there something I'm missing with trying to load these modules at boot, or in trying to recompile the kernel?

If I knew how to recompile the kernel under R5E50, I'm fairly confident I could make it work. But for some reason the process is either failing, or different then R5C7.

Any help is appreciated.

Edit: I was able to successfully recompile the kernel in R5E50 and boot KnoppMyth, I wiped the drive and started from scratch. I've always compiled the raid modules into the kernel, because this is the only way I know how to boot the raid. I'm not really sure about the pros/cons/necessity of doing this. Would there be a better way of doing the same thing?

This isn't specific to that hardware, I have the same problem on an Intel motherboard. Trying to install on a SATA drive leads to multiple lines of the of resume2= error. The resume2= error is understandable and harmless, but I don't understand why it is repeated. The OS finally goes bang and panics with etc/init: Out of file descriptors
and
Kernel panic - not syncing: Attempted to kill init!

I can add a parallel drive as hda and install to that, however when I boot into mythTV (with the intention of migrating /myth to the big SATA drive) udev does not instanciate sda. /var/log/messages shows the OS barfing on SATA with something like ATA: abnormal status 0x7F on 0xe407.

If I invoke any legacy modes on SATA, the original problem occurs on boot (even though booting to hda).

There is something up with the Kernel config or the boot directory contents, or the lilo config such that it is unhappy with SATA in ways that I have not seen elsewhere. I'm a bit perplexed.

I am in need of a cluestick.

- David

I did a little digging

The repeated resume= error lines are the result of lilo not having resume2=swap:/some_partition in it. Lilo doesn't understand the resume2 attribute, so I assume you need grub to add this attribute. I removed the invocation of the suspend function from linuxrc in the initrd and the multiple lines went away, replaced with a single complaint from suspend that linuxrc didn't have the line This let me see all the messages but there was little extra to see.

So I added some echos to linuxrc to see how far it got.

What is happening is that linuxrc is being invoked repeatedly. linuxrc mounts a few things (proc, sys) mounts slash, mounts sda1 to mnt, does a pivot_root then unmounts proc and slash.

So when being mounted repeatedly, I assume it runs out of file descriptors because of the repeated mounting of slash and/or sda1.

What I do not understand is why linuxrc is getting repeatedly re-run. I don't know what calls it. Is it init? I don't see an etc/inittab to tell it what to do. Is it that it gets re-run if it returns an error and the mount is failing every time?

I dug some further.

The kernel installed on /dev/sda1 was failing to identify the SATA devices on boot. The kernel on the CD did identify the SATA device and so could install to it.

The repeated lines of errors from linuxrc are simply because /dev/sda1 was not there, so the mount and pivot_root failed, so instead of picking the new init off sda1, it picked the existing one in initrd and started again.

The kernel reported ATA: abnormal status 0x7F on 0xE407. Assuming this to be related to the problem I went a googling and found there to be issues with multithreaded probes that were being discussed on lkml this December. Specifically, a lot of drivers are not thread safe when it comes to probing.

To get going, I dropped some money on a PATA 250G drive and installed and ran in that. I recompiled with the latest stable kernel (2.6.19.2) with no improvement. I turned off hyperthreading (since it was a thread safety issue being discussed on lkml) and bingo it worked.

I can't see any kernel option to turn of multithreaded probing. So this sucks.. multithreaded probing saves a few hundred milliseconds off the boot time. Turning off hyperthreading costs 20% performance all the time.

So the moral of this story is.. if you've tried everything discussed on this forum to get SATA working (particularly on an Intel 915GEV MB with Pentium D) and it installs but won't run with multiple resume2= errors, then turn off hyperthreading and go fix the piix_ata driver before I do.

- David.

I am using a SCSI Raid, and had to load the modules for the suspend2 stuff.
There actually is no modprobe in the initrd file, and the normal modprobe is not statically linked, anyway.
So, I found a static insmod binary on he cd, and copied that to the /static directory, and then added
/static/insmod /modules/megaraid_mm.ko
/static/insmod /modules/megaraid_mbox.ko
for my raid card (LSI Megaraid), and got it working.

Just FYI, it is easy to find out if a binary is linked dynamically.
strings binary-file shows libc.so.x for a dynamically linked binary in the output. If that's not there, it is usually safe to assume the binary is statically linked.