Project

General

Profile

Actions

Bug #4793

open

spa_import_rootpool and vfs_mountroot rely on device path strings passed from GRUB

Added by Jim Klimov about 7 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
zfs - Zettabyte File System
Start date:
2014-04-22
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

A subject that I raised earlier in email, and apparently made no bug about it (can't find any): http://thr3ads.net/zfs-discuss/2012/10/2103283-Changing-rpool-device-paths-drivers

My subsequent research stalled at a non-working POC (I did not figure out the intimate details needed to form the necessary structures and mount a pool by GUID); however, I hope it can help more crafty programmers to complete the quest.

In short - ZFS stores string representations of Solaris device paths in the device/pool labels. These are saved into the pool when it is exported, as well as into /etc/zfs/zpool.cache, at least to speed up the finding of devices related to a pool. For normal pools, if there are discrepancies, such as relocated drives, the system can just query all devices by the pool's GUID and find the disks involved in a pool. Discrepancies can also be caused by hardware changes (different controllers in use, dual-boot of a physical OS vs. the same OS as a partition-backed VM, or even when a USB device is attached or removed before boot), settings changes (SATA vs. IDE on motherboard controllers), possibly by changes to the set of drivers causing different enumeration (devfsadm).

The problem is that an rpool is not a "normal pool" in this case. The GRUB bootloader has routines to find the bootfs (ultimately as a numbered reference to the dataset, like rpool/123) on a boot device (one of the disks in a possible root mirror), then it fetches the device path string from the boot device's label, and passes these as parameters to the booted kernel. In turn, the kernel tries to import exactly the device referenced by the device-path string as the initial rpool (and would probably attach its mirror parts further in the import process?) - which does make sense when a particular device is desired by an admin among the available options, perhaps in case of failed or stale "other" devices.

However, for other cases (such as intended or otherwise "explained" changes to the OS'es view of the hardware) it may rather be desired to import the pool from any device that hosts a single-disk or mirrored component of the rpool just by its GUID (possibly using the last-TXG counter as a means to identify differing devices, or preferring one with the most recent TXG). That is, GRUB should also be able to pass the selected rpool's GUID as another parameter to the kernel (which is not hard to do), and possibly a separate flag to request this behavior instead of the default one, and the kernel should interpret this data and import an rpool by GUID from any matching device or one matched by further criteria (i.e. TXG per above variants).

In particular, the popular trick with Live media (boot Live, zpool import -f -N rpool, zpool export rpool, reboot from HDD) is not very handy at least when:
  • dual-booting is used frequently for any reason, causing "hardware changes"
  • the Live media attached to the USB port causes different enumeration of controllers than would happen when there is no media on the port (happened to me with a USB HDD used for Live Media, although there were indeed no such problems on the same machine and same port later, with a USB Flash stick).

Related issues

Related to illumos gate - Bug #7119: boot should handle change in physical path to ZFS root devicesClosedJoshua M. Clulow2016-06-18

Actions
Actions #1

Updated by Andrew Stormont almost 5 years ago

  • Related to Bug #7119: boot should handle change in physical path to ZFS root devices added
Actions

Also available in: Atom PDF