On Tue 10 Jan 2017 at 20:08:10 (+0100), Steffen Dettmer wrote: > On Sun, Jan 8, 2017 at 7:45 PM, Joe <j...@jretrading.com> wrote: > >> What happened before: > >> I had issue with a Debian server SATA bus [1]. I noticed because > >> apt-get upgrade hung, because initramfs updater calls "sync" which > >> hang because of [1]. All operations accessing a certain (backup) disk > >> blocked. Shutdown over network. It was reported server power LED still > >> up, so probably shutdown hang, too. Server was powered off and disk > >> pulled. > > > > The disc you removed: did it have an entry in /etc/fstab? Does this > > server use systemd? If yes to both, comment the /etc/fstab entry or > > give it an extra option 'noauto'. > > In short: yes, this was the problem. I didn't found this first because > there was no easily visible error message. > > Thanks you for your help! > > Do you - or anyone - know how to mount a disk at boot without > failing when it is not there? Like normal "classic" behavior? > Of course I can write a simple script if I somehow manage > systemd to execute it. In the old days there was some rc.local, > surely I find something like this. I just wonder what to put > into fstab that script detects as to be mounted without > systemd aborting when it is missing (without patching > systemd of course)
I thought I had pointed it out to you already: Similarly, both man fstab and man mount could benefit from more gloss on (no)auto and nofail. Compare the terse "nofail" entry with the following one on "relatime" which discusses kernel versions. How essential it was to read §5.6.1 in jessie's release notes! §5.6.1 says: 'If it fails to mount an "auto" mount (without the "nofail" option), systemd will drop to an emergency shell rather than continuing the boot. 'We recommend that all removable or "optional" mount points (e.g. non-critical network drives) listed in /etc/fstab either have the "noauto" or the "nofail" option.' > The removed USB disk had an entry in fstab, [...] > (an error message about missing > firmware was also present in journal and I assumed it would be the real > problem, but this message seems to be normal). > So my problem was that systemd makes a wrong assumption, > This worked well before systemd when some init script just started > "fsck [...] I can see that a post-mortem of what went wrong is useful, but I can't understand why you say that systemd made the "wrong" assumption. If you specify something wrongly, you can't really expect it to do what you want it to do, or what sysv chanced to do, just to match your own assumptions. Similarly, missing firmware is only "normal" in that so long as you don't depend on the functionality provided by that firmware, you'll be all right. Cheers, David.
