Bug 1070676

Summary: btrfs - missing /dev/btrfs-control causes btrfsck to taint and crash the kernel - please include correct dracut module
Product: Red Hat Enterprise Linux 6 Reporter: lejeczek <peljasz>
Component: dracutAssignee: Harald Hoyer <harald>
Status: CLOSED ERRATA QA Contact: Release Test Team <release-test-team-automation>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.5CC: dracut-maint-list, jstodola, lindahl, mganisin, peljasz
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Cause: The device node "/dev/btrfs-control" is only created, after the btrfs kernel module is loaded. Consequence: Tools trying to access /dev/btrfs-control prior to the btrfs kernel module loading fail. Fix: /dev/btrfs-control is now statically created by the dracut initramfs environment. Result: All access to /dev/btrfs-control will trigger the kernel auto loading of the btrfs kernel module and tools will not fail.
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-10-14 07:05:32 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description lejeczek 2014-02-27 10:56:56 UTC
Description of problem:

it is the cause of grief to many customers, 

simple fix would be: (works for me)

inst_hook pre-mount 40 "$moddir/install.btrfs-control.sh"

#!/bin/bash
mknod /dev/btrfs-control c 10 234


having dracut taken care (dracut should be the best place for it I imagine) of it solves the problem
there is even relevant bug report in btrfs but does not seem someone looked into it
https://bugzilla.redhat.com/show_bug.cgi?id=920537

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Harald Hoyer 2014-02-27 13:10:15 UTC
Well, no need to mknod these days with devtmpfs mounted on /dev.

Does it work, if you have:

---- SNIP -----
SUBSYSTEM!="block", GOTO="btrfs_end"
ACTION!="add|change", GOTO="btrfs_end"

ENV{ID_FS_TYPE}=="btrfs", RUN+="/sbin/modprobe btrfs"
ENV{ID_FS_TYPE}=="btrfs", RUN+="/sbin/btrfsctl -A $env{DEVNAME}"

LABEL="btrfs_end"
---- SNIP -----

in /etc/udev/rules.d/40-btrfs-module.rules ?

Comment 3 lejeczek 2014-02-28 17:56:32 UTC
it doesn't, actually I've had it all this time there, if it's not distro's default then I must have put it myself long time ago
nope, it's default, I've just check another box
these rules do not seem to create /dev/btrfs-control
is it kernel module that is supposed to take care of it?

Comment 4 RHEL Program Management 2014-05-12 19:21:23 UTC
This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release.  Product
Management has requested further review of this request by
Red Hat Engineering, for potential inclusion in a Red Hat
Enterprise Linux release for currently deployed products.
This request is not yet committed for inclusion in a release.

Comment 5 Harald Hoyer 2014-05-13 09:43:29 UTC
(In reply to lejeczek from comment #3)
> it doesn't, actually I've had it all this time there, if it's not distro's
> default then I must have put it myself long time ago
> nope, it's default, I've just check another box
> these rules do not seem to create /dev/btrfs-control
> is it kernel module that is supposed to take care of it?

normally:
/sbin/modprobe btrfs

should simply let the device appear. But yeah, it cannot hurt to precreate it.

Comment 6 Harald Hoyer 2014-05-28 14:20:27 UTC
please test:
http://people.redhat.com/harald/downloads/dracut/dracut-004-347.el6/

Comment 9 Jan Stodola 2014-09-08 13:49:37 UTC
/dev/btrfs-control is created by dracut:

switch_root:/# ls -l /dev/btrfs-control
crw-------. 1 0 root 10, 234 Sep  8 13:46 /dev/btrfs-control
switch_root:/#

Tested with dracut-004-349.el6.

Moving to VERIFIED.

Comment 10 errata-xmlrpc 2014-10-14 07:05:32 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1492.html