You are not logged in.
Pages: 1
I have been seeing a warning on every boot saying
BTRFS: could not find root 8
Below is an excerpt from my current boot. I decided to include just a small part for now since this is where it seem to happen on every boot without exception.
...
nov. 23 01:49:42 fang systemd[1]: Mounted /home.
nov. 23 01:49:42 fang systemd[1]: Reached target Local File Systems.
nov. 23 01:49:42 fang systemd[1]: Starting Create Volatile Files and Directories...
nov. 23 01:49:42 fang kernel: BTRFS: could not find root 8
nov. 23 01:49:42 fang kernel: BTRFS: could not find root 8
nov. 23 01:49:42 fang kernel: BTRFS: could not find root 8
nov. 23 01:49:42 fang systemd[1]: Started Create Volatile Files and Directories.
...
I have three partitions that are mounted at boot so I assume this is why it appears three times in a row. Two of those partitions are btrfs filesystems, while one is a vfat partition. I first started getting this on a boot the 21st this month, and after some testing with downgrading specific packages I tracked it down to being caused by the upgrade to systemd-228. When I downgraded systemd, systemd-sysvcompat and libsystemd to 227-1, this warning stopped appearing.
I did some googling and came across this
http://www.spinics.net/lists/linux-btrfs/msg28713.html
So from what I understand, this message is not dangerous but is outputted when something calls btrfs qgroup show <mnt> if qgroup is disabled. I am assuming that this is a harmless message and that the new systemd version is running some qgroup command on mountpoints. I did a test myself and running
# btrfs qgroup show /
will indeed produce the same warning in my logs.
I was just wondering if others are experience the same warning message and perhaps have any other insights.
Offline
I'm seeing the same thing, guessing it has something to do with
systemd-tmpfiles learned two new line types "q" and "Q" that
operate like "v", but also set up a basic btrfs quota
hierarchy when used on a btrfs file system with quota
...but I haven't had time to look at it.
Offline
Looks like that is the case, with debug I see
systemd-tmpfiles[572]: Running create action for entry Q /home
systemd-tmpfiles[572]: Found existing directory "/home".
systemd-tmpfiles[572]: Couldn't adjust quota for subvolume "/home" because quota support is disabled: Protocol not available
systemd-tmpfiles[572]: Running remove action for entry Q /home
kernel: BTRFS: could not find root 8
Offline
It does indeed seem to be perfectly harmless and just a result of the new update to systemd-tmpfiles. Upstream might want to know about this since it should probably not result such warnings when btrfs qgroups are not enabled on a mountpoint. I am low on time this week, but I can see if I can squeeze in time for it later this week if nobody else wants to do it.
Offline
This bug/issue does now also seem to be in the core repo.
Offline
You can get rid of the messages by enabling quotas on your subvolumes. It is not a 'real' fix but the messages go away.
Last edited by ChrisG (2015-12-02 03:57:31)
Signature Geek - This is where you learn.
Offline
You can get rid of the messages by enabling quotas on your subvolumes. It is not a 'real' fix but the messages go away.
You do NOT want to do this. Quotas are being extensively reworked at the moment (see the btrfs mailing list) so they are in no sense mature. Let a proper fix come from systemd upstream since there seems to be no harm in the warnings.
Linux User #353 - SLS -> Slackware -> Red Hat -> Mandrake -> Fedora -> Arch
Offline
ChrisG wrote:You can get rid of the messages by enabling quotas on your subvolumes. It is not a 'real' fix but the messages go away.
You do NOT want to do this. Quotas are being extensively reworked at the moment (see the btrfs mailing list) so they are in no sense mature. Let a proper fix come from systemd upstream since there seems to be no harm in the warnings.
Do you have an example of how enabling quotas is harmful? Thank you.
Signature Geek - This is where you learn.
Offline
Not necessarily harmful, but not warranted to work around this message. See the BTRFS mailing list thread concerning the issue. Note in that thread that one of the list regulars (post by Duncan) does not consider quotas to be stable given the recent rework, and would not consider them so until about kernel 4.5. The post by Qu Wenruo (BTRFS dev) implies the qgroup ioctl API is not adequately complete.
My take is that while quotas are likely to be usable (have working backups!), turning on quotas to eliminate this warning message is most unwise.
Linux User #353 - SLS -> Slackware -> Red Hat -> Mandrake -> Fedora -> Arch
Offline
Not necessarily harmful, but not warranted to work around this message. See the BTRFS mailing list thread concerning the issue. Note in that thread that one of the list regulars (post by Duncan) does not consider quotas to be stable given the recent rework, and would not consider them so until about kernel 4.5. The post by Qu Wenruo (BTRFS dev) implies the qgroup ioctl API is not adequately complete.
My take is that while quotas are likely to be usable (have working backups!), turning on quotas to eliminate this warning message is most unwise.
That seems reasonable. I'm excited for it.
Signature Geek - This is where you learn.
Offline
Pages: 1