Bug 465132 - (DanT) Problems with latest updates as of week of Sept 28-Oct 4
Problems with latest updates as of week of Sept 28-Oct 4
Status: CLOSED DUPLICATE of bug 462228
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-10-01 14:49 EDT by Dan Thurman
Modified: 2008-10-23 22:38 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-23 22:38:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dan Thurman 2008-10-01 14:49:44 EDT
Description of problem:

I have updated two different machines and ran into the following problems:

1) ASUS P5GC-MX/1333

(a) Kernel:

   - No Gui startup after udev
   - mkrootdev: could not determine nfs root target
   - mount: missing mount point
   - setuproot: moving /dev failed (No such file or directory)
              : error mounting /proc (No such file or directory)
              : error mounting /sys (No such file or directory)
              : error mounting /selinux (No such file or directory)
    - switchroot: Mount failed
    - system hangs

    I have removed and reinstalled the kernel and the problem remains.
    I was forced to use the previous kernel 1(b) since 1(a) was not

(b) Kernel

   + Worked with updates prior to that of last week or so,
     startup/login gui worked fine, however:

   - Due to current updates (last few days):
      - Startup gui fails to come up just after udev, but the login gui works.

2) Intel DQ35J0

(a) Kernel:
     Worked fine and did not have any problems, and it did not hang.
     But newer updates broke the startup gui as in 1(b) above

(b) Kernel
    Same as in 1(b) above.

Version-Release number of selected component (if applicable):

+ Noted in the description above as to kernel version

How reproducible:

Every time.

Steps to Reproduce:
1. N/A
Actual results:

+ See description above, not sure how to reproduce the problem

Expected results:


Additional info:

Comment 1 Dan Thurman 2008-10-01 17:42:40 EDT
The same problem as in 1(a) occurs for kernel-
just updated today (10/1/08)
Comment 2 Chuck Ebbert 2008-10-04 01:47:23 EDT
(In reply to comment #1)
> The same problem as in 1(a) occurs for kernel-
> just updated today (10/1/08)

Is it really an nfsroot system?
Comment 3 Dan Thurman 2008-10-04 12:43:49 EDT

I have never set my system up to use NFS whatsoever,
unless the yum update system itself inserted NFS root
without my knowledge.

I DO know that this problem appeared after an update
and it started when kernel was first
released and when I rebooted ASUS MB.  The other Intel MB
computer was found to be ok and it at another site
location, so, apparently this new kernel hang problem
only affects my ASUS MB system.

Can you explain to me if there is a way to check if
my system(s) are nfsroot and how I might go about
removing it in order to get the kernel to boot?

Thanks for responding,
Comment 4 Dan Thurman 2008-10-04 13:33:05 EDT
I looked up documentation regarding nfsroot and
read up on how they are setup and configured.  I
have found nothing to to indicate that my system
is using nfs or nfs booted filesystems.

I have checked dhcp cconfigurations, grub.conf,
removed all tftp packages, pulled the network
cable and so far none of these changes resolved
the kernel boot issue.

Comment 5 Dan Thurman 2008-10-04 14:29:14 EDT
I wanted to point out that if I boot
using the previous kernel version
kernel- it works.

Nothing about nfsroot was reported at all.

Seems the difference is the kernel version.
Comment 6 Dan Thurman 2008-10-07 14:38:28 EDT
As of 10/6/08:

Upgrading to kernel- on
Intel DQ35J0 (2 above) behaves exactly like
1(a) - it somehow believes it is "nfs-rooted".

Does anybody have anything to report so far
or is there anything I can do to help move
this issue along?

Comment 7 Ugo Viti 2008-10-08 16:18:07 EDT

have you installed ltsp-client package?

if so, boot using your latest working kernel and run "rpm -e ltsp-client"

after that, you must rebuild your initrd with:

mkinitrd -f /boot/initrd-

if you haven't installed ltsp-client I don't know because your kernel try to boot from nfs.

Best regards
Comment 8 Dan Thurman 2008-10-08 17:54:16 EDT

I had ltsp-client installed (must have been included in updates)
but I yum removed this, and performed the mkinitrd for each
kernel ( & and now,
both of these kernels are bootable!


And mow... one down and one more to go!

I am still not getting the bootup GUI to
work - is there a fix for that one yet?

Kind regards!
Comment 9 Ugo Viti 2008-10-09 07:36:11 EDT
You are talking about 'rhgb' ?

editing /etc/grub.conf in your running kernel line you should be have something like this:

kernel /boot/vmlinuz- ro root=LABEL=/ quiet rhgb

however verify if rhgb is installed: rpm -qi rhgb

Best Regards
Comment 10 Dan Thurman 2008-10-09 11:43:40 EDT
Yes, The RHGB stopped working due to the last massive
updates of which xorg/ltsp-client updates were included
in those packages.

I have used the same grub.conf file since F9 came out
but the last kernel version kept is
up to the most recent kernel release:

RHGB was working for both systems up to kernel versions:
(1) ASUS: and (2) Intel:
that is, until the most recent xorg packages was updated.
The timing of the RHGB break was definitely due to the updates,
and I suspect it is the latest xorg packages.

# cat /boot/grub/grub.conf2.6.26.5-45.fc9.i686
# grub.conf generated by anaconda
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/sda6
#          initrd /initrd-version.img
title Fedora (
	root (hd0,2)
	kernel /vmlinuz- ro root=LABEL=root-f9 rhgb quiet
	initrd /initrd-

title Fedora (
	root (hd0,2)
	kernel /vmlinuz- ro root=LABEL=root-f9 rhgb quiet
	initrd /initrd-

title Fedora (
	root (hd0,2)
	kernel /vmlinuz- ro root=LABEL=root-f9 rhgb quiet
	initrd /initrd-

# rpm -qi rhgb
Name        : rhgb                         Relocations: (not relocatable)
Version     : 9.0.0                             Vendor: Fedora Project
Release     : 6.fc9                         Build Date: Fri 02 May 2008 12:10:44 PM PDT
Install Date: Wed 07 May 2008 06:42:30 PM PDT      Build Host: hammer2.fedora.redhat.com
Group       : System Environment/Base       Source RPM: rhgb-9.0.0-6.fc9.src.rpm
Size        : 221433                           License: GPLv2
Signature   : DSA/SHA1, Fri 02 May 2008 02:22:46 PM PDT, Key ID b44269d04f2a6fd2
Packager    : Fedora Project
URL         : http://www.redhat.com/
Summary     : Red Hat Graphical Boot
Description :
Red Hat Graphical Boot provides a clean and simple interface to the boot process

If there is anything else I can provide you, please let me know!

Comment 11 Chuck Ebbert 2008-10-09 22:32:01 EDT
ltsp-5.1.26-1 fixes this.
Comment 12 Dan Thurman 2008-10-09 23:09:15 EDT
ltsp does not exist for me,
and if it did exist:

(1) What specifically does ltsp fix?
(2) Where can I get it?

Kind regards,
Comment 13 John Ellson 2008-10-11 20:31:42 EDT
The issue with ltsp-client is in bug #462228
Comment 14 Chuck Ebbert 2008-10-23 22:38:44 EDT

*** This bug has been marked as a duplicate of bug 462228 ***

Note You need to log in before you can comment on or make changes to this bug.