pftf
Ubuntu ACPI boot on RPi4B (4GB) after shutdown -P/-r now: "system.journal corrupted or uncleanly shut down"
NOTE: Turns out the "system.journal corrupted or uncleanly shut down" appears to be the "unknown time at boot" problem, where the system.journal file appears to have future timestamps in its information for a while because of the inaccurate time. This leads to the rejection of system.journal from what I can tell.
Still, the lack of other service shutdown notices and such probably still indicates a problem. I'm just not sure that the notice of system.journal corruption would disappear as well.
Original notes follow . . .
This might only be an FYI as things are . . .
I rebuilt a ubuntu RPi4B kernel to include ACPI support and have it booting (no microsd card involved). But I've noticed 2 points about shutdown -P now for this context: (1) It is very fast and without the normal output about shutting things down. (2) On booting the next time I get notices, such as:
[ 10.259880] systemd[1]: Started Journal Service.
[ 10.379244] systemd-journald[911]: Received client request to flush runtime journal.
[ 10.396453] systemd-journald[911]: File /var/log/journal/ac868517c77945bc934cb9e59d1f8241/system.journal corrupted or uncleanly shut down, renaming and replacing.
of course shutdown -r now also gets such. The shutdowns and later power-ons look like:
root@ubuntu:~# shutdown -P now
[ 410.866236] reboot: Power down
PM_RSTS: 0x00000575
RPi: BOOTLOADER release VERSION:c305221a DATE: Sep 3 2020 TIME: 13:11:46 BOOTMODE: 0x00000006 part: 63 BUILD_TIMESTAMP=1599135103 0x897c4fff 0x00c03111
Halt: wake: 1 power_off: 0
PM_RSTS: 0x00001000
RPi: BOOTLOADER release VERSION:c305221a DATE: Sep 3 2020 TIME: 13:11:46 BOOTMODE: 0x00000006 part: 0 BUILD_TIMESTAMP=1599135103 0x897c4fff 0x00c03111
uSD voltage 3.3V
FYI:
# cat /etc/os-release /proc/version
NAME="Ubuntu"
VERSION="21.04 (Hirsute Hippo)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu Hirsute Hippo (development branch)"
VERSION_ID="21.04"
. . .
VERSION_CODENAME=hirsute
UBUNTU_CODENAME=hirsute
Linux version 5.8.0-1015-raspi (root@ubuntu) (gcc (Ubuntu 10.2.1-19ubuntu1+aptbuild1) 10.2.1 20210206, GNU ld (GNU Binutils for Ubuntu) 2.36.1) #18 SMP PREEMPT Sun Feb 21 10:38:55 PST 2021
When I built things, I set up the system compiler/toolchain to by default tune for cortex-a72. I used v1.22 of RPI_EFI.fd . I used the RPi4B firmware that ubuntu supplied and copied /usr/lib/systemd/boot/efi/systemd-bootaa64.efi to EFI/BOOT/bootaa64.efi . I supplied a loader/entries/ubuntu.conf . My config.txt does have some performance tuning material in it.
For now, my context may be too far off from supported activities to be more than a potential forewarning. I'm not trying to indicate which "side"(s) the problem might be on, I do not have the context for making that kind of judgment.
As you note, this looks like its not doing a proper shutdown sequence (rather more like reboot -fnk). This wouldn't normally be a firmware problem. I would try ans trace something like systemctl reboot to see why systemd isn't executing its shutdown actions. There are probably various kernel/firmware knobs that might trip up systemd's understanding of UEFI.
In more recent 21.04 linux-raspi drafts, enabling ACPI via "LANG=C fakeroot debian/rules editconfigs" results in 2 check failures:
. . .
Running config-check for all configurations ...
check-config: /tmp/tmp.XvvM4JZewH/CONFIGS/arm64-config.flavour.raspi: loading config
check-config: /root/linux-raspi-5.11.0/debian.raspi/config/annotations loading annotations
check-config: /root/linux-raspi-5.11.0/debian.raspi/config/../../debian.master/config/annotations loading annotations
check-config: FAIL (n != -): CONFIG_ACPI_CUSTOM_METHOD policy<{'arm64': '-'}> mark<ENFORCED> note<override master annotations>
check-config: FAIL (n != -): CONFIG_CRYPTO_DEV_HISI_ZIP policy<{'arm64': '-'}> mark<ENFORCED> note<override master annotations>
check-config: 146/148 checks passed -- exit 1
*** ERROR: 1 config-check failures detected
So may be what I'd done to set up a RPi4B ubuntu UEFI/ACPI test was(/is) not valid but is now explicitly reported. May be a non-raspi arm64 ubuntu server build must be used.
Note: Things progressed to 5.11.0 (compared to the original report's 5.8.0 context).
Yes, generally you want to use the normal arm64 install images rather than the rpi specific ones if your running this firmware. The debian images at this point are generally functional (AFAIK) so presumably, some of that config/etc should be in ubuntu now too.