Rainer Orth
2008-Jul-22 16:58 UTC
[zfs-discuss] Moving ZFS root pool to different system breaks boot
Recently, I needed to move the boot disks containing a ZFS root pool in an Ultra 1/170E running snv_93 to a different system (same hardware) because the original system was broken/unreliable. To my dismay, unlike with UFS, the new machine wouldn''t boot: WARNING: pool ''root'' could not be loaded as it was last accessed by another system (host: hostid: 0x808f7fd8). See: http://www.sun.com/msg/ZFS-8000-EY panic[cpu0]/thread=180e000: BAD TRAP: type=31 rp=180acc0 addr=0 mmu_fsr=0 occurred in module "unix" due to a NULL pointer dereference : trap type = 0x31 pid=0, pc=0x1046de4, sp=0x180a561, tstate=0x4480001602, context=0x0 g1-g7: 0, 180b1c8, 30000314f80, 306, 18c2c00, 10, 180e000 000000000180a9e0 unix:die+74 (10c1400, 180acc0, 0, 0, 10, 180aaa0) %l0-3: 0000000000000000 0000000000000000 0000000000000000 0000000001000000 %l4-7: 0000000000002000 00000000010c1848 00000000010c1800 0000000000001a7e 000000000180aac0 unix:trap+9d8 (180acc0, 0, 31, 1c00, 0, 5) %l0-3: 00000000c1680000 ffffffffffffe000 0000000000000000 0000000001835bc0 %l4-7: 0000000000000001 0000000000000001 0000000001162800 0000000000000002 000000000180ac10 unix:ktl0+48 (0, 180e000, 180afe8, 30000314b00, 2f, 30000314b00) %l0-3: 0000000000000003 0000000000001400 0000004480001602 000000000101b5b0 %l4-7: 000000000000000c 0000000000000003 0000000000000000 000000000180acc0 000000000180ad60 genunix:lookuppnat+90 (0, 0, 1, 180afe0, 180b1c8, 0) %l0-3: 0000000000000118 0000000000000000 0000000000000000 00000000c0000c23 %l4-7: 000000000000003f 000000000000000a 0000000001835bc0 000000000180afe8 000000000180ae20 genunix:vn_createat+11c (7fffffff, 1, 180b1d0, 80, 80, 1) %l0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %l4-7: 0000000000002102 0000000000000001 fffffffffffffdff 0000000000000000 000000000180b020 genunix:vn_openat+164 (180b420, 2102, 2302, 200, 1, 100) %l0-3: 0000000000000001 0000000000000000 0000000000000000 0000000000000000 %l4-7: 0000000000000000 0000000000000080 0000000000000300 000000000180b1c8 000000000180b270 genunix:vn_open+30 (ffffffffffffffff, 1, 2302, 1a4, 0, 0) %l0-3: 0000000000000004 0000000001877c00 0000030000309418 0000030000309418 %l4-7: 000000000000000c 0000000000000003 0000030000c114a8 000000000000062c 000000000180b340 zfs:spa_config_write+c8 (30000c13928, 30000c138a8, 0, 1, 30000c137e8, 18d6c00) %l0-3: 0000030000045870 0000030000d19b10 00000300000458c0 000000000134fc00 %l4-7: 0000000000000018 0000000000000005 0000000000002000 000000000134fc00 000000000180b4b0 zfs:spa_config_sync+104 (300003111c0, 0, 1, 300003111e8, 0, 5) %l0-3: 0000030000311660 00000300003111c0 0000030000c13928 0000000001350000 %l4-7: 000000000134fc00 0000000001350000 0000000000000000 0000000000000000 000000000180b570 zfs:spa_import_common+470 (0, 134e400, 0, 1, 0, 300003111c0) %l0-3: 0000000001346d58 0000000000000000 0000000000000001 ffffffffffffffff %l4-7: 0000000000000001 0000000001346c00 000000000134e400 000000000000012c 000000000180b650 zfs:spa_import_rootpool+74 (183b3d0, 183b000, 134f000, 8, 134bc00, 134f000) %l0-3: 000000000180e000 0000000001873000 0000000000000036 0000000001815000 %l4-7: 0000000000000035 0000000000000002 0000000001843ab8 000000004885f531 000000000180b720 zfs:zfs_mountroot+54 (1899f28, 0, 18c2800, 708, 300003b09f0, 13380cc) %l0-3: 0000000001815400 00000000018c8000 00000000012ba000 00000000011e8000 %l4-7: 00000000018c3400 00000000012ba000 00000000011e8000 00000000018bbc00 000000000180b7e0 swapgeneric:rootconf+1ac (12dc400, 0, 1873400, 1873bb0, 18c35f0, 18bfc00) %l0-3: 0000000001873400 0000000000000000 00000000018c0800 000003000004c6f0 %l4-7: 00000000018c2c00 00000000012dc400 0000000001873400 0000000000000001 000000000180b890 unix:stubs_common_code+70 (300000f1000, 0, 4, 3000004c520, 300000f1000, 1877f18) %l0-3: 000000000180b149 000000000180b211 0000000000000000 0000000000000001 %l4-7: 0000000000000000 0000000001818ab8 0000000000000000 0000000001142800 000000000180b950 genunix:vfs_mountroot+5c (600, 200, 800, 200, 1873400, 189a000) %l0-3: 000000000001d524 0000000000000064 000000000001d4c0 0000000000001d4c %l4-7: 00000000000005dc 0000000000001770 0000000000000640 00000000018c5800 000000000180ba10 genunix:main+b4 (1815000, 180c000, 1835bc0, 18151f8, 1, 180e000) %l0-3: 0000000001836b58 0000000070002000 00000000010c0400 0000000000000000 %l4-7: 000000000183ac00 0000000000000000 000000000180c000 0000000001836800 panic: entering debugger (no dump device, continue to reboot) This seems to be the same issue as CR 6716241, which has been closed as `Not a defect''. I consider this completely unacceptable since this is a serious regression compared to UFS, which has no such requirement. There needs to be some sort of documented workaround for situations like this. Fortunately, the machine still had a UFS BE with snv_93, where I could import the root pool like this: # zpool import -f -R /mnt root Afterwards, the machine booted as expected. In the absence of this BE, and suffering from the absence of SPARC failsafe archives after liveupgrade (recently mentioned on install-discuss), I''d have been completely stuck. Rainer ----------------------------------------------------------------------------- Rainer Orth, Faculty of Technology, Bielefeld University
Jürgen Keil
2008-Jul-23 14:31 UTC
[zfs-discuss] Moving ZFS root pool to different system breaks boot
> Recently, I needed to move the boot disks containing a ZFS root pool in an > Ultra 1/170E running snv_93 to a different system (same hardware) because > the original system was broken/unreliable. > > To my dismay, unlike with UFS, the new machine wouldn''t boot: > > WARNING: pool ''root'' could not be loaded as it was > last accessed by another system (host: hostid: > 0x808f7fd8). See: http://www.sun.com/msg/ZFS-8000-EY > > panic[cpu0]/thread=180e000: BAD TRAP: type=31 rp=180acc0 addr=0 mmu_fsr=0 occurred in module "unix" due to a NULL pointer dereference...> suffering from the absence of SPARC failsafe archives after liveupgrade > (recently mentioned on install-discuss), I''d have been completely stuck.Yes, on x86 you can boot into failsafe and let it mount the root pool under /a and then reboot. This removes the hostid from the configuration information in the zpool''s label. I guess that on SPARC you could boot from the installation optical media (or from a network server), and zpool import -f the root pool; that should put the correct hostid into the root pool''s label. This message posted from opensolaris.org
Rainer Orth
2008-Jul-23 15:53 UTC
[zfs-discuss] Moving ZFS root pool to different system breaks boot
=?UTF-8?Q?J=C3=BCrgen_Keil?= <jk at tools.de> writes:> > Recently, I needed to move the boot disks containing a ZFS root pool in an > > Ultra 1/170E running snv_93 to a different system (same hardware) because > > the original system was broken/unreliable. > > > > To my dismay, unlike with UFS, the new machine wouldn''t boot: > > > > WARNING: pool ''root'' could not be loaded as it was > > last accessed by another system (host: hostid: > > 0x808f7fd8). See: http://www.sun.com/msg/ZFS-8000-EY > > > > panic[cpu0]/thread=180e000: BAD TRAP: type=31 rp=180acc0 addr=0 mmu_fsr=0 occurred in module "unix" due to a NULL pointer dereference > ... > > suffering from the absence of SPARC failsafe archives after liveupgrade > > (recently mentioned on install-discuss), I''d have been completely stuck.[...]> I guess that on SPARC you could boot from the installation optical media > (or from a network server), and zpool import -f the root pool; that should > put the correct hostid into the root pool''s label.That''s what I did with the snv_93 UFS BE I had still around, with the exception that I used zpool import -f -R /mnt to avoid pathname clashes between the miniroot and the imported pool. I think I even exported the pool afterwards, but I''m no longer certain about this: I seem to remember problems with exported root pools being no longer bootable. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Faculty of Technology, Bielefeld University