21.04 with mainline kernel strange random "crash" not logged

I am sure this is out of scope, but before I downgrade the kernel I would like to see if anyone can shed some light on this:

I have a Lenovo S540 IdeaPad, Ryzen 4800u. After installing clean 21.04, there were still some issues with the backlight buttons: whenever I change it, the screen becomes dark first. Minor issue. Also, on standby the battery drain is substantial (15% in 8 hours).

I read AMD has added improved Ryzen support to 5.12, so I updated to the latest non-rc: 5.12.8.

I didn’t really test 21.04, I immediately updated the kernel. Battery drain in standby is about 8% now, adjusting backlight works as expected. Bootlog only shows a few ACPI red warnings/errors.

Unfortunately, completely randomly, this happens:

  1. my screen goes black for a second, Budgie UI homescreen is shown, all my open apps are no longer open. but my panel is white instead of black.
  2. I create a screenshot but it cannot be saved anywhere, it seems /home is inaccessible.
  3. After a few seconds more, see the second screenshot. This keeps scrolling non stop until I do a hard-shutdown with physical button.

I assume this is related to me using a different kernel. It almost seems as if the (BTRFS) filesystem gets locked somehow. Not sure what triggers it.

Not sure on your specifics - but you maybe missing some firmware https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1922350

I’m waiting for this one to be resolved on my ryzen 7 series - brightness issues affects me.

Note - the above bug will only be fixed (when it comes) for the standard kernels - not the mainline.

1 Like

I think I better stick with the standard kernel of 21.04 in that case and just be a little patient until an update presents itself :slight_smile:

I first went back to the previous kernel, still had the same issue, screen flashes, Panel becomes white and no files can be read or written. I tried to open /var/log/syslog: input output error

When the journal stuff starts scrolling I can’t do much.

I did a clean 21.04 install… to my surprise that didn’t change a thing. I am going back to 20.10 now, as the issue didn’t show up with that version.

Is this because you are using btfrs? What happens if you use out of the box ext4?

I always use btrfs since 20.04. Haven’t seen this issue before. But I think I found the culprit.
By default, after installing Ubuntu-Budgie with btrfs filesystem, /swapfile is created. But since BTRFS does not allow a swapfile on a subvolume just like that (it could be snapshotted) and without CoW turned off, this will result in a warning/error and the swapfile will not be used. Most users won’t notice.

A few weeks ago I got an old Intel NUC with only 4GB RAM so I thought it would be wise to enable swap. I Googled and learned you have to create a seperate subvolume for it, mount it via fstab and apply chattr +C to disable CoW. So I did all that and it seems that system is working fine, while swapping.

I added these steps to my postinstall script that I run after a clean install, used it on my Ryzen laptop (with 16GB ram). When I used it, the issues began. Since I have cleaned up that post-install script a lot and made lots of modifications, I wasn’t sure what the issue could be. It seemed to be too low-level to be caused by my script.

Today, before switching back to 20.10 or testing ext4, I thought I simply do a quick clean install again and did not run my script → all goes fine!

Then I ran my script but omitted the swapfile commands → for over 40min now, all seems fine!

This is what I do to enable swap on btrfs:

# Temporarily mount filesystem root
sudo mount -o subvolid=5 /dev/nvme0n1p2 /mnt/system
# create a root subvolume for user personal folders in the root filesystem
sudo btrfs subvolume create /mnt/system/@swap
# Just to be sure, disable CoW for the subvolume
sudo chattr +C /mnt/system/@swap

# now umount the filesystem root
sudo umount /mnt/system

# Temporarily mount @swap and finish configuration 
sudo mkdir /swap
sudo mount -o subvol=@swap /dev/nvme0n1p2 /swap

# Configure swap file
sudo chattr +C /swap
sudo touch /swap/swapfile
sudo chattr +C /swap/swapfile
sudo chmod 600 /swap/swapfile
sudo dd if=/dev/zero of=/swap/swapfile bs=1024 count=4194304
sudo mkswap /swap/swapfile
sudo swapon /swap/swapfile

# Add mount rule to fstab
UUID=... /swap                   btrfs   defaults,noatime,subvol=@swap  0  0
/swap/swapfile none swap sw 0 0

I can verify with free -mh and it shows 4GB swap.

I will wait for a day or so, play with the laptop a bit to ensure it works fine without swap, then I will try to enable swap again with the above commands.

It is a pity Ubuntu Installer doesn’t take care of this automatically when btrfs filesystem is selected, instead creating /swapfile that is broken/doesn’t work. Subvolumes @ and @home are created by default the installer, it could create a subvolume @swap as well.

1 Like

Please do file a bug report against Ubiquity for this.

This way, the developers who are now creating the new installer are notified and can take this into account for the new installer - I’m assuming here the new installer offers btrfs as a filesystem of course.

You might also want to raise a query on the new installer github as well to see if they have immediate plans to offer btrfs - or if this is a future aspiration.

1 Like

Bad news, even after normal clean install without setting up swap myself, I get the same issue.

It is definitely BTRFS related. If I hit ESC and some other buttons and wait long enough:

Not sure how to report this as bug.

As suggested I did report the general issue with the old and the new installer regarding the creation a swapfile, but that can’t be the cause because this error happen on 20.04 and 20.10, same laptop, while installers from both prev versions also created a swapfile.

btrfs is a kernel issue

ubuntu-bug linux

Note though. Since you have reproduced this across multiple versions I feel it might just be worth double checking the health of your hard-drive. It might be failing and causing btfrs to go into read only mode trying to save your files from further corruption.