Bug 603724 - Do not remove existing udev database in start_udev script
Summary: Do not remove existing udev database in start_udev script
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: udev   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 610925
TreeView+ depends on / blocked
 
Reported: 2010-06-14 12:57 UTC by Peter Rajnoha
Modified: 2010-07-02 18:43 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 610925 (view as bug list)
Environment:
Last Closed: 2010-06-25 11:56:53 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

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