I don't think that Mandriva likes me!

[onederer]

Well, I had purchased this 64 bit AMD 3400+ computer, and was looking forward to installing a 64 bit operating system in the new serial hard drive that I got just for this occasion.Don't ask me how I did it, but I succeeded the first time out, installing the OS in that second hard drive. I remember having a hard time with the Via Technologies video board. But I managed to get around it by selecting a Vesa driver. Spend a good amount of time setting things up and tweaking this and that. And when I was done, I hadn't used Linux for quite a few days. That is until that day that I decided to fire it up.The only thing that was facing me was a kernel panic message, and I wasn't able to recover from that. I tried to reinstall it, and everytime was a failure. In the meantime, the mother board suffered a heart attack, and wouldn't do any networking anymore. I also found out that the Bios was corrupt. The manufacturer honored the warrantee, and send me a replacement board. Upon swapping the boards, Win** came up without any problems. So I thought that it would be a fine time to try to install once more Mandriva 64 bit OS. Again, it balked when it came to the video card. It couldn't configure it. I tried the Vesa trick, but it didn't take. This was the last part of the error message that I read:Ramdisk: Couldn't find valid RAM disk image starting a 0.VFS: Cannot open root device "811" or unknown-block (8,17)Please append a correct 'root=" boot optionKernel panic - not syncing: VFS Unable to mount root fs on unknown - block (8,7)So, being the die-hard that I am, I decided to try installing the OS once more. The result: Same old junk. No dice! It just won't go in there. This what some of the last part of the error message read:VFS: Can't find ext3 filesystem on /dev/sda1.mount: error 22 mounting ext3 flags notailwell, retrying without the options flags.VFS: Can't find ext3 filesystem on /dev/sda1.mount: error22 mounting ext3pivotroot: pivot - root (sysroot,sysroot/initrd) failed:2umount /init/sys failed:2Initrd finishedFreeing unused kernel memory: 220K freed.Kernel panic - not syncing: No init found. Try passing init= option to kernel.Without a solution, I won't try to install another 64 bit OS in that system, until I know what's going on. I do know that SDA1 is the Win** serial drive. sda2 should be the Linux drive. How it's getting it's information crossed, I don't know. I did try to swap the hard drive cables to see if it would make any difference. But that didn't help.So now I come to you to see if you can make anything out of the above information.Now I have one machine with Win** and SuSe, and no problems. The new 64 bit machine with only Win**, since it seems to be Linux resistant. I believe that the Via video board uses S3 drivers, and Linux doesn't seem to have the modules for that.And the third machine, has win98SE, and Debian (still can't get the printing to work in that one, and can't get Mandriva installed in the spare hard drive).I would like to get a 64 bit OS running in the new machine, and later try something else in the Tower, next to Debian.Cheers!

[linuxdude32]

I think the clue lies in this:

Ramdisk: Couldn't find valid RAM disk image starting a 0.VFS: Cannot open root device "811" or unknown-block (8,17)Please append a correct 'root=" boot optionKernel panic - not syncing: VFS Unable to mount root fs on unknown - block (8,7)

That says to me that it was looking but couldn't find an initrd file (the first line) and that it couldn't find the root partition (/).It sounds like the installer guessed your setup incorrectly and therefore wrote the wrong lines in your /etc/lilo.conf or /boot/grub/menu.lst file depending on which bootloader you're using. Do you have a Live Linux CD you can boot from? If so, you need to let us know what is in these files.You should use give us the output of:

fdisk -l

If you need help in mounting the distro partitions and such, just ask.

[Bruno]

Well, I had purchased this 64 bit AMD 3400+ computer

<{POST_SNAPBACK}>

Did you check it's Linux hardware compatebillity before buying ?? Bruno

[onederer]

Well Linux does make a 64 bit version for AMD processors. The only incompatibility now that I found is the built-in video. I don't think that there is a driver available for the S3 version yet. I had gotten away with it by selecting Vesa instead of S3, or making up a generic setup.But at the moment, that's down the river, until things get straightened out. If I have to, I can buy a compatible card, and disable the on-board video, in the Bios.

[onederer]

I think the clue lies in this:That says to me that it was looking but couldn't find an initrd file (the first line) and that it couldn't find the root partition (/).It sounds like the installer guessed your setup incorrectly and therefore wrote the wrong lines in your /etc/lilo.conf or /boot/grub/menu.lst file depending on which bootloader you're using. Do you have a Live Linux CD you can boot from? If so, you need to let us know what is in these files.You should use give us the output of:

fdisk -l

If you need help in mounting the distro partitions and such, just ask.

<{POST_SNAPBACK}>

Here's what I managed to get by using a SuSe 9.3 live CD:This is /etc/lilo: default="linux"boot=/dev/sdamap=/boot/mapkeytable=/boot/us.kltpromptnowarntimeout=100message=/boot/messagemenu-scheme=wb:bw:wb:bwimage=/boot/vmlinuz label="linux" root=/dev/sdb1 initrd=/boot/initrd.img append="resume=/dev/sdb5 splash=silent" vga=788 read-onlyimage=/boot/vmlinuz label="linux-nonfb" root=/dev/sdb1 initrd=/boot/initrd.img append="resume=/dev/sdb5" read-onlyimage=/boot/vmlinuz label="failsafe" root=/dev/sdb1 initrd=/boot/initrd.img append="failsafe resume=/dev/sdb5 devfs=nomount" read-onlyother=/dev/sda1 label="windows" table=/dev/sdalinux:/media/sdb1/etc # And this is the content of fdisk -l :Disk /dev/sda: 200.0 GB, 200049647616 bytes255 heads, 63 sectors/track, 24321 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System/dev/sda1 * 1 22985 184626981 7 HPFS/NTFS/dev/sda2 22986 24321 10731420 f W95 Ext'd (LBA)/dev/sda5 22986 24321 10731388+ c W95 FAT32 (LBA)Disk /dev/sdb: 203.9 GB, 203928109056 bytes255 heads, 63 sectors/track, 24792 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System/dev/sdb1 * 1 23851 191583126 83 Linux/dev/sdb2 23852 24792 7558582+ 5 Extended/dev/sdb5 23852 24792 7558551 82 Linux swap / SolarisI hope that this information helps. /dev/sda should be the WindowsXP drive, and /dev/sdb should be the Linux drive.Cheers!

[onederer]

Where do I go from here?Can I beat this by editing Lilo.conf? Could you help me with this?Do I have to clear out the /dev/sda MBR (I forgot the WinXP command to do this)?What else do I need to do?Cheers!

[linuxdude32]

Where do I go from here?Can I beat this by editing Lilo.conf?  Could you help me with this?Do I have to clear out the /dev/sda MBR (I forgot the WinXP command to do this)?What else do I need to do?Cheers!

<{POST_SNAPBACK}>

Hmmmm... this looks right but it's been a while since I used lilo. Bruno, do you see anything amiss here?Only other thing I can think of right now is to check that the files that it points to and make sure they have exactly used filenames. For example, here:

image=/boot/vmlinuzlabel="linux"root=/dev/sdb1initrd=/boot/initrd.imgappend="resume=/dev/sdb5 splash=silent"vga=788read-only

Check to make that /boot has the files vmlinuz and initrd.img. PClos might have a repair mode that can fix this. Something like "reinstall bootloader" or similar.

[teacher]

Hmmmm... this looks right but it's been a while since I used lilo. Bruno, do you see anything amiss here?Only other thing I can think of right now is to check that the files that it points to and make sure they have exactly used filenames. For example, here:

image=/boot/vmlinuzlabel="linux"root=/dev/sdb1initrd=/boot/initrd.imgappend="resume=/dev/sdb5 splash=silent"vga=788read-only

Check to make that /boot has the files vmlinuz and initrd.img. PClos might have a repair mode that can fix this. Something like "reinstall bootloader" or similar.

<{POST_SNAPBACK}>

Bruno can't answer right now. He is out of town for a few days. However, looking at it, I don't see anything that looks amiss. The image is right as it had to copy the files when it did the boot. It says the boot program is in the mbr (sda) and the distro with its root is on sdb1. That matches with where he said he installed it. The image and the initrd are set up as a symbolic link in that folder so they will always be correct. The vga is the standard 1024 x 768 and sb5 would be the swap file. Splash silent would mean not to show the details, but rather an image instead. Error 22 is "no such partition". That means it can not find the partition. So the question becomes, is it sdb1 or something else. What does fstab show?

[linuxdude32]

I notice in the error message it refers to not being seeing a partition at sda1. No wonder, that's a Windows NTFS partition! Why it's looking there I'm not sure.Julia makes a good point. What does /etc/fstab look like? There may lie an answer.

[burninbush]

Something I wonder, reading this -- might be useful. I don't have a SATA drive here yet, but the fact that linux calls them /dev/sda, sdb, etc., brings to mind my early troubles with scsi drives, which are also /dev/sdX. Are SATA drives handled by the same sort of drivers as scsi? If so, it could be that the kernel he's trying to boot doesn't have drivers to read that type of disk hardware. I saw a lot of messages in the early days just like that; kernel panics because the kernel being booted couldn't find the device designated as root. Wouldn't be the first time that has happened. To Onderer ... I wonder if you have something like a Mepis disk handy, that would allow you to get grub up in command-line mode? You might be able to boot it that way, i.e., tell grub where to look for the kernel file version that is on your (hd1,0) partition [and also make it find the initrd file]. If that installed kernel includes support for your SATA drives, then you should be able to boot it that way, regardless of what lilo did right/wrong. Is it possible that you have changed your boot order in cmos after doing the install? When you want to run Windows, do you now have to get to it from a lilo screen?

