journalctl --list-boots do not show the correct _BOOT_ID (Bengt Gördén)
---------- Forwarded message ---------- From: "Bengt Gördén" <bengan@bag.org> To: factory@lists.opensuse.org Cc: Bcc: Date: Mon, 28 Nov 2022 15:34:44 +0100 Subject: journalctl --list-boots do not show the correct _BOOT_ID I've got a problem with crashing computer since a couple of weeks and needs to check logs. journalctl --list-boots doesn't show the right _BOOT_ID. Is this a known problem? I couldn't find anything in bugzilla.
time is UTC+1
@Bengt: I just ran that command in my Leap 15.5 install that is a month or more old and got one entry, because I have been lately booting from the Super Grub2 disk to get into it. Previously I log into each of my installs once a week, so there should have been more entries. # journalctl --list-boots 0 f5339494adda41508d8cf2f7536ba6dd Mon 2022-11-28 08:13:14 PST—Mon 2022-11-28> After a recent zypper in Leap 15.5 a problem with the GUI freezing developed and I filed a bug report on that one . . . so far no crashes. What might be more relevant is that week or so back I ran a zypper in my TW install which had a "grub2" package and letting that go through it seemed to break my grub menu, removing the 7 other distros I had up until then AND it seemed to change the UUID numbers of the non-TW installs (which may relate to your issue?). At that point only TW was showing up to boot, I tried to #update-bootloader but that then removed all of the menu entries. Have another bug report filed on that one. https://bugzilla.suse.com/show_bug.cgi?id=1205772
On 2022-11-28 20:30, Fritz Hudnut wrote:
@Bengt:
I just ran that command in my Leap 15.5 install that is a month or more old and got one entry, because I have been lately booting from the Super Grub2 disk to get into it. Previously I log into each of my installs once a week, so there should have been more entries.
I think my problem needs to be reported to upstream of systemd/journalctl. After doing some more research, I've come to the conclusion that journalctl is a pretty crappy piece of software. How can a software that is so involved in debugging have so many bugs in it??? Anyway. If you have many files in /var/log/journal/*. Run journalctl --list-boots on all of them (individually). Ex. for i in `ls -1art system*`;do journalctl --file $i --list-boots;done Also do this (beware that this can take some time) journalctl --verify I also found a bug that probably fits my problem. https://github.com/systemd/systemd/issues/6447 -- /bengan
On Tue, Nov 29, 2022 at 2:11 PM Bengt Gördén <bengan@bag.org> wrote:
I also found a bug that probably fits my problem. https://github.com/systemd/systemd/issues/6447
It was fixed 5 years ago. Unless you imply that Leap still has a version without this fix. The quick way to test is to run journalctl from Tumbleweed directly on the /var/log/journal from Leap.
On Wednesday 30 November 2022, Bengt Gördén wrote:
On 2022-11-28 20:30, Fritz Hudnut wrote:
@Bengt:
I just ran that command in my Leap 15.5 install that is a month or more old and got one entry, because I have been lately booting from the Super Grub2 disk to get into it. Previously I log into each of my installs once a week, so there should have been more entries.
I think my problem needs to be reported to upstream of systemd/journalctl. After doing some more research, I've come to the conclusion that journalctl is a pretty crappy piece of software. How can a software that is so involved in debugging have so many bugs in it???
Anyway. If you have many files in /var/log/journal/*. Run journalctl --list-boots on all of them (individually). Ex. for i in `ls -1art system*`;do journalctl --file $i --list-boots;done
Also do this (beware that this can take some time) journalctl --verify
If you need alternate way to get an overview of past boots, I wrote a PyQt journal browser than can show a calendar view of past boots. The calendar is marked with a green dot for each boot, and a red dot for any shutdown that seems abnormal (where the journal seems truncated). See screenshots here: https://github.com/digitaltrails/jouno The calendar view takes about 30 seconds to initialise for about a 256 boots off an ssd (I shutdown my desktop each night and keep about a years worth of logs). I was actually looking for a way to watch/filter the journal and raise desktop alerts for things I was interested in (messages from things I'm working on, or from backups, or smartd, etc). But my curiosity grew a bit beyond that, so I added the Query->Calendar view. It's not widely used, it's stable enough on my desktop, but not sure how well it'd go on a busy server. Community build: https://software.opensuse.org/package/jouno Michael
I also found a bug that probably fits my problem. https://github.com/systemd/systemd/issues/6447
On 2022-11-30 04:52, Michael Hamilton wrote:
If you need alternate way to get an overview of past boots, I wrote a PyQt journal browser than can show a calendar view of past boots. The calendar is marked with a green dot for each boot, and a red dot for any shutdown that seems abnormal (where the journal seems truncated).
See screenshots here: https://github.com/digitaltrails/jouno
Thanks. Looks interesting at first glance. I installed from build.o.o but will check it out a bit more in depth later. -- /bengan
participants (4)
-
Andrei Borzenkov -
Bengt Gördén -
Fritz Hudnut -
Michael Hamilton