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 > -------- > jbyers: > > 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 have choices. also, a line like the following in /boot/grub/grub.conf timeout 10 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. > > so > 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 > > Jack > 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-2.6.27.7-130.fc10.x86_64.img initrd-2.6.27.7-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-2.6.27.7-130.fc10.x86_64.img > 2.6.27.7-130.fc10.x86_64 > # Exit the chroot environment and reboot: > exit > 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 easier... You would have to get a boot up and into a virtual console. Either... A. let it boot up until the screen disappears... press <Control><Alt><F2> or 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 yum update 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 init 3 yum install system-config-display system-config-display --reconfig 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 Craig -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
