Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Created attachment 1288202[details]
example patch to add dm creation/removal logging
Description of problem:
RFE proposal to log addition and removal of dm devices by default. Thought of this while troubleshooting an environment in which I needed to know if a multipath partition device was created during a particular boot process. Then realized that there is no record of dm device creation. This is inconsistent with other devices, as their creation is logged (dm, mdadm, multipath, lvm activation). Very rarely are there systems that do not have an active dm layer.
Even though the names are not persistent, troubleshooting information can be gathered from knowing when the dm layer is increased or reduced. Adding the actual dmsetup name to the output would be wonderful, but unsure if this is possible; I could not find an easy way.
Version-Release number of selected component (if applicable):
kernel-3.10.0-681.el7
Actual results:
dm-x device addition and removal is not logged
Expected results:
Jun 15 16:27:26 localhost.localdomain kernel: device-mapper: core: Created dm-0
Jun 15 16:27:26 localhost.localdomain kernel: device-mapper: core: Created dm-1
Jun 15 16:27:28 localhost.localdomain kernel: device-mapper: core: Created dm-2
Jun 15 16:27:28 localhost.localdomain kernel: device-mapper: core: Created dm-3
Jun 15 16:27:28 localhost.localdomain kernel: device-mapper: core: Created dm-4
Jun 15 16:27:28 localhost.localdomain kernel: device-mapper: core: Removing dm-4
Jun 15 16:27:29 localhost.localdomain kernel: device-mapper: core: Created dm-4
Jun 15 16:27:29 localhost.localdomain kernel: device-mapper: core: Created dm-5
......
Jun 15 16:31:57 localhost.localdomain kernel: device-mapper: core: Removing dm-4
Any consideration is appreciated.
Don't you rather want to see logging of 'lvm2' messages ?
Such feature already exists in lvm.conf.
See the lvm.conf 'syslog=1' setting for logging in log{} section.
You may also select your preferred 'verbosity' level for less or more detailed syslogging of any lvm2 command.
What'd be the purpose of 'dm-XX' logging - these numbers are rather meaningless - as it's quite hard to 'map' dm-X to i.e. VG/LV in system for just this 'trace'.
I do not think that all dm devices creation and removal should be logged by default.
Note, there is difference between plugging of hw device (sd layer) and creating virtual (and possible private) device mapping.
For example, cryptsetup in some situations uses temporary devices that maps keyslots. This action is private to cryptsetup and should be visible only if users explicitly switch debug on. (It could reveal which keyslot was used, how many tries user did etc).
And if you are using hidden disk mapping for Truecrypt compatible device, it is even security problem for the user (it documents that user mapped something that should be, well, "hidden".
There are probably other info that already reveals such action in log but we should not make this even worse.
Please be very careful with enabling such features. For lvm it maybe makes sense (but just for top-level device and not with dm-X name) but for other users of device-mapper subsystem is is not so great idea.
Milan, Zdenek,
Yes, I agree. My need was related to wanting to see multipath partition devices being created. Perhaps I can focus my efforts there and see if I can come up with a better solution. Will close this or change component with updated possible patch as soon as I'm able to research this more.
Thanks for your time.
Created attachment 1288202 [details] example patch to add dm creation/removal logging Description of problem: RFE proposal to log addition and removal of dm devices by default. Thought of this while troubleshooting an environment in which I needed to know if a multipath partition device was created during a particular boot process. Then realized that there is no record of dm device creation. This is inconsistent with other devices, as their creation is logged (dm, mdadm, multipath, lvm activation). Very rarely are there systems that do not have an active dm layer. Even though the names are not persistent, troubleshooting information can be gathered from knowing when the dm layer is increased or reduced. Adding the actual dmsetup name to the output would be wonderful, but unsure if this is possible; I could not find an easy way. Version-Release number of selected component (if applicable): kernel-3.10.0-681.el7 Actual results: dm-x device addition and removal is not logged Expected results: Jun 15 16:27:26 localhost.localdomain kernel: device-mapper: core: Created dm-0 Jun 15 16:27:26 localhost.localdomain kernel: device-mapper: core: Created dm-1 Jun 15 16:27:28 localhost.localdomain kernel: device-mapper: core: Created dm-2 Jun 15 16:27:28 localhost.localdomain kernel: device-mapper: core: Created dm-3 Jun 15 16:27:28 localhost.localdomain kernel: device-mapper: core: Created dm-4 Jun 15 16:27:28 localhost.localdomain kernel: device-mapper: core: Removing dm-4 Jun 15 16:27:29 localhost.localdomain kernel: device-mapper: core: Created dm-4 Jun 15 16:27:29 localhost.localdomain kernel: device-mapper: core: Created dm-5 ...... Jun 15 16:31:57 localhost.localdomain kernel: device-mapper: core: Removing dm-4 Any consideration is appreciated.