Clean install of 24.10.0 results in "cannot import ‘boot-pool’ : no such pool available"

TrueNAS General
1

I just grabbed the GA of Electric Eel (24.10.0) and attempted to do a clean install. I am running a Dell 740xd that has 2 256gb SSDs that I use for the boot/OS.

I had previously installed 24.04.2 on this machine with zero issues a few weeks ago and have been testing it. So I decided to do a clean install of Electic Eel now that its released.

I did a normal installation, selected my 2 SSDs and let it formate them of course. Something I noted is that Electric Eel doesnt ask about swap partitions. Install went fine, and I rebooted the machine. When it attempted to boot, GRUB comes up no issues and it attempts to boot the first entry as expected. Shortly after that, I get this error message:

cannot import ‘boot-pool’ : no such pool available

I tried installing a few times and the outcome is the same. I’ve even tried completely clearing the SSD’s by booting a Fedora Live CD and deleting all the parition info from the SSDs and then installing Electric Eel but the results are always the same.

Oddly enough, I can install 24.4.2 without any issues. Am I doing somehting wrong when attempting to install Electric Eel? I am using an HBA of course, and I’ve noticed that the drives will sometimes be in a different order (sda, one time then sdf the second). But SURELY the install isn’t referencing disks by their device name…hopefully… and is using UUID.

2

I’m having the same issue on a clean install.
Have you found a fix?

3

Fix: cannot preform a mirrored install

4

I have not found a fix. Its very very unfortunate that we can’t do a mirrored install!

I was able to install 24.04.* and then do the upgrade from the webui, but thats not ideal.

Is there a way to open a bug against not being able to do a mirrored install?

5

I just tried doing 24.04.2.3 and got the same error. Fresh install. Wonder if something changed between 24.04.2 and 24.10.0 that broke this.

6

I switched from Kingston 2 x 120 GB SSD
to Samsung 2 x 500 GB SSD and EE installed mirrored

7

Okay after some searching I found this thread: USB to SATA adaptors and SWAP space nightmare - #19 by cgfrost

The problem is the drives aren’t fully wiped when doing an install, even though the installer says it will.

I ran blkdiscard /dev/<drive> on both my mirrored drives, and on reinstall it works fine.

Hence why your switch worked, because the new drives didn’t have TrueNAS already installed.

2 Likes
8

Essentially, yes. There are phantom disc labels from a previous install somewhere on the drive that TrueNAS is interpreting as an exported boot environment.

Drives that have been formatted with previous TrueNAS versions can show exported pools in the TrueNAS UI (NAS-131890). This is typically due to obsolete filesystem labels in the boot drives still being detected by TrueNAS. The underlying bug is fixed in 24.10.0-RC.2 and newer, but these labels can remain on boot drives used with previous TrueNAS releases. Removing these labels from the boot drives requires backing up your TrueNAS configuration, reinstalling 24.10.0 fresh on the boot drives, then restoring the TrueNAS configuration.

9

This solved it for me as well. Not a great solution, more of a workaround, but it did solve the problem.

10

Any fresh .iso install of 24.10.0 should fix this issue as we’ve added functionality to clear the phantom labels before installation. No further workaround is necessary.

11

Unfortunately, I was doing a fresh install from the 24.10.0 .iso and thats where I was seeing this problem. I don’t think its actually clearing the phantom labels.

12

Same Problem, fresh install cannot import Boot-Pool.
(Disks were used before on older version)
So clearing Labels is not working.

I try´d to insert Disk into another Truenas and used Wipe there.
Still same Problem.

Its working with blkdiscard.

From installer, choose shell.
lsblk for identify drives
then blkdiscard /dev/sdx (or vdx…) -f

13

Relaying what I’ve been told, a fresh install of 24.10.0 should wipe all labels from the boot pool and prevent that error. However, if there are any other disks in the system that were used previously used to install SCALE that were not wiped (say if you had previously used a drive for a boot drive and are now using it for your apps pool) the error would appear.

If anyone feels like this doesn’t apply in their situation and you saw the error on a fresh install of 24.10.0, we’d be happy to look at a bug ticket with a debug file attached via the private file upload service (preferably one from before a workaround was applied).

14

I totally get what you are saying but its clearly not working. Heres my scenario:

I had SCALE 24.04.* installed onto the ONLY 2 SSDs in my 740xd. Both of those disks were in a pool together as I had selected both of them for the target to install SCALE when I first installed 24.04.

I ran 24.04 for a few weeks, and then when I saw 24.10.0 had been release as GA, I decided to do a clean install. I mounted the .ISO and did the install. The Installer saw the only 2 SSDs and I selected both of them for the install, just as I had done with 24.04 weeks prior. That seemed to have went fine with no errors. I rebooted the machine and GRUB came up, and booted but I was presented with error as described in the first post (cant import boot-pool).

It did not wipe the labels from the 2 SSDs I was using for 24.04. I COULD NOT get 24.10.0 to install and work correctly until I did the blkdiscard solution mentioned above.

15

Looks like another user experiencing the same here:

16

It’s possible there is an issue specific to mirrored boot pools since that seems to cover both situations, but we’d need an actual bug report and debug file to investigate what happened.

17

Oh no! I upgraded to 24.10 and now have the same “key error pool_name not found”. Clearly some error in the upgrade script?
What is the safe fix for this?

18

is there a way to fix it without doing a fresh install?

19

Not that I am aware of.

20

Man - I spent all day with this and given I am using an old r720XD the process is a bit slow switching between BIOS and UEFI, finally stumbled across this.

I resolved my issue with wiping out the problematic boot-pools with wipefs -a /dev/sdX

Did have to use BIOS too though to boot.