[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Sid Systemd upgrade



On Mon, 21 Jul 2014 22:54:42 -0400
The Wanderer <wanderer@fastmail.fm> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 07/21/2014 06:46 PM, Michael Biebl wrote:
> 
> > Am 22.07.2014 00:21, schrieb Joe:
> > 
> >> So I plugged in the drive, and suddenly it all burst into life.
> >> Well, nearly all, no networking, which is a bit limiting for a
> >> workstation...
> >> 
> >> This drive has its own fstab entries by UUID, as it often gets
> >> plugged into this desktop. My assumption is that failing to find
> >> the drive present had blocked proper startup. Once it was mostly
> >> going, I commented out the fstab entries, along with the network
> >> mounts, unplugged the drive, rebooted, and it has reached the point
> >> where I can post this. At least, I'm assuming it will post when I
> >> press this...
> > 
> > I assume this partition on the removable drive is not marked
> > "noauto" or "nofail"
> > 
> > Since systemd can't know which mount points are essential for your 
> > system to come up properly, the default is to drop you into a
> > rescue shell if the devices do not show up during boot (the timeout
> > is 90 secs).
> 
> What does sysvinit do in this case? Just continue trying to boot even
> if one or more of the non-'noauto'-type mount entries fails? (I
> presume it does something different from what you describe for
> systemd, or else this would not be new behavior and Joe wouldn't have
> been surprised by it.)
> 

Yes, these drive entries have been in place for probably more than a
year, they just caused warnings in the boot logs previously.

It's no big deal, Michael has indicated how to restore them, and I can
live without them for a while. I have backup scripts which involve this
drive, which makes it nice to know where it gets mounted, not just on
some arbitrary /usbX.

The next issue is the kernel panic on shutdown, and the resulting
fsck-ing on boot. /, /usr and /var are all starting up non-clean, which
is a little worrying. What is it which routinely writes to /usr? I
thought it was possible to mount /usr read-only, not that I've ever
done so. More concerning is the message during boot:

systemd[1]: /usr appears to be on its own filesytem and is not already
mounted. This is not a supported setup. Some things will probably break
(sometimes even silently) in mysterious ways. Consult
http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken for
more information.

Unfortunately, the URL doesn't work, but no doubt I can find
information about this. I can't be the first...

-- 
Joe


Reply to: