Bug 142705

Summary: /dev/null is read only - no permissions
Product: [Fedora] Fedora Reporter: Marc Perkel <marc>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED WONTFIX QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 3   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-01-10 06:06:13 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Marc Perkel 2004-12-12 23:33:26 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3)

Description of problem:
Creates a bizzare /dev file system where there are no access
permissions on /dev/null and the /dev/cpu directory is missing.

I was running Fedora Core 2 and upgraded to Core 3 using YUM.

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

How reproducible:

Steps to Reproduce:
1. Upgread from Core 2 to Core 3 using Yum

Additional info:
Comment 1 Harald Hoyer 2004-12-13 03:54:33 EST
please read:

 The steps to upgrade without Anaconda or a rescue CD are (NOT

    * start from a kernel-2.6
    * Make sure /sys/ is mounted
    * Install the latest initscripts package
    * Install the latest udev package
    * Execute /sbin/start_udev
    * Install the latest mkinitrd package
    * Install the latest kernel package
    * Or execute mkinitrd for your existing kernel(s) 
Comment 2 Steve Fink 2005-01-09 15:09:29 EST
I had the same problem, upgrading via apt-get dist-upgrade from
RedHat9 to FC3. It seems to me that this bug should be marked a
duplicate of the actual bug, which is that the upgrade process doesn't
work. I was able to fix my system by doing

  mkdir /sys
  mount none /sys -t sysfs

and then hopefully fixing it for later boots by adding

  none                    /sys                    sysfs   defaults   
    0 0

to my /etc/fstab. (Haven't tried rebooting yet). Seems like the udev
rpm could have done that.

On the other hand, the automated upgrade broke quite a few other
things as well (it even mangled the partition table on a secondary
drive!), so it's probably a "don't do that". But the bug should be
logged anyway.
Comment 3 Harald Hoyer 2005-01-10 06:06:13 EST
well, "don't do that" is correct ... sorry guys