Score:0

Sudden unresponsive blue screen in ubuntu 20.04

in flag

Recently I switched from Windows 10 to Ubuntu 20.04 in my laptop. My laptop is acer nitro 5 with 16 GB ram 256 GB SSD and 1TB HDD. I installed ubuntu in my ssd. I used 500MB for efi partition, 8GB for swap partition, 125GB for root partition and 102GB for home partition. And I created two partitions of my HDD at /home/dev/Data(D) and /home/dev/Data(E) using Disks.

There was some problem in posting the log files. So I'm sharing a link to the files. (var/log/syslog, var/log/syslog.1, var/log/kern.log, var/log/kern.log.1, var/log/dmesg) The files contain the information for the time period around the crash. The crash happened somewhere around 18:30:00 and 19:05:00.

"https://drive.google.com/drive/u/3/folders/1-JZRLaAcDxVNJJLyI4vJJrFR2yqd28bV"

System Monitor SSD HDD

After a while I noticed that I do not have permission to write and delete in my HDD partitions. So I modified the permissions. Also I installed few software like google chrome, vs code, nqq, etc.

Since I have installed ubuntu the system crashes suddenly without any warning. A dim blue screen appears. The whole system stops responding. It happens anytime randomly. No warnings. So I have no choice but to shut down it forcefully using the power key. And when I restart the system it works fine. It happens once or twice in a day. I searched for the problem and I found answers that are saying that overheating can be the problem. But it only started since I switched to ubuntu. Before that everything was working fine.

Can someone help me figure out the problem? Thanks in advance.

These are my BIOS and boot settings Boot settings BIOS settings BIOS settings

I frequently get the following error. Error

There is no option for Wayland in gear symbol in the lower right purple screen when I login. options in gear symbol in the lower right purple screen when login

mondotofu avatar
cn flag
How would you feel about renaming the HDD partitions to have names that do not contain the parentheses? Perhaps the names could end with -D and -E. This could eliminate a problem with Linux semantics in using these devices.
mondotofu avatar
cn flag
If you post the complete content of /var/log/syslog, /var/log/kern.log and /var/log/dmesg then we may be able to get some insight into your latest crash.
Eric Fonsi avatar
in flag
There was some problem in posting the log files. So I'm sharing a link to the files. https://drive.google.com/drive/folders/1-JZRLaAcDxVNJJLyI4vJJrFR2yqd28bV?usp=sharing
mondotofu avatar
cn flag
Thanks for providing the latest files. In the syslog file, it's clear that data recovery was necessary on Data(D) and Data(E) drives, so there was clearly some kind of crash that necessitated that.
mondotofu avatar
cn flag
What you provided were the current files. If the last time you used the system there was a crash, the details on the crash would appear in the /var/log/syslog.1, /var/log/kern.log.1, Beyond the .1 logs in the /var/log directory, we have archived logs preserve the ending state of each time your've restarted your computer.
mondotofu avatar
cn flag
These show up as /var/log/syslog.2.gz, syslog3.gz,.... maybe as high as syslog7.gz before they are rolled off and purged. So when I asked for the syslog and kern.log files for the crash, I should have said either the /var/syslog.1 and /var/kern.log.1 files because those are the files that would hold the data we need to diagnose your problem. If it doesn't crash every time, then we need the files that correspond to the latest crash (that might mean the pair of syslog.2..gz and kern.log.2.gz files as the numbers go together). Thanks!
Eric Fonsi avatar
in flag
Thanks @mondotofu ! I have included the var/log/syslog.1 and var/log/kern.log.1 files in the link. Also I changed the drive names from Data(D) and Data(E) to simply D and E.
mondotofu avatar
cn flag
# in kernel.1.log
mondotofu avatar
cn flag
Jun 26 19:11:28 dev kernel: [ 0.000000] efi: EFI v2.60 by INSYDE Corp. Jun 26 19:11:28 dev kernel: [ 0.000000] efi: TPMFinalLog=0x89596000 ACPI 2.0=0x89d0d014 ESRT=0x88dce618 SMBIOS=0x88dca000 SMBIOS 3.0=0x88dc8000 MEMATTR=0x78d26018 RNG=0x88dc6698 TPMEventLog=0x6f6b0018 Jun 26 19:11:28 dev kernel: [ 0.000000] efi: seeding entropy pool Jun 26 19:11:28 dev kernel: [ 0.000000] random: fast init done Jun 26 19:11:28 dev kernel: [ 0.000000] secureboot: Secure boot enabled Jun 26 19:11:28 dev kernel: [ 0.000000] Kernel is locked down from EFI Secure Boot mode; see man kernel_lockdown.7
Score:0
cn flag

I think the issue relates to UEFI Secure Boot locking the kernel.

This should be correctable by entering your BIOS and turning it off.

Step 1: Boot into the system settings by powering on the system and using the manufacture’s method to access the system settings.

Step 2: Look through the menu and select UEFI as the boot mode.

Note: Many menus show UEFI and Legacy as the choices, while others may display UEFI and BIOS.

Step 3: Navigate to the Secure Boot option and turn it OFF.

Note: On some devices, you should first boot once after disabling UEFI and go back to the settings menu to disable Secure Boot.

Thanks for performing the steps to turn off UEFI Secure Boot.

Thanks also for posting your latest log files. It seems that you stayed up for a couple of days before the system shut itself down.

Now I see the reason why. You have configured your system to perform unattended upgrades.

This leads to a situation where your computer is shutdown without your interaction in order to fully apply the upgrades.

The syslog.1 file you posted tells the story in its last two lines:

Jul 11 08:40:22 dev systemd[1]: Started Login Service.
Jul 11 08:40:22 dev systemd[1]: Started Unattended Upgrades Shutdown.

Personally, I like to see what upgrades are available at boot time and not automatically turn that over to an unattended process.

I suggest you read this article and decide whether you wish to turn off unattended upgrades. It's not for everyone.

How To Disable Unattended Upgrades On Ubuntu

I think this will end unexpected outages.

OK, so it wasn't the unattended upgrades.

I see something else I'd change, and that would be to login with Wayland as your display system instead of X. It's going to be the default Ubuntu display manager in the future, anyhow.

Inside of syslog, there seem to be some errors and warnings when opening up X Windows displays. It's old and some say reliable, but it has memory leaks, and may possibly be exposing you to network threats, but Wayland has been proving its worth and Canonical has been fine-tuning it.You just have to choose it when you login.

Look for the gear symbol in the lower right purple screen when you login, and choose Wayland.

Eric Fonsi avatar
in flag
Thanks @mondotofu, Do I need to let UEFI disabled, or can I enable it again after disabling secure boot.
mondotofu avatar
cn flag
I would leave it permanently off since you don't need it to run Windows on this machine.
Eric Fonsi avatar
in flag
I turned the secure boot off. But still the problem is there. This is the link of latest log files. https://drive.google.com/drive/folders/1-JZRLaAcDxVNJJLyI4vJJrFR2yqd28bV?usp=sharing
Eric Fonsi avatar
in flag
Thanks @mondotofu. In my case the system doesn't shut down, it freezes and a dim blue unresponsive screen is displayed. And then I have no choice but to shut the system down forcefully using the power key. Will the above solution work in this case also?
mondotofu avatar
cn flag
I'm not 100% sure that it will make your problems go away, but I think stopping unwelcome interruptions that leave you hanging makes sense. You should try it.
Eric Fonsi avatar
in flag
I turned the unattended upgrades off. But still the problem is there. I added the latest log file in the above link.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.