Bug 610925

Summary: Do not remove existing udev database in start_udev script
Product: [Fedora] Fedora Reporter: Peter Rajnoha <prajnoha>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 13CC: agk, harald, jonathan, mbroz
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: udev-153-3.fc13 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 603724 Environment:
Last Closed: 2010-08-19 21:27:36 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 603724    
Bug Blocks: 610889    

Description Peter Rajnoha 2010-07-02 14:43:44 EDT
Harald, we need to keep the udev database in F13 as well (+ the IMPORT{db} udev rule support). Thanks!

+++ This bug was initially created as a clone of Bug #603724 +++

Any existing udev database is removed while processing /sbin/start_udev script today. The script includes this line:

  rm -fr $udev_root/.udev > "$udev_root/null" 2>&1

Considering that we're using udev in initrd already (dracut), we have the udev database filled in during initrd stage as well for certain devices. Such information could be very important for later use, e.g. to correctly process the "udevadm trigger --action=add" coldplug used during udev initialisation after the root fs is ready for use.

For example, such information is an important piece to correctly process the coldplug's ADD events for device-mapper devices. Device-mapper devices should normally be processed on CHANGE events only, but the coldplug at boot generally uses ADD trigger without making any distiction between such artificially generated ADD events and ADD events generated as a result of a real creation of a device, therefore making it impossible to react properly.

The information that is stored in udev database contains helper variables set during device activation to take a proper action later (also using a new IMPORT{db} udev rule).

Since there's no real need to remove the database at this stage, we should try to preserve the database from previous runs so any udev rule processing can take advantage of existing database.

Any information that needs to be updated will be updated as a result of processing the trigger event that is used in start_udev script later.
Comment 1 Fedora Update System 2010-08-02 14:23:22 EDT
udev-153-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/udev-153-1.fc13
Comment 2 Fedora Update System 2010-08-02 21:10:06 EDT
udev-153-1.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update udev'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/udev-153-1.fc13
Comment 3 Fedora Update System 2010-08-05 02:49:30 EDT
udev-153-2.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/udev-153-2.fc13
Comment 4 Fedora Update System 2010-08-05 19:48:33 EDT
udev-153-2.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update udev'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/udev-153-2.fc13
Comment 5 Fedora Update System 2010-08-13 04:39:19 EDT
udev-153-3.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/udev-153-3.fc13
Comment 6 Fedora Update System 2010-08-19 21:26:59 EDT
udev-153-3.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.