Bug#748056: systemd: can't boot properly when unable to mount a hibernated NTFS partition

[Michael Biebl]

On Mon, 17 Nov 2014 13:14:49 +0100 intrigeri  wrote:
> Hi,
> 
> Michael Biebl wrote (03 Jul 2014 21:07:36 GMT) :
> > Am 03.07.2014 20:57, schrieb Michal Suchanek:
> >> Also candidate for big fat release note.
> 
> > Nod. I guess the recommendation here is to simply mark non-critical
> > mounts as nofail.
> > [...]
> > So maybe just documenting the fact that this needs to be done by the
> > administrator is the best way.
> 
> So, how about:
> 
> 1. retitling this bug "Document behavior on missing/faulty filesystems

I retitled the bug report.

>more prominently" (not sure if the doc should be in fstab(5)
>and/or in systemd's NEWS.Debian)

I don't think a NEWS.Debian entry would help that much. Afaik, such an
entry would only be shown on *upgrades* of systemd, not fresh
installations. It's also not really a behavioural change *in* systemd
itself, only compared to sysvinit.

Maybe adding it to README.Debian would be better.

> 2. filing a release notes bug, whose expected outcome would be
>a paragraph in the release notes that points to the aforementioned
>documentation

That has happened for the jessie release notes which had a dedicated
section about this specific issue.

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

Bug#748056: systemd: can't boot properly when unable to mount a hibernated NTFS partition

[intrigeri]

Hi,

Michael Biebl wrote (03 Jul 2014 21:07:36 GMT) :
 Am 03.07.2014 20:57, schrieb Michal Suchanek:
 Also candidate for big fat release note.

 Nod. I guess the recommendation here is to simply mark non-critical
 mounts as nofail.
 [...]
 So maybe just documenting the fact that this needs to be done by the
 administrator is the best way.

So, how about:

1. retitling this bug Document behavior on missing/faulty filesystems
   more prominently (not sure if the doc should be in fstab(5)
   and/or in systemd's NEWS.Debian)

2. filing a release notes bug, whose expected outcome would be
   a paragraph in the release notes that points to the aforementioned
   documentation

?

Cheers,
--
intrigeri


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#748056: systemd: can't boot properly when unable to mount a hibernated NTFS partition

[Michal Suchanek]

Package: systemd
Version: 204-14
Followup-For: Bug #748056

Hello,

since this is a 'feature' I expect this is still present.

I encountered this problem when one of my drive cables went loose and
the drive became inaccessible.

The drive was ad-hoc connected while placed physically outside of the
computer case so this situation is forseeable but non-fatal with
sysvinit. With systemd this renders the system non-bootable. There is no
way to boot the system other than reconnecting the drive.

I can understand that systemd does not want to automagically boot with
some filesystem in fstab failing but it can at least offer the option
when it stops the boot and requires user input anyway.

The situation was further complicated by systemd not handling multiple
consoles properly so the notices were printed and user input exected on
disconnected serial console.

Also candidate for big fat release note.

Thanks

Michal


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#748056: systemd: can't boot properly when unable to mount a hibernated NTFS partition

[Michael Biebl]

Am 03.07.2014 20:57, schrieb Michal Suchanek:
 Package: systemd
 Version: 204-14
 Followup-For: Bug #748056
 
 Hello,
 
 since this is a 'feature' I expect this is still present.
 
 I encountered this problem when one of my drive cables went loose and
 the drive became inaccessible.
 
 The drive was ad-hoc connected while placed physically outside of the
 computer case so this situation is forseeable but non-fatal with
 sysvinit. With systemd this renders the system non-bootable. There is no
 way to boot the system other than reconnecting the drive.

Well, the system does boot, but it drops you into the emergency shell
where you can inspect the problem.

I do admit though, that this doesn't help for headless servers where you
only have an SSH login.

 Also candidate for big fat release note.

Nod. I guess the recommendation here is to simply mark non-critical
mounts as nofail.

We could try to make systemd smarter and determine which file systems
are vital for a successful boot and which are not. But I fear this will
be hard to get right for all corner cases.

So maybe just documenting the fact that this needs to be done by the
administrator is the best way.


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

Bug#748056: systemd: can't boot properly when unable to mount a hibernated NTFS partition

[Michael Biebl]

Am 13.05.2014 22:57, schrieb Nikita Pichugin:
 Package: systemd
 Version: 204-10
 Severity: important
 
 Dear Maintainer,
 
 I use a dualboot machine with Debian and Windows 8. I want the windows
 partition to automount on boot, so I added it to the /etc/fstab. The problem 
 is
 that I can't boot into Debian after a shutdown (not reboot!) from Windows: all
 I get is an emergency console. I looked into the journal log and found that
 Debian couldn't mount the windows partition, because Windows was hibernated 
 (it
 turned out that Windows 8 use hybrid shutdown by default). If I turn off the
 hybrid shutdown in Windows, then everything works as expected.
 I think that unability to mount a partition shouldn't break the boot like 
 that.
 I'd expect a non-critical error or warning or something like that, but
 definitely not an emergency console.

How is systemd supposed to know, if the given partition is vital for the
system to function properly?
Continuing to boot might lead to subtle failures, data loss etc which
can be hard to debug. I personally consider it a bug, that sysvinit
continued to boot in that case.

If the partition is not vital for the system, mark it as nofail [0].

Michael

[0] man fstab
-- 
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

Bug#748056: systemd: can't boot properly when unable to mount a hibernated NTFS partition

[Nikita Pichugin]

Hello,

Thank you for pointing that out! By the way, fstab man page says that
nofail means do not report errors for this device if it does not exist,
although the HDD partition obviously always exists. I also thought that
nofail was meant to be used for things like removable devices, not for
marking vital partitions.

Well, if systemd is designed to behave like that, then this report should
be closed, of course. Thanks for your time again.


2014-05-13 19:12 GMT+00:00 Michael Biebl bi...@debian.org:

 Am 13.05.2014 22:57, schrieb Nikita Pichugin:
  Package: systemd
  Version: 204-10
  Severity: important
 
  Dear Maintainer,
 
  I use a dualboot machine with Debian and Windows 8. I want the windows
  partition to automount on boot, so I added it to the /etc/fstab. The
 problem is
  that I can't boot into Debian after a shutdown (not reboot!) from
 Windows: all
  I get is an emergency console. I looked into the journal log and found
 that
  Debian couldn't mount the windows partition, because Windows was
 hibernated (it
  turned out that Windows 8 use hybrid shutdown by default). If I turn
 off the
  hybrid shutdown in Windows, then everything works as expected.
  I think that unability to mount a partition shouldn't break the boot
 like that.
  I'd expect a non-critical error or warning or something like that, but
  definitely not an emergency console.

 How is systemd supposed to know, if the given partition is vital for the
 system to function properly?
 Continuing to boot might lead to subtle failures, data loss etc which
 can be hard to debug. I personally consider it a bug, that sysvinit
 continued to boot in that case.

 If the partition is not vital for the system, mark it as nofail [0].

 Michael

 [0] man fstab
 --
 Why is it that all of the instruments seeking intelligent life in the
 universe are pointed away from Earth?