[SOLVED] ACPI BIOS Error

[SoyDodger]

Running Mint 19.3, Kernel 5.x and I've tried reverting to earlier versions, no luck.

I hadn't shut the computer down for a few days. It had run a few updates and restarted afterward just fine. This morning I started getting this message after boot:


Trying an earlier kernel gave me the following:


Followed by the ACPI stuff again, but there is also an issue of mint-vg not found:




The "mint-vg not found" part bugs me as I had this before. Did a clean install from new media, and now it's happened again. I can't get into the system so I don't know how to run fsck, or what that is. Not sure what busybox is.

_____ _____ _____ _____ _____ _____

I couldn't find much on Mint forums, except this (viewtopic.php?f=46&t=313738&p=1772615&h ... S#p1772615) but I don't think it is the same problem, it's just similar.

Looking further afield I found this:
https://www.linuxquestions.org/question ... 175605357/ where the most revealing comment said:

Just to give you some background, as you probably know, ACPI is the power regulation code in your motherboard's BIOS/UEFI:

It's suppose to be a standard that any operating system can properly implement. However, in typical Microsoft fashion, MS operating systems do not follow or properly implement the ACPI standard. Instead, MS gives motherboard manufacturers their own improperly implemented ACPI code for inclusion in the motherboard BIOS/UEFI. The code runs fine with MS windows but all for other operating systems like linux there can be problems. Because of MS's market dominance, the faulty ACPI implementation from MS has become the de facto industry standard. As a result, linux and other non-MS operating systems have to reverse engineer the faulty ACPI implementation from MS. That's why you can see problems in linux with ACPI related functionality like suspend to ram, hibernate, etc.

Apparently, the ACPI related code in certain newer linux kernels has a problem with the typical BIOS/UEFI ACPI implementation on certain motherboards which is why we're getting those error messages. Even though I get those error messages at the beginning of the boot process, I've had no problems with suspend/resume or any other ACPI related issues. Here's another guy with the same problem so you are not alone:

The advice there was to not run in BIOS legacy mode by disabling UEFI but to run in UEFI mode instead with secure boot disabled.

This device is formerly Windows 10 and I had problems with drive formatting when I swapped over to EXT4 so I thought it may be that. I went back to my Mint installation and made sure I was using UEFI with secure boot disabled and fast boot disabled. Still no go.

Any suggestions on how to fix this issue?

PS. Apologies in advance if the images are too small to be readable, it hit the site limit of 640x480.

[SoyDodger]

Couldn't wait for a solution as I needed the machine for a project. Timeshifted back two days and everything is back to normal.

I had 5 updates waiting. Two security ones and one for Skype. Applied those updates and restarted the device successfully.

Will apply the 2 system updates more cautiously, and see what difference that makes. Will post back with the results.

[Moonstone Man]

Couldn't wait for a solution...

You need to be more prepared for disasters like this one because you're using disk encryption. The people who may be able to help you are few and far between, and when they are online, they are likely to be on the opposite side of the world in a different time zone. If you use encryption, you need to be able to recover from a disaster on your own, without assuming someone can assist, and if someone does assist, there's no guarantee that they can help you recover the encrypted data, so you need to be ready to lose everything. It isn't a simple matter of 'wait for a solution', it's a highly complex problem that requires a lot of to-ing and fro-ing, sometimes over days. You got lucky this time. Next time might be different.

That said, if you need data security, use VeraCrypt containers, which can be backed up with a simple copy/paste.

sudo add-apt-repository -y ppa:unit193/encryption

[SoyDodger]

Thanks for the advice, it is appreciated. I didn't realize that the built in encryption caused that many more complexities. I will look at using Veracrypt containers instead. I had (incorrectly it seems) assumed the whole disk approach it was more direct and effective than using admin accounts and user passwords, however I have just migrated from Win10 so my general knowledge of Mint is sorely lacking.

I was not so worried about losing data, more about the ability to boot... but now I type that out it seems a bit idiotic!
In any event, I have offsite storage in the event SHTF, but it takes time to get up and running again.

I made a new Timeshift point this morning and will add the updates one at a time and test the boot sequence. Still playing catch up with work at the moment though and this involves a bit of tinkering.

[SoyDodger]

Untechnical as this solution was, I just waited a while as I had two GRUB2 updates to run. I wasn't sure which one to use, so left it a few days.

Then there was an Ubuntu update and kernel update that were released. I applied those and then the signed GRUB2 update. Everything went through smoothly. Been running on latest kernel and GRUB2 since. No issues.

Don't forget to add a Timeshift image when tinkering!