[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: f10dvd installs but won't boot
- From: Craig White <craigwhite azapple com>
- To: "Community assistance, encouragement, and advice for using Fedora." <fedora-list redhat com>
- Subject: Re: f10dvd installs but won't boot
- Date: Tue, 05 May 2009 13:56:28 -0700
On Tue, 2009-05-05 at 13:31 -0700, jackson byers wrote:
> David wrote
> Just in case you are not aware of this Jackson, it may help to know
> that the boot process and messages can be paused by pressing ctrlS and
> resumed by ctrlQ
> thanks David, that helps me look at all msgs up to some point
> shy of the failure point
> which is something like
> Waiting for X-server...
> I cant catch final part of that line,
> the screen goes blank immmediately after it shows up.
this sounds like an x problem...another problem entirely
> additional info:
> 1)commenting out hiddenmenu in grub.conf
> --does not present the choices to me, it just grabs first one
Just a note here...you have to press a key on the keyboard in order to
also, a line like the following in /boot/grub/grub.conf
can give you enough time to press a key on the keyboard to have choices
> --even worse, it prevents ESC from showing the choices
> So now I am back to hiddenmenu nobegining # and ESC works
> 2)acpi=off looks no different, gets to Waiting for X-server...
> then screen blanks
> 3)retesting taking scsi_mod.scan=sync out of the kernel line
> still with "rhgb quiet" removed
> goes back to what I previously observed:
> mount: error mounting /dev/root on /sysroot no such file or directory
> that msg does point to the initrd because the init script therein
> is trying do that mount
> but now that scsi_mod.scan=sync appended to kernel line
> gets past that error, I dont see further evidence of initrd error.
> scsi_mod.scan=sync is required. FWIW at the end I copy
> the section from f10releasenotes on this.
> 4)I remain stuck at Waiting for X-server..
> It is not as if X is just failing to come up
> with normal boot otherwise; this prevents the boot from finishing
> here is the quote
> ==from f10 commonproblems or f10 release notes
> New Fedora 10 installs do not boot, boot delays for 10 seconds or
> stabilization cannot be detected
> link to this item - Bugzilla: #473305 and Bugzilla: #470628 On systems
> that use specific SCSI hardware (can include SATA controllers), a
> fresh install could complete, but on reboot it would hang and either
> display "stabilization cannot be detected", delay for 10 seconds or
> not continue to boot at all, with sg or other devices being listed.
> The problem is that mkinitrd was edited to enhance boot times. This
> introduced an IF clause, that, under specific circumstances, causes
> scsi_wait_scan not to be loaded and also prevents 'emit "stablized
> --hash --interval 250 /proc/scsi/scsi"'from being called, and hence
> the above mentioned issues occur.
> In order to fix this issue, a temporary option can be used, by editing
> the kernel argument from within grub and appending
> "scsi_mod.scan=sync". This will allow the boot to proceed in most
> circumstances, although it might take a few seconds to proceed. By
> using the mentioned kernel argument anaconda freeze-ups and crashes on
> some systems are also prevented, during the installation process.
> A better fix is to rebuild the initrd that the kernel requires in
> order to boot. mkinitrd --with=scsi_wait_scan (detailed instructions
> below). Beginners please follow the steps below:
> # To fix this issue, boot from live-media.
> #Become root on the live-system (note the dash):
> su -
> # Enable LVM, if you are using LVM:
> vgchange -ay
> # Create a mount point:
> mkdir /mnt/sysimage
> # Mount your installed system (VGhere = Your VolumeGroup;
> # LVname = Name of Logical Volume):
> mount -t ext3 /dev/VGhere/LVname /mnt/sysimage
> # Note: Experienced users also mount your other mount points,
> # such as /var into the chroot.
> # If required mount the /boot partition into the chroot
> # (where sdxx is the /boot partition):
> mount -t ext3 /dev/sdxx /mnt/sysimage/boot
> # Mount the required special kernel directories into the chroot environment:
> mount --bind /dev/ /mnt/sysimage/dev
> mount --bind /proc /mnt/sysimage/proc
> mount --bind /sys /mnt/sysimage/sys
> # Change into the directory root of your installed system:
> chroot /mnt/sysimage
> # Rename your old initrd (note your initrd version might be different,
> # modify as required)
> mv initrd-188.8.131.52-130.fc10.x86_64.img initrd-184.108.40.206-130.fc10.x86_64.img.old
> # Create your new initrd image
> # Note: The third argument after mkinitrd is the kernel version)
> mkinitrd --with=scsi_wait_scan initrd-220.127.116.11-130.fc10.x86_64.img
> # Exit the chroot environment and reboot:
> Now pray! Please note the lines beginning with a "#" are comments!
> Some command lines are separated by a carriage return.
> Important Note: mkinitrd-6.0.71-3.fc10 fixes the issue above!! Please
> update your system after fixing manually, or better after booting
> using the kernel argument "scsi_mod.scan=sync" !!!
If you read Bill Nottingham's comment (# 19), the solution seems far
You would have to get a boot up and into a virtual console.
A. let it boot up until the screen disappears...
B. Press a key at the grub prompt and highlight the kernel with the
arrow keys and press the letter 'e', move down to the kernel line and
press the letter 'e'. Add a space and put in the number "3" to tell it
to boot to runlevel 3
After startup either way...
login as root and as root, run...
yum update mkinitrd
This would take some time to install all of the updates.
This still won't solve your X problems.
That would probably need you to switch to the console again as above and
again, login as root
yum install system-config-display
and see if you can get a working X display
You can test it by typing 'startx'
Once you get X running, you can type 'init 5' or just reboot
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
[Date Prev][Date Next] [Thread Prev][Thread Next]