Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 603724 - Do not remove existing udev database in start_udev script
Do not remove existing udev database in start_udev script
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
Depends On:
Blocks: 610925
  Show dependency treegraph
Reported: 2010-06-14 08:57 EDT by Peter Rajnoha
Modified: 2010-07-02 14:43 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 610925 (view as bug list)
Last Closed: 2010-06-25 07:56:53 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 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.

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