On Thu, 22 Apr 2021 at 19:10, Reginald Beardsley via
openindiana-discuss <openindiana-discuss@openindiana.org> wrote:
> I do *not* understand why there is any justification for renaming physical
> interfaces between boots, but I had a demonstration today when a USB port was
> renamed c1t0d0p0 which had previously been c11t0d0p0.
>
> I think we have reached terminal complexity. No one understands the system
> any longer and so they randomly break things of which they are unaware.
Your consistent negative hyperbole in these threads is frankly
exhausting. We have, today, the best introspection and debugging
tools that have existed in the fifty year history of UNIX. The
software might not be doing what you want at this minute, in your
specific environment, but it absolutely can be understood and fixed.
If you want help with something, please try engaging constructively
and with some empathy for the people to whom you are sending mail.
Demonstrate that you've actually investigated your issue, rather than
opening and immediately closing with a fatalistic complaint about how
everything is broken and the project is doomed.
I don't know what happened with your USB disk having a new device
name, but I guarantee that were one to examine what the system was
doing, it would be possible to find out. In spite of the negativity,
many people have tried to help you in your endeavours in the last few
months.
On Thursday, April 22, 2021, 08:54:14 PM CDT, <li...@mcintyreweb.com> wrote:
> I think this should be OK if you run "zpool export" before unplugging the USB
> disk. I agree that this may be difficult/impossible for a boot image though
> since you can't export the rpool while the system is running ...
> > On Thursday, April 22, 2021, 03:01:03 PM CDT, Stephan Althaus
> > <stephan.alth...@duedinghausen.eu> wrote:
> > The issue is, that the zfs import routine should read the zfs labels on
> > the disks instead on insist on some device path.
> > And in these cases just see if some other disk (that is not part of a
> > successfully imported 'online' pool) has the correct zfs label for the
> > "missing" disk.
>
> I agree that this seems to be a bug, which could be filed against
> illumos/zfs. But it may be dangerous to change without a ZFS expert
> confirming there is not some other case that would break without the current
> logic. For example there might be complications for systems with multipath
> IO. In my case it was a lot easier to fix via disk plugging rather than
> learning how to edit the kernel.
>
> FWIW, deleting /etc/zfs/zpool.cache did not fix this, so the problem appears
> just by reading the paths on disk.
If the pool is the boot pool, and consists of a single vdev (i.e., not
mirrors or raid or stripes) then your situation may have improved as
of the integration of:
7119 boot should handle change in physical path to ZFS root devices
https://www.illumos.org/issues/7119
The hand-off between the boot loader and the system itself is a
complicated affair; in particular it can be hard to determine which
firmware-visible block device is equivalent to a particular OS-visible
block device. To work around this, the original design for booting
from ZFS (and similarly in the cache file mechanism for pools other
than the root pool) is that the /devices paths and devids and so on
are written in the pool label.
Until 7119 was integrated, these cached values were used uncritically
and there was no fallback if the /devices path for the root disk had
subsequently changed. After 7119, if we cannot find the root disk, we
will now attempt to scan all visible block devices looking for a
device which appears to contain the correct pool/vdev GUID (a 64-bit
ID) that the boot loader told us about, and import that instead. As
noted in the ticket this is sufficient to boot from a single disk
pool, and has enabled us to create virtual machine images that work
under a variety of hypervisors -- the OS just finds the correct path
on first boot.
I haven't personally tried, but I would hope this might make USB pools
work better as well. If not, bugs can be filed and further
improvements can of course be made!
Cheers.
--
Joshua M. Clulow
http://blog.sysmgr.org
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
