[yocto] systemd crashes above emergency runlevel

[Ilya Dmitrichenko]

Hi Diego,

My issue doesn't look like neither of the ones you described. It does,
however, seem to somehow relate to journald.

I have managed to rescue this by removing these two files:

/lib/systemd/system/sysinit.target.wants/systemd-journal-flush.service
/lib/systemd/system/sysinit.target.wants/systemd-journald.service

I then succesfully booted to multi-user target and noticed that
journald has started after all.

I am suspecting this could be simply something to do with the rootfs
being read-only when he tries to start, but I'll dig into it and see
what's up exactly.

One quite annoying things is that emergency shell provided by systemd
doesn't seem to echo stdin in the input mode. So basically I type a
command but cannot see what I type. Here is what it looks like:


random: nonblocking pool is initialized
Welcome to rescue mode! Type "systemctl default" or ^D to enter default mode.
Type "journalctl -xb" to view system logs. Type "systemctl reboot" to reboot.
Press Enter for maintenance(or press Control-D to continue):
sh-4.3# sh-4.3# sh-4.3# /home/root

that was me typing `pwd`, which would normally appear as:

sh-4.3#
sh-4.3# pwd
/home/root
sh-4.3#

So I'm wondering if anyone use emegency shell (emergency.target),
which is different form runlevel1.target..?


Anyhow, the whole weird thing about my issue is that it seem as if my
Beaglbone board loosing power when journald tries to start... So I am
not quite sure how to catch whatever is happening to it. I haven't
tried JTAG yet, but that lives on the same FTDI chip that the serial
console, so it's likely that JTAG gets cut-out too. I might try
tracing supply voltage rails, when I get some more time.

Any suggestions would be very welcome.

-- 
Ilya

On 5 September 2014 13:18, Diego Sueiro <diego.sueiro at gmail.com> wrote:
> Ilya,
>
> On Fri, Sep 5, 2014 at 8:45 AM, Ilya Dmitrichenko <errordeveloper at gmail.com>
> wrote:
>>
>> I have built an image form Beaglebone (white) with systemd instead of
>> sysvinit and it crashes after loading a few services. I'm suspecting
>> it's to do with getty taking over the console tty, but not quite sure.
>>
>> What I see that the serial port terminal (tried screen and
>> miniterm.py) gets disconnected and something occurs to the FTDI serial
>> port so OS X kernel doesn't see it again.
>>
>> I was able to boot with init=/bin/sh and set default.target to
>> emergency.target and from there calling `/sbin/init 1` started more
>> systemd units and then crashed the same way.
>>
>> Any ideas?
>
>
> What systemd version you are using?
>
> I have two different problems with systemd (208 - did not tested on newer
> versions yet).
>
> 1 - The boot was reaching Emergency Mode giving me this kind of message:
>
> systemd-fsck[136]: Config: Superblock last mount time (Mon Jan  6 17:54:44
> 2014,
> systemd-fsck[136]: now = Wed Jan  1 07:14:39 2014) is in the future.
> systemd-fsck[136]: Config: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
> systemd-fsck[136]: (i.e., without -a or -p options)
>
>
> This was solved by having the /etc/e2fsck.conf file with this content:
>
> [options]
> broken_system_clock = true
>
>
>
> 2 - The other issue is related with journal log files rotation. It did not
> respect the restrictions configured at journal.conf. If you have consecutive
> power cycles (without issuing linux shutdown process) the "currupted" logs
> is not going to be rotated and it time it boots a new log file is created.
> After some time the memory is full and some process cannot start because of
> this.
>
> Can you send your boot log?
>
>
>
> Regards,
>
> --
> *dS
> Diego Sueiro
>
> Administrador do Embarcados
> www.embarcados.com.br
>
> /*long live rock 'n roll*/