Dear Michael Biebl, you wrote:
> The verbose debug log from the initramfs and systemd can maybe tell us
> more. But looking at https://www.icce.rug.nl/systemd/journalctl, the
> sda5 mount happens at line 773, the first errors start at line 785 and
> the remount is at line 802.
> So it looks like /usr is not mounted at the time
> systemd-remount-fs.service is run.
Right. That's consistent with the impression I got from the error messages.
*Why* that is true, however, eludes me.
>
> What's also curious is, that the log doesn't seem to be complete.
> Usually systemd's first log line is something like
>
> > Dez 18 07:03:47 pluto systemd[1]: systemd 228 running in system mode. (+PAM
> > +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
> > +GCRYPT +GNUTLS +ACL +X
> > Dez 18 07:03:47 pluto systemd[1]: Detected architecture x86-64.
>
> Those early boot messages seem to be missing completely.
Well, I didn't edit anything. The information I generated is passed to you the
way it was made available by the various programs/commands.
> Btw, you mentioned that this happened after an upgrade. Which previous
> version did you run which worked fine? Which other packages were
> upgraded along with it?
Is there a way to determine that? What I do to upgrade the system is run
'aptitude update' and then 'aptitude upgrade'. Is there a log somewhere that
tells me what packages and versions were updated at what moments in time?
> If you downgrade systemd/udev, does the problem go away?
I thought about doing that, but was afraid for an avalanche of forced
downgrades of packages that might now depend on the most recent udev and
systemd versions. But I'll give it a try asap and let you know the results.
--
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
