From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1) Gecko/20020417 Description of problem: When booting either from bootnet.img or from CD-ROM, kernel boots but then can't load the initial ramdisk. The kernel tries EXT-fs, cramfs, FAT and isofs (I think) before giving up and dying with a kernel panic. Redhat 7.1 works fine on my machine. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Boot computer with Redhat 7.3 installer disk (either floppy or CD-ROM) That's it! This occurs even when choosing the mediacheck option. Actual Results: Kernel panic. Expected Results: Nice installation procedure. Additional info: Processor is an AMD Duron. Most other things fairly standard.
Please check the md5sums of the ISOs you burned.
The md5 sums are correct. But I think you can mark this bug resolved - looks like it is hardware, as adding mem=128M (I have 256Mb installed) causes all to work. Though Redhat 7.1 never had any bother. And Redhat 7.3 seems fine without a mem= restriction on memory. Odd.
OK - more info. When I boot the BIOS mentions 16Mb shared memory (shared with the video card maybe?) and my profile on RHN and the free command both seem to agree that I have 240 MB (rather than 256MB). So it seems the running kernel knows something is up with the last 16MB. But the installer doesn't. Does that help?
Matt is this a problem with syslinux?
I'm having the same problem as mentioned by peter.hunter. The installer tries to load the ramdisk and panics. The md5 checksums of my iso's match that of the ones on the red hat site. Running 384 megs of memory.
Here's a little more information which might or might not help. It's the last few pieces of information relating to the panic. RAMDISK: Compressed image found at block 0 crc error<6>Freeing initrd memory: 1976k freed EXT2-fs: unable to read superblock cramfs: wrong magic FAT: unable to read boot sector isofs_read_super: bread failed, dev=09:00, iso_blknum=16, block=32 Kernel panic: VFS: Unable to mount root fs on 09:00 I truncated the beginning of the boot sequence because everything looked alright up until the crc error line. I'm running a P3 773 with a BE6-II mobo and 384M memory. On Peter's suggestion, I tried the mem=128M parameter but that didn't work for me. If there's anymore info I could provide you with that would help, please let me know.
Additional notes after more testing: Burning the CD using 'disc at once' mode causes the above errors. Burning the CD using 'track at once' mode circumvents the above errors, but hangs at the blue screen just after it finishes loading /sbin/loader right at the end. Booting with a floppy made from boot.img allowed me to boot and install normally.
Just to make things clear - I do not see the crc error that byap sees. Maybe two seperate problems?
I've got the same problem. Looking in this bugzilla I found bug 65187. I was installing ReadHat 7.3 in my laptop, with 128 MB of RAM with 8 MB of shared memory for the video card. Using these parameters, the installation started: mem=exactmap mem=640K@0 mem=119M@1M Hope this helps.
Here's a new twist: Disabling power management in BIOS also is a way of getting past kernel panic. First, with power management in BIOS set to APM/APCI with all other power sub-options disabled, I had experiencesimilar to others as described below. How reproducible: Always Steps to Reproduce: Wipe hard drive. Boot Red Hat 7.3 Disk 1. Hit return at "boot: " prompt yields the following dead end: EXT2-fs: unable to read superblock cramfs: wrong magic FAT: unable to read boot sector isofs_read_super: bread failed, dev=09:00,iso_blknum=16, block=32 Kernel panic: VFS: Unable to mount root fs on 09:00 I have 128MB of memory of which 8MB is shared for video, so I tried: boot: linux mem=120M with same kernel panic result. However, boot: linux mem=112M gets past the kernel panic. Text installs had same experience. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Then I disabled power management in BIOS, and repeated installation. It worked without any problems. I didn't have to specify any memory parameters when booting. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Hardware is very cheap motherboard of mostly SiS chipset stuff (sis630 video, sis900 ethernet) with 1050MHz Athlon (1400 part downclocked), 128MB of memory, 27KB IDE hard drive, IDE CD-ROM drive. I verified that the CD has the correct md5sum. The system worked fine with RH 7.2.
I have basically the same kind of m/b as jep.com - cheap SiS with lots of integrated components. Maybe a BIOS bug? But what's strange is that once installed, the kernel plays nicely with my machine. What's different about the installer kernel? If it would really help, I can annoy my users by booting the machine with the installer disk having turned off power management. But only if it would help.
I experienced exactly the same problem as mentioned by byap. But my configuration is quite different: 486 DX2, 32MB EDO RAM, 3 IDE disks, ATAPI CD-ROM. I tried to use installation options: - mem=exact-map, - nodma, - lower the ammount of available memory from 32m to 16m, 8m and other values, but with no success.
I always had this problem with RH distros. And I *always* solve them very nicely...Disable ACPI under "power management" in the BIOS. Or use APM ONLY. Do not use APM/ACPI combos. The error you mention can be reproduced 100% of the time. Can any RH engineer tell me why RH does not like ACPI management? Thanks, Erick Perez eperez
I am having the same problem. I have a Compaq Proliant 2500 with (5)18.2GB HDD's. RAID5. 680M of memory. Compaq Smart 2/P array controller. 7.3 will not detect memory and when I boot with: boot: linux mem=680M It gives me a kernel panic EXT2-fs: unable to read superblock cramfs: wrong magic FAT: unable to read boot sector isofs_read_super: bread failed, dev=09:00,iso_blknum=16, block=32 Kernel panic: VFS: Unable to mount root fs on 09:00 I have tried all the solutions on this page. 7.2 installs with little to no problem. Only have to specify memory size.
Is this any better with the Fedora test releases?
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/