efi_check_space: Unable to expand staging area

D

drhowarddrfine

Did a package upgrade last night. Everything went fine and shutdown the computer which I rarely do. Booted up this morning to this:

a.jpg


I went into one of the boot modes but now I forgot which one and I have to leave for a few hours. The boot mode said it would boot the "active" one which seemed a logical choice at the time.

Everything is working now but I tried to do pkg upgrade and it wants to upgrade 113 packages. Doesn't sound right. I ran freebsd-update fetch and it says I'm on p6 and it wants to upgrade to p7. Unless I missed something, I thought I upgraded to p7 a couple of weeks ago but I didn't write that in ink on my hand so I could be wrong.

Sorry for the quick write up but I just got called out and have to run. Perhaps someone already knows what's going on here.
 
It's a known problem with the nvidia kernel module for some people on some installations. ~2 years ago, it caused exactly that kind of error on a lot of peoples machines. The solution is to load the nvidia kernel module via rc.conf instead of loader.conf. AFAIK there is a bug report for this, but I don't know the situation right now.
 
steps I saw that but I reinstalled this machine a year or so ago and never had an issue till now. Has something changed?

As I said, I updated all my packages but didn't pay attention to what was getting updated so if the nvidia driver changed, or something that caused this, I wouldn't know.
 
I think moving load of nvida stuff to rc.conf would be a simple/quick way of testing this.
ETA:
I don't do EFI boot, but have always loaded the nividia and i915 modules from rc.conf
 
So I took out the nvidia stuff in loader.conf. I noticed I had kld_load in rc.conf. This didn't fix anything.

Now I notice under boot options that I have 12 options from different OS versions like 13.1p5 and 13.1p6 and 13.2p1. I thought I had upgraded to 13.2 but, when I select that, I get the error at the beginning of this thread. If I select 13.1p7, everything boots up fine. So I'm wondering if I misinstalled 13.2 so many weeks ago.

I'm just blurting things out, I know. I either don't know what I'm doing or I'm too busy to think straight. No. I'm sure I don't know what I'm doing. I just slapped this zfs system together with the plan to study it better but that has never happened.
 
My understanding of this efi_check_space error is rather limited. There seems to be a limit of the amount of memory the uefi bootloader can use to load kernel modules. That is considered a bug in our uefi bootloader, but I don't know if someone is currently working on a fix (PR 251866?). When this error appeared for some users some years ago, the nvidia kernel module was always the culprit (it is rather big in size compared to other modules). Therefore it was a sensible first attempt in fixing your current problem.

Not everyone is affected by this bug, and not always at the same time. It may depend on the physical machine of a user, on a specific kernel version and patch level, on a specific pkg version, on the phase of the moon, on the one cosmic ray which caused this specific bit flip or all things at the same time.

Okay, back to solutions: can you please show the /boot/loader.conf of your 13.2p1 boot environment. Maybe we can carve out more modules from loader.conf to rc.conf.
 
Ok. Still, the only idea I have on the subject is the reduction of kernel modules you want to load at early boot through loader.conf. Can you create a new 13.2 boot environment, either through freebsd-update upgrade or install it manually (untaring the 13.2 distributionsets)? Then install and enable kernel modules one at a time and see if your machine still boots successfully?
 
You could simply boot on 13.1p6, create a new boot environment bectl create 13.2-release, and activate it bectl activate 13.2-release.
Then reboot your machine, it should boot on 13.2-release boot environment.

In this environment, remove the load of nvidia driver from /boot/loader.conf
Put it in /etc/rc.conf

Upgrade all your package with pkg, restart your computer and see if it still works.

Finally perform the upgrade to 13.2.

Normally if your boot environment are setup correctly, all your user data should not have been reverted (only installed/upgraded package between the 13.1-p6 BE creation).
 
I have a 13.2-RELEASE environment but it won't boot into it. I removed the nvidia line in loader.conf.

Right now, I can boot into 13.1p6. This morning chromium came up but I had to refresh all my open tabs, something I never had to do before.

I'm tempted to try an upgrade to 13.2 from where I'm at but prefer not to wipe my system.

There are now 12 boot environments listed.
 
The point is that you create another boot environment to attempt another upgrade, so that you can fallback to 13.1p6 if it is still broken.
 
Tried upgrading. It says to reboot and run install again but that just keeps looping over and over again to do the same thing. I now have 15 boot environments to select. Only one of them works: 13.1p7
 
drhowarddrfine said:
[...]
Right now, I can boot into 13.1p6. This morning chromium came up but I had to refresh all my open tabs, something I never had to do before.
[...]
There are now 12 boot environments listed.
Click to expand...
drhowarddrfine said:
Tried upgrading. It says to reboot and run install again but that just keeps looping over and over again to do the same thing. I now have 15 boot environments to select. Only one of them works: 13.1p7
Click to expand...
I deduce from this that you succesfully applied the patch from 13.1p6 to 13.1p7, but 13.1p6 is not present anymore as a BE; am I correct about this? I think it would be helpful (as a starting point) that you give the output of a bectl list and a freebsd-version -kru from the one BE that boots successfully. Also the message when after a reboot it says that you need to reboot again, accompanied with a freebsd-version -kru at that point.
 
bectl list
BE Active Mountpoint Space Created
13.1-RELEASE-p1_2022-09-01_042939 - - 1.19G 2022-09-01 04:29
13.1-RELEASE-p2_2022-11-02_033021 - - 1.71G 2022-11-02 03:30
13.1-RELEASE-p3_2022-11-18_172620 - - 932M 2022-11-18 17:26
13.1-RELEASE-p4_2022-12-01_063054 - - 973M 2022-12-01 06:30
13.1-RELEASE-p5_2023-02-09_034245 - - 512M 2023-02-09 03:42
13.1-RELEASE-p6_2023-02-17_043714 - - 559M 2023-02-17 04:37
13.1-RELEASE-p7_2023-04-16_075139 - - 3.01G 2023-04-16 07:51
13.1-RELEASE-p7_2023-05-18_142421 - - 474M 2023-05-18 14:24
13.1-RELEASE-p7_2023-05-21_082506 N / 110M 2023-05-21 08:25
13.1-RELEASE-p7_2023-05-21_082803 - - 108M 2023-05-21 08:28
13.1-RELEASE-p7_2023-05-21_083117 - - 320K 2023-05-21 08:31
13.1-RELEASE_2022-08-10_142208 - - 1.59G 2022-08-10 14:22
13.2-RELEASE_2023-04-16_075339 - - 3.40G 2023-04-16 07:53
13.2-RELEASE_2023-05-18_140542 - - 3.04M 2023-05-18 14:05
default R - 24.0G 2020-10-17 19:05

freebsd-version -kru
13.2-RELEASE
13.2-RELEASE
13.1-RELEASE-p7
 
Why default is still marked as active ? To me it seems like you attempt the upgrade on one BE, and then reboot in another BE and attempt to do the upgrade.

Did you make a new boot environment, activate it, then reboot, and then did the upgrade ?
If not what steps did you do ?
 
I mean the second attempt, how did you do it ?
Did you select a different boot environment to allow it to boot, and then perform the first stage of upgrading and then reboot ?

If you did that then on reboot you will be in default boot environment.

If on reboot you selected the boot environment freshly created by freebsd-update then you will be right just before the installation of the first stage.
Hence the installation loop, each times you are booting in the backup that is done by freebsd-update. That is my guess.

Since your upgrade didn't succeed, and the fact that you just don't want to wipe all of your data, strictly following the handbook will not be enough. In the handbook it is
assumed that you are in the default boot environment, which is not the case for you.

That is why I suggested to create a new boot environment (give it a distinctive name: working-be), from the boot environment that is working.
And then activate it, and reboot. Thus meeting the assumption in the handbook that you are on a default boot environment.
 
monwarez Thanks. I'll try that but it might take till tonight or tomorrow. What you describe sounds like what I have done but the initial start of this problem is a mystery to me.
 
The title here seems to be misleading, seeing how loader continues after printing those messages. Do you have other system to check (ping, ssh) if this one actually boots and simply does not output anything to the screen?
 
drhowarddrfine said:
As I said, I updated all my packages but didn't pay attention to what was getting updated so if the nvidia driver changed, or something that caused this, I wouldn't know.
Click to expand...
cat /var/log/messages | grep pkg should tell what packages where updated (deinstalled/installed) and when.
 
You must log in or register to reply here.
Back
Top