Bug 603724

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 RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: agk, harald, jonathan, mbroz
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 610925 (view as bug list) Environment:
Last Closed: 2010-06-25 07:56:53 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 610925    

Description Peter Rajnoha 2010-06-14 08:57:30 EDT
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.