[ross549]

the 2.4 kernels require that you load "ide-scsi" in the append line.... in 2.6 it is already built in.

[burninbush]

the 2.4 kernels require that you load "ide-scsi" in the append line.... in 2.6 it is already built in.

<{POST_SNAPBACK}>

But that's only useful for ide-cdroms, Ross, has nothing to do with booting from a hard disk.If you have a real scsi disk [and I guess not that many linux users have scsi disks] it requires drivers to be either incorporated directly into the vmlinuz file, or else loaded to a ramdisk at bootup [in the initrd file]. Failing one of those, you'll get kernel panics just like what the user described; unable to find a root device. Without the driver in memory or kernel code, the scsi disk just doesn't exist. Here, I have Adaptec boards, and watch for text re "aic7xxx" during early bootup, which means the kernel is going to find my scsi hardware. If you search a recent /boot/config-2.6.whatever file, looking for 'SATA' you'll see that there are lots of statements in there pertaining to SATA disks. Seems likely that a recent distro would have accomodated this, but lots of unlikely-seeming events occur in linux universe. Load any recent Slack distro, for example, and at the point where you select what kernel to use, you are encouraged to use the one used during install [booted from the ide cdrom] -- even if you installed to a scsi disk! And then, of course, it won't boot, even from the kernel now in /boot. Another big gotcha. So, what I don't know, zero experience, is how his linux and SATA play together. Just offered it as a possibility.

[linuxdude32]

If you have a real scsi disk [and I guess not that many linux users have scsi disks] it requires drivers to be either incorporated directly into the vmlinuz file, or else loaded to a ramdisk at bootup [in the initrd file].  Failing one of those, you'll get kernel panics just like what the user described; unable to find a root device.  Without the driver in memory or kernel code, the scsi disk just doesn't exist.  Here, I have Adaptec boards, and watch for text re "aic7xxx" during early bootup, which means the kernel is going to find my scsi hardware. 

Good point. I was thinking it was failing on the root device and had found the initrd but it didn't, an error before that says it couldn't find the RAMDISK which is what initrd is (INitial RamDisk). It needs the ramdisk so that it has a SCSI driver built-in in order to setup the root disk (/). I have a SCSI drive too and always need a ramdisk but several distros still fail to create one (or fail to create instructions to load one in the bootloader).onederer: did you change the bootup order in your BIOS? I don't know much about SATA, does it use master/slave? Maybe it's not clear to the computer which one is the bootup drive.

[burninbush]

... It needs the ramdisk so that it has a SCSI driver built-in in order to setup the root disk (/). I have a SCSI drive too and always need a ramdisk but several distros still fail to create one (or fail to create instructions to load one in the bootloader).

<{POST_SNAPBACK}>

Scsi problems are what shoved me into doing kernel compiles; what I tend to do these days is to closely survey the hardware on my system, and them make a kernel that specifically builds-in every driver I need to the kernel proper, and specifically excludes everything I don't need. This usually produces a bzImage ~2mb size, smaller than a lot of initrd files. So, that done, there is no more need for initrd files, and without a lot of modules, the same kernel will work with most any distro. There are a few stock distros that routinely put my aic7xxx into the kernel itself -- Mepis comes immediately to mind. Having a new distro find the scsi hardware is a lot more common today than it was 2 years ago when I first got into linux. I think that may be due to just giving up on trying to make boot diskettes -- so kernels can be bigger now. Re the thread, I dunno how kernels deal with SATA, but given the names, it might be a similar problem. There are a bunch of items in xmenuconfig about SATA disks. Also dunno exactly how ramdisks get declared -- some distros require a size to be specified, others have nothing but the initrd= statement, and I suppose must get the size info from the initrd file itself.

[BarryB]

onedererAs a system check, you might want to try the kanotix 64bit version ftp://debian.tu-bs.de/kanotix/KANOTIX-64-2005-03I have it installed on a 64bit box with no sata issues, the install is a bit more involved than Mandriva(actually different is a better choice of words and does take a small amount of cli work..it is a fast install though, but it's also a live cd.But the point is that it (if it works) might give some answers to setting up your mandriva box. you can see it's configuration and set-up and maybe cross reference to mandriva (but kanotix in itself is pretty good and for the most part pure 64 bit)..Another work around, may be to go into bios an revert to ata, then install..then back to sata after the install.

[ebrke]

You guys know more about this than I do, but I do recall reading somewhere that if your kernel isn't 2.6.11, you should do what Barry said and revert to ata in the bios. Wherever I was reading (can't remember) said that before 2.6.11 could not handle sata.

[onederer]

This is a weird problem, and I still haven't been able to straighten it out yet. I only have 2 SATA drives, and no ATA drives. The kernel was a 2.6 variety. Mandriva installed itself once, but then for unknown reasons, just fizzled away, forcing me to attempt a re-install.