PMG boot failure: can't find zpool "rpool"

S

SomeNewUser

New Member
Sep 12, 2026
7
0
1
Kernel: 7.0.14-15-pve #1 SMP PREEMPT_DYNAMIC PMX 7.0.14-15 (2026-08-26T14:21Z) x86_64
pmgversion: pmg-api/9.1.2/42245585286a (running kernel: 7.0.14-15-pve)

After recent package upgrades (today) to a PMG install, a reboot results in failure to locate zfs "zroot" fileystem.

I tried booting the the previous working kernel, but the same problem appeared.


From console, boot gets dumped to (initramfs) prompt. Info on console around that point:


Code: 
Begin: Importing ZFS root pool 'rpool' ... Begin :Importing pool 'rpool' using defaults ... Failure: 1

Failure: 1



Command: /usr/sbin/zpool import -N 'rpool'

Messages: cannot import rpool': no such pool available

Error: 1



Failed to import pool 'rpool'

Manually import the pool and exit



Buzybox (text)

(initramfs)


From here, I am able to: (as a diagnostic step)

Code: 
(initramfs) zpool import -d /dev/....path.to.partition.with.zroot



Code: 
pool: rpool
id: [0-9]+
state: ONLINE
action: The pool can be imported using its name or numeric idetifier.
config:
rpool ONLINE
disk/by-id/name-here ONLINE

(it is not needed. I could have typed "zpool import -N rpool" and "exit")


Code: 
(initramfs) zpool import -N rpool
(initramfs) exit

Boot resumes, and services start, web interface is available.
This happens reliably on each boot.
Initially, "zpool upgrade" showed several features were available.

As a diagnostic step, I enabled these features in the pool and rebooted, but the same problem appeared and the same manual import "worked" to get PMG booted.

After boot, "apt update ; apt upgrade" shows nothing new available.

Suggestions?
 
May be @SomeNewUser you show us your real hardware and the Disks?
SSD no QLC and HDD no SLC Drives.
ZFS run on my servers as ZFS Raid 1 - Mirror with on minimum 2 disks.
Example I setup a ZFS Mirror SSDs disk for only the rpool and the proxmox ve system.
for the vm and data i setup a second ZFS Pool dpool with different parameter and sizes.

Proxmox VE Backups of LXC and VM are 'good' located on a other Proxmox Backup Server (BS), that 'must' use SSDs for the Datastorrage!
 
news said:
May be @SomeNewUser you show us your real hardware and the Disks?
SSD no QLC and HDD no SLC Drives.
ZFS run on my servers as ZFS Raid 1 - Mirror with on minimum 2 disks.
Example I setup a ZFS Mirror SSDs disk for only the rpool and the proxmox ve system.
for the vm and data i setup a second ZFS Pool dpool with different parameter and sizes.

Proxmox VE Backups of LXC and VM are 'good' located on a other Proxmox Backup Server (BS), that 'must' use SSDs for the Datastorrage!
Click to expand...
PMG mentioned runs as a VM on PVE 9.2.11 host.
Did you want hardware settings for the VM on the PVE where PMG is running?
 
Onslow said:
Welcome, @SomeNewUser

Don't use apt upgrade .
Use apt full-upgrade
:)
Click to expand...
I used this to inspect installed packages (dpkg -l) and review for possible older versions of the "same" package. I found 2, removed them, re-issued "update-initramfs -u" but problem on boot persists.
(I'm assuming that is where you were going with your suggestion: possible old packages not having been removed.)
 
Last edited:
An update on progress (diagnostic step which bypasses the problem, but is not a fix):

An edit to: "/etc/default/zfs"
to append:

Code: 
# FIXME: test adding:
ZFS_INITRD_PRE_MOUNTROOT_SLEEP='5'
ZFS_INITRD_POST_MODPROBE_SLEEP='5'

Then running :

Code: 
update-initramfs -u

and rebooting did not help.

However, an edit to: "/etc/default/zfs"
and change these to to 20:

Code: 
ZFS_INITRD_PRE_MOUNTROOT_SLEEP='20'
ZFS_INITRD_POST_MODPROBE_SLEEP='20'

Then running :

Code: 
update-initramfs -u

and reboot, and after the two 20 second pauses, the boot works without manual intervention.

Maybe a recent change to PVE has changed this, to break boot of PMG.

Hopefully, this helps with suggestions for cause. This delay is not a fix, but a work-around and provides usefal diagnostic data:
There appears to be a timing issue on boot not seen before, where zfs/zpool are not immediately available to the booting kernel/system, but after some delay, become available.

I'd rather have a faster boot (like before this problem appeared.) Do you have any suggestions which could cause zfs/zpool discovery/availability to be delayed after updates?
 
Last edited:
Update on work-around:

Only changes to "/etc/default/zfs" reduced to:

Code: 
ZFS_INITRD_POST_MODPROBE_SLEEP='10'

and not including "ZFS_INITRD_PRE_MOUNTROOT_SLEEP"

then running:

Code: 
update-initramfs -u

After that rebooting seems to be the "optimal minimum" time delay with 3 out of 3 boot tests.

Setting to "9" seconds or less, and manual intervention is required or boot is blocked on 3 out of 3 boot tests.

So, down from an added 40 seconds wait on each reboot to 10 seconds of added wait time.
Not a fix, just a work-around.

Any suggestions for a fix so no delay/sleep is required?

Thanks!
 
the delay seems to be required for your disks to become (fully) visible..
 
fabian said:
the delay seems to be required for your disks to become (fully) visible..
Click to expand...
The evidence provided above supports that, but for several months, no delay has been required. Now, a minimum of 10 seconds is needed.
Maybe an update to the Promox VE that contains the VM which runs the Proxmox Mail Gateway has changed availability of disks to booting kernels int he PMG VM.
 
You must log in or register to reply here.
Top Bottom
Back