Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2016-01-28 Thread Michael Biebl
Hi Brian Am 22.01.2016 um 04:52 schrieb Brian May: > Brian May writes: > >> Oh, except I note that you used /dev/sdb1 and/dev/sdb2 on the same >> harddisk. I used seperate harddisks for both. Wonder if that matters? > > I had a look again at reproducing this on a KVM, in

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2016-01-28 Thread Michael Biebl
Am 28.01.2016 um 23:11 schrieb Brian May: > Michael Biebl writes: > >> That sounded like you can no longer reproduce the issue with testing. > > Sorry, will try to clarify what I meant. > > I tried to reproduce the problem inside a VM, but I couldn't reproduce > the problem

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2016-01-28 Thread Michael Biebl
Am 28.01.2016 um 20:46 schrieb Brian May: > Michael Biebl writes: > >> Is this still reproducible with (systemd v215 from) jessie? >> >> Should we close the bug report until/unless we have a proper way to >> reprodce the issue? > > The problem first started with Jessie. As I

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2016-01-28 Thread Brian May
Michael Biebl writes: > That sounded like you can no longer reproduce the issue with testing. Sorry, will try to clarify what I meant. I tried to reproduce the problem inside a VM, but I couldn't reproduce the problem inside the VM. The problem still occurs on my physical

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2016-01-28 Thread Brian May
Michael Biebl writes: > Is this still reproducible with (systemd v215 from) jessie? > > Should we close the bug report until/unless we have a proper way to > reprodce the issue? The problem first started with Jessie. As I have said I can still reproduce this on testing. I have

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2016-01-21 Thread Brian May
Brian May writes: > Oh, except I note that you used /dev/sdb1 and/dev/sdb2 on the same > harddisk. I used seperate harddisks for both. Wonder if that matters? I had a look again at reproducing this on a KVM, in Debian testing. I used separate harddisks for both. However, unable

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2015-12-03 Thread Martin Pitt
Martin Pitt [2015-12-03 9:33 +0100]: > I tested this with the attached script *cough* -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) btrfs-raid1.sh Description: Bourne shell script

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2015-12-03 Thread Martin Pitt
Hey Brian, Martin Pitt [2015-11-29 0:56 +0100]: > | P: > /devices/pci:00/:00:1f.2/ata3/host2/target2:0:0/2:0:0:0/block/sdb/sdb1 > | E: ID_FS_UUID=f77d6ce8-12bf-476a-8276-2031ce3e3c42 > | E: ID_BTRFS_READY=1 > | > | P: >

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2015-12-03 Thread Brian May
Martin Pitt writes: > I tested this with the attached script (in two variants), and I don't > see anything generally wrong with it; sure, the two devices have the > exact same UUID thus the symlink will randomly point to one or the > other, but both of my devices have

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2015-11-28 Thread Martin Pitt
Michael Biebl [2015-11-01 2:57 +0100]: > So, I'm not sure if this a problem of the systemd btrfs builtin doing > something stupid or if it's a kernel/btrfs bug. Just FTR, it's not generally broken. I (and also some of my colleagues) have used btrfs for a long time, with systemd versions 44 to

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2015-11-28 Thread Martin Pitt
Hello Brian, Brian May [2015-11-01 10:36 +1100]: > Brian May writes: > >> Can you boot with systemd.log_level=debug on the kernel command line and > >> attach the output of journalctl -alb. > >> > >> The output of udevadm info -e might be helpful as well. > > > > Have a vague

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2015-11-28 Thread Brian May
Martin Pitt writes: > It's indeed very likely that this is due to the "mirrored" mode and > both partitions have the same UUID. I guess this confuses the kernel > driver and/or udev somehow? Perhaps annoyingly, somedays it boots every time. Then I get a day when it wont boot

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2015-11-21 Thread Brian May
Brian May writes: > What I will do is try to reproduce in a KVM, and if that fails, upgrade > to testing (it doesn't really matter if I break this computer and in > actual fact you could argue it is already broken anyway). I just upgraded to testing. Looks like it has exactly

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2015-11-05 Thread Brian May
Michael Biebl writes: > Maybe you reproduce the problem in a throwaway VM, which can easily be > upgraded? I will try... However I suspect this might require a combination of real hardware to reproduce. e.g. maybe these hard disks really are a bit slow to wake up when first

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2015-11-02 Thread Michael Biebl
Am 01.11.2015 um 08:41 schrieb Brian May: > Michael Biebl writes: > >> It might be worth a try to test with the lastest systemd version (v227) >> from unstable and if the problem is reproducible, file the but upstream. > > Can I do this on a stable system? It should be

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2015-11-01 Thread Brian May
Michael Biebl writes: > It might be worth a try to test with the lastest systemd version (v227) > from unstable and if the problem is reproducible, file the but upstream. Can I do this on a stable system? I had a look at backporting systemd from unstable for stable, however

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2015-10-31 Thread Brian May
Michael Biebl writes: > Can you attach your /etc/fstab please. UUID=1308477f-22a4-48d7-9b82-8ff29e115234 / ext4 errors=remount-ro 0 1 UUID=AC4D-F9EE /boot/efi vfatdefaults0 1 /dev/sr0/media/cdrom0 udf,iso9660

Processed: Re: Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2015-10-31 Thread Debian Bug Tracking System
Processing control commands: > tags -1 + moreinfo Bug #803531 [systemd] systemd: timeout mounting /home (btrfs) at boot Added tag(s) moreinfo. -- 803531: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803531 Debian Bug Tracking System Contact ow...@bugs.debian.org with probl

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2015-10-31 Thread Michael Biebl
Am 01.11.2015 um 00:36 schrieb Brian May: > Brian May writes: >>> Can you boot with systemd.log_level=debug on the kernel command line and >>> attach the output of journalctl -alb. >>> >>> The output of udevadm info -e might be helpful as well. >> >> Have a vague feeling I may

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2015-10-31 Thread Brian May
Michael Biebl writes: > That's most likely, why the device is not considered ready by > udev/systemd, so no mount attempt is made. Ok. That makes sense. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=74020 Sure this bug is the one you wanted to point me to? "Spontaneous

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2015-10-31 Thread Michael Biebl
Am 01.11.2015 um 02:09 schrieb Brian May: > Michael Biebl writes: > >> That's most likely, why the device is not considered ready by >> udev/systemd, so no mount attempt is made. > > Ok. That makes sense. > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=74020 > > Sure

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2015-10-31 Thread Michael Biebl
Am 01.11.2015 um 02:09 schrieb Brian May: > Michael Biebl writes: > >> That's most likely, why the device is not considered ready by >> udev/systemd, so no mount attempt is made. > > Ok. That makes sense. > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=74020 > > Sure

Bug#803531: systemd: timeout mounting /home (btrfs) at boot

2015-10-30 Thread Brian May
Package: systemd Version: 215-17+deb8u2 Severity: important When my computer boots, it times out trying to mount /dev/sdc1 to /home. That is it takes more then 90 seconds. Yet when I run "mount -a" by hand it takes a maximum of 2 seconds. If I keep rebooting the computer by hand, eventually it