ZFS Frequent "zfs:zroot/ROOT/default failed with error 5"

thierry@

thierry@

Developer
Hello,

On a laptop running FreeBSD 16-Current, boot is often halted with the messages:

kernel: zfs: NOTICE: Cannot find the pool label for 'zroot'
kernel: Mounting from zfs:zroot/ROOT/default failed with error 5.

kernel: Loader variables:
kernel: vfs.root.mountfrom=zfs:zroot/ROOT/default

Then I enter in the "Manual root filesystem specification:" dialog
<fstype>:<device> [options]
Mount <device> using filesystem <fstype>
and with the specified (optional) option list.

eg. ufs:/dev/da0s1a
zfs:zroot/ROOT/default
cd9660:/dev/cd0 ro
(which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)

? List valid disk boot devices
. Yield 1 second (for background tasks)
<empty line> Abort manual input

"?" does not list anything, "." does not help, nor entering "zfs:zroot/ROOT/default"

After rebooting in single user mode, `fsck -p' reports:
/dev/gpt/efiboot0: 6 files, 255 MiB free (521542 clusters)
FIXED
/dev/gpt/efiboot0: MARKING FILE SYSTEM CLEAN

Hopefully It's not systematic, but quiet frequent. This is a NVMe drive: is it dying?
 
thierry@ said:
FreeBSD 16-Current
Click to expand...
Obligatory mention.

DutchDaemon

Thread 'Topics about unsupported FreeBSD versions'

The FreeBSD Forums cater primarily to end-users and systems administrators. As such, the Forums focus almost exclusively on FreeBSD versions that are officially supported according to the official FreeBSD website. Since resources are scarce, the FreeBSD Forums strongly suggest that anyone asking questions on the forums run one of the officially supported versions (see the links at the end of this post), for which the installed user base is logically the broadest.

In terms of 'unsupported versions' we make the following distinction:

  1. FreeBSD versions that are...
  • Thanks
  • Like
 
I find it interesting that something was fixed on the efi partition, the implication seems to be that when efi was corrupted/unclean it was not visible as a bootable partitition.
Is that a loader issue?
Was the EFI partition automatically mounted on normal system boot? If so is there a path that on shutdown it becomes unclean?
I think a way to test the last theory would be to ensure that the efi partition is NOT automatically mounted in /etc/fstab and then play the "reboot until it fails or I'm comfortable" game.

But it looks like rebooting into single user mode actually gets to a point where something is mounted?
 
I did not add it in the original message, but smartctl is OK, nvmecontrol selftest is OK, and once the machine has booted, everything is fine and I don't see any signs of disc weakness.

But there's a chance the problem will come back the next time the system starts up
 
In /etc/fstab there is:

# Device Mountpoint FStype Options Dump Pass#
/dev/gpt/efiboot0 /boot/efi msdosfs rw 2 2

The problem arises even after a clean shutdown.

I've just noticed this message in /var/log/messages:
pid 147 (zpool_find_import) is attempting to use unsafe AIO requests - not logging anymore
ZFS WARNING: Unable to attach to nda0p1.
but this is just a warning, and the process continue after that.
 
I would add "noauto" to the entry in /etc/fstab (this is personal preference, the efi partition really does not need to be always mounted, just when it's being updated).

nda0p1, is that ZFS or the EFI?
maybe output of gpart list?
 
You're right, I'll add noauto.
Remark: it has been produced by the installer, and I did not change it myself.

nda0p1 is efiboot0.

# gpart list
Geom name: nda0
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 2000409223
first: 40
entries: 128
scheme: GPT
Providers:
1. Name: nda0p1
Mediasize: 272629760 (260M)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 20480
Mode: r1w1e2
efimedia: HD(1,GPT,1a1c4c97-876d-11f1-8783-74d4ddd549e7,0x28,0x82000)
rawuuid: 1a1c4c97-876d-11f1-8783-74d4ddd549e7
rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b
label: efiboot0
length: 272629760
offset: 20480
type: efi
index: 1
end: 532519
start: 40
2. Name: nda0p2
Mediasize: 524288 (512K)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 272650240
Mode: r0w0e0
efimedia: HD(2,GPT,1a215fca-876d-11f1-8783-74d4ddd549e7,0x82028,0x400)
rawuuid: 1a215fca-876d-11f1-8783-74d4ddd549e7
rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
label: gptboot0
length: 524288
offset: 272650240
type: freebsd-boot
index: 2
end: 533543
start: 532520
3. Name: nda0p3
Mediasize: 68719476736 (64G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 273678336
Mode: r1w1e0
efimedia: HD(3,GPT,1a29b74a-876d-11f1-8783-74d4ddd549e7,0x82800,0x8000000)
rawuuid: 1a29b74a-876d-11f1-8783-74d4ddd549e7
rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
label: swap0
length: 68719476736
offset: 273678336
type: freebsd-swap
index: 3
end: 134752255
start: 534528
4. Name: nda0p4
Mediasize: 955216035840 (890G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 68993155072
Mode: r1w1e1
efimedia: HD(4,GPT,1a2fdfed-876d-11f1-8783-74d4ddd549e7,0x8082800,0x6f33a800)
rawuuid: 1a2fdfed-876d-11f1-8783-74d4ddd549e7
rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
label: zfs0
length: 955216035840
offset: 68993155072
type: freebsd-zfs
index: 4
end: 2000408575
start: 134752256
Consumers:
1. Name: nda0
Mediasize: 1024209543168 (954G)
Sectorsize: 512
Mode: r3w3e6
 
Thanks, I can understand the installer adding it but don't understand installer not including "noauto".
This is complete speculation on my part, but msdosfs I think is less robust with unclean shutdowns (I could be completely wrong, so take it as my opinion).
If we start there, automatically mounting it may expose it to more unclean shutdowns, which get it marked dirty, then loader can't figure it out. That would be my hypothesis, then see if we can figure out how to test it (reboot cycles?)
The "unsafe AIO requests" against msdosfs may be a clue (does/should msdosfs support AIO requests?)

So that's all I've got. A bunch of speculation that if I look at it side-eyed with a beer, makes sense. But I have no way to test and figure out the truth of it.
 
I was unable to boot when my zroot pool didn't have bootfs property set.

To check the property's value.

$ zpool get bootfs zroot

To set the value.

# zpool set bootfs=zroot/ROOT/default zroot

zpoolprops(7)
Code: 
     bootfs=(unset)|pool[/dataset]
             Identifies the default bootable dataset for the root pool.  This
             property is expected to be set mainly by the installation and
             upgrade programs.  Not all Linux distribution boot processes use
             the bootfs property.
 
2 things comes into mind.

  1. The 5th field (dump) for ESP in /etc/fstab has value 2, causing error on dropping archive flag for any of files / directories in ESP.
  2. Possibility that setting any of read-incompatible flag that installed bootcode / loader doesn't yet (sanely) supporting.
If 1. matters, modifying last 2 fields from 2 2 to 0 0 could help. But if it helps, it would mean something wrong in msdosfs codes.

If 2. matters, forgotton upgrades of bootcode in ESP (actually whichever loader.efi or boot1.efi regardless its filename) or issue in the bootcode.

Note that I intentionally call boot1.efi and/or loader.efi in ESP to distinguish the one in /boot/loader.efi.
 
T-Aoki said:
2 things comes into mind.

  1. The 5th field (dump) for ESP in /etc/fstab has value 2, causing error on dropping archive flag for any of files / directories in ESP.
  2. Possibility that setting any of read-incompatible flag that installed bootcode / loader doesn't yet (sanely) supporting.
If 1. matters, modifying last 2 fields from 2 2 to 0 0 could help. But if it helps, it would mean something wrong in msdosfs codes.

If 2. matters, forgotton upgrades of bootcode in ESP (actually whichever loader.efi or boot1.efi regardless its filename) or issue in the bootcode.

Note that I intentionally call boot1.efi and/or loader.efi in ESP to distinguish the one in /boot/loader.efi.
Click to expand...
OK, thanks for your help: I'll check it!
 
You must log in or register to reply here.
Back
Top