Your message dated Mon, 16 Jan 2017 07:05:00 +0100
with message-id <[email protected]>
and subject line Re: Bug#829180: possible root cause identified
has caused the Debian Bug report #829180,
regarding mounts sometimes fail at boot
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
829180: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829180
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Severity: important
Package: systemd
Version: 215-17+deb8u2
Since upgrading to jessie/systemd, one particular system frequently
stops in the single-user mode password prompt during booting.
Looking at the journalctl output, I usually find that some mount has
failed with a line like this:
/dev/mapper/vg00-name device already mounted or /foo/bar/mountpoint busy
The actual mountpoint is not the same each time the error occurs.
Sometimes there is more than one filesystem that fails to mount.
The system is an NFS server but it doesn't mount any NFS shares from
other servers.
In every case where I saw this happen, the system had been shut down
cleanly before the boot.
When this occurred today, I noticed that the mountpoint was on the root
filesystem (e.g. /foo/bar/mountpoint is a directory in /) so it doesn't
appear to be waiting for any other mount.
The problem always seems to refer to LVM logical volumes.
I previously had a lot more logical volumes on this machine but I've
combined several of them into a BtrFS volume because I thought that
having too many LVs may be troublesome. Now there are 10 LVs.
It was working fine with over 50 LVs with wheezy, before systemd
Regards,
Daniel
--- End Message ---
--- Begin Message ---
Am 14.01.2017 um 15:49 schrieb Daniel Pocock:
> I've removed the file 99-btrfs.rules now and put the system in a reboot
> loop for about 45 minutes, it rebooted about 18 times without the mounts
> failing any more.
Glad you figured it out. I'm closing this bug report, see below.
> Therefore, I feel it is likely this udev file, combined with systemd
> attempting mounts much earlier, was the reason the mounts were
> intermittently failing.
>
> While I understand that systemd may not be able to identify every
> specific irregularity like this, some ideas for improvement come to mind:
>
> - when systemd finds the udev file (99-btrfs.rules was mentioned
> in the journalctl output), could it be more conservative by default
> and delay trying to mount any devices that are associated with
> udev rules like this?
>
I don't think it's systemd's business to clean up such a btrfs rules
file. This should be done by the admin who created the file. After all,
how are we supposed to decide whether the file is buggy or actually
needed. Even then, a better package to handle such a clean up would be
btrfs-tools.
Regards,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
--- End Message ---
