Bug 227772 - regression: gptzfsboot sees remains of old pools and fails to boot
Summary: regression: gptzfsboot sees remains of old pools and fails to boot
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 11.1-STABLE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2018-04-25 15:29 UTC by emz
Modified: 2018-04-26 22:27 UTC (History)
0 users

See Also:


Attachments
boot screen with loader stuck, initial screen (54.02 KB, image/jpeg)
2018-04-25 15:30 UTC, emz
no flags Details
boot screen with loader stuck on custom pool/kernel path (74.55 KB, image/jpeg)
2018-04-25 15:30 UTC, emz
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description emz 2018-04-25 15:29:08 UTC
Using 11.1-RELEASE I was getting the "cannot read MOS" message concering the old deleted pool (which labels for some reason persist on the new vdevs) but this didn't lead to the inability to boot.

Using recent STABLE r332095 gptzfsboot it now does.

I'm getting various messages (see attached screenshots) but the most fatal semmms to be "ZFS unexpected object set type 0", then booting process hangs, gptzfsboot seems to see the pool, but entering the pool name and path to the kernel does nothing - progress bar stucks.

The workaround is to use old 11.1 gptzfsboot loader.
Comment 1 emz 2018-04-25 15:30:11 UTC
Created attachment 192810 [details]
boot screen with loader stuck, initial screen
Comment 2 emz 2018-04-25 15:30:41 UTC
Created attachment 192811 [details]
boot screen with loader stuck on custom pool/kernel path
Comment 3 emz 2018-04-25 15:32:14 UTC
Follow-up: zfsroot is the actual live pool, esx is the old non-existent pool. gamestop is the old-non-existent pool with one device from it (it actually contain full fragment since it's the old spare disk), zroot is the old non-existent pool.