lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Crashed debian while installing centos chroot


From: Vadim Zeitlin
Subject: Re: [lmi] Crashed debian while installing centos chroot
Date: Thu, 3 Oct 2019 01:49:59 +0200

On Wed, 2 Oct 2019 16:26:11 +0000 Greg Chicares <address@hidden> wrote:

GC> Vadim--I post this in case you have any insight to share.

 Not really, sorry. Debian is not supposed to crash (at least if you mean a
real, earnest kernel crash), so I don't have much experience with them. The
only time it happened to me was due to bad hardware and when I reported the
bug, with the pictures of the kernel stack trace shown on the monitor, I
was immediately told that it must be due to a hardware problem because the
stack showed a perfectly normal path executing (as I was told, I didn't
redo the math myself) trillions time per day, so it would be good to have a
look at the stack to see if it shows anything less usual in your case, but
that's all I can recommend.

 Of course, looking at the kernel logs could be useful as well, but I don't
actually know where do they go by default nowadays (I still save them to
/var/log/kern.log, but it's configured explicitly here). And if they're
only handled by journalctl, they might not even be available because by
default its journal files are not even persistent. FWIW I do recommend
setting "Storage=persistent" in /etc/systemd/journald.conf to change this.


GC> [I had enabled already enabled SysReq magic:
GC>   echo "kernel.sysrq = 1" >> /etc/sysctl.d/local.conf
GC> and REISU worked, but not B. Apparently LeftAlt-SysReq works
GC> better than RightAlt-SysReq. But I eventually got B to work
GC> by holding and releasing the relevant keys repeatedly.]

 Hmm, I never use right Alt anyhow, so I never had an opportunity to test
this...

GC> Poking around, I see:
GC> 
GC> $ls -l /srv/chroot/centos7/var/lock/lock
GC> lrwxrwxrwx 1 root root 9 Oct  2 15:29 /srv/chroot/centos7/var/lock/lock -> 
/run/lock
GC> 
GC> $ls -l /run/lock/lock/lock 
GC> lrwxrwxrwx 1 root root 9 Oct  2 15:29 /run/lock/lock/lock -> /run/lock
GC> 
GC> Isn't that circular? Anyway, I seem to be okay:

 I don't know where does /run/lock/lock/lock come from. I don't have this
neither on my main system nor in the chroot (note that the link inside the
chroot points into the chroot, implicitly, of course, i.e. its actual
target is actually /src/chroot/centos7/run/lock on the main system). In
fact, I don't even have /var/lock/lock neither:

        % ls -lA /srv/chroot/centos-7.6/run/lock
        total 8
        drwxrwxr-x 2 root   54 4096 Sep 21 23:02 lockdev
        drwxr-xr-x 2 root root 4096 Sep 21 23:02 subsys


 And I also have no idea about what could have resulted in these recursive
lock directories. It would be convenient to blame the crash, of course, but
I don't see how could it be related to this neither.

 Sorry again,
VZ

Attachment: pgpXXdLXZa5YD.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]