Hi, I have a computer running snv_81 with ZFS root set up previously, and wanted to test the new LU bits in snv_90. Of course, I expected this wouldn't be as easy as it should be.
The first annoyance was that installing the new LU packages from the DVD don't update the manpages. Fortunately, http://opensolaris.org/os/community/arc/caselog/2006/370/commitment-materials/spec-txt/ has the details (as well as the info which I would need later). My current setup is snv_81 with root at zpl/root, /opt at zpl/opt, and separate filesystems for data. This differs from the new hierarchy in the spec, where root is <zpool>/ROOT/<BE name>, and any child filesystems are <zpool>/ROOT/<BE name>/<fs>. The new filesystems also use defined mountpoints (relying on canmount=noauto to not automount them during creation) instead of mountpoint=legacy. A simple lucreate -n snv_90 fails because the ABE isn't defined - I don't have a /etc/lutab. The new lu expects lutab to have been populated at install time with the current BE as mentioned in the spec. It seems to prefer naming the BE after the ZFS filesystem which contains the root (in my case zpl/root so it looked for a BE named "root"). I created a fresh /etc/lutab: 1:root:C:0 1:/:zpl/root:1 1:boot-device:/dev/dsk/c1t0d0s0:2 Where the BE ID is 1, "root" is the BE name, "zpl/root" is the filesystem, and /dev/dsk/c1t0d0s0 is the device for the "zpl" pool. I attempt lucreate again, and it now asks me to run /usr/lib/lu/lux86menu_propagate, which presumably is supposed to synchronise the GRUB menu and make it safe to delete a BE containing GRUB's stage2 file. So I do it: # /usr/lib/lu/lux86menu_propagate It leaves /zpl/boot/grub/bootsign/BE_root as a hint that the BE named "root" currently contains GRUB's files. Now lucreate -n snv_90 get further - it snapshots zpl/[EMAIL PROTECTED] and attempts to clone to it zpl/ROOT/snv_90 - unfortunately the expected zpl/ROOT hierarchy doesn't exist yet. To fix that: # zfs create zpl/ROOT The error handling doesn't seem to be complete, as I had to delete the snapshot from the failed attempt before trying again. lucreate is able to create the clone now and event snapshots zpl/[EMAIL PROTECTED] and clones to ROOT/snv_90/opt correctly. It fails later (surprise), trying to set the ZFS property "canmount" to the value "noauto" on the clones. Unfortunately this value for canmount was introduced at the same time as the installer changes, so it's not supported in Nevada before snv_88. I edited /usr/lib/lu/luclonefs to set canmount=on instead (which is fine because the current filesystems use mountpoint=legacy so the clones won't be automounted). # cp -p /usr/lib/lu/luclonefs /usr/lib/lu/luclonefs.orig # perl -pi -e s,canmount=noauto,canmount=on,g /usr/lib/lu/luclonefs # lucreate -n snv_90 Now succeeds. With the snv_90 DVD image mounted at /mnt: # luupgrade -u -n snv_90 -s /mnt It even completes. Since we can't set the mountpoint of the new filesystems correctly yet under this Nevada build (or it will try to automount since canmount=noauto can't be used), we set them to mountpoint=legacy again, and update the existing vfstab entries for the new locations. # zfs set mountpoint=legacy zpl/ROOT/snv_90 # zfs set mountpoint=legacy zpl/ROOT/snv_90/opt # mount -F zfs zpl/ROOT/snv_90 /a # perl -pi -e s,zpl/root,zpl/ROOT/snv_90,g /a/etc/vfstab # perl -pi -e s,zpl/opt,zpl/ROOT/snv_90/opt,g /a/etc/vfstab Now would also be a good time to check /a/var/sadm/system/data/upgrade_cleanup # umount /a # sudo lustatus " Boot Environment Is Active Active Can Copy Name Complete Now On Reboot Delete Status -------------------------- -------- ------ --------- ------ ---------- root yes yes yes no - snv_90 yes no no yes - " # sudo luactivate snv_90 "... Activation of boot environment <snv_90> successful." It doesn't seem to change the bootfs property on zpl or GRUB's menu.lst on the zpool, so we do it manually: # zpool set bootfs=zpl/ROOT/snv_90 zpl Update the boot archive (which is stale for some reason): # mount -F zfs zpl/ROOT/snv_90 /a # bootadm update-archive -R /a # umount /a Cross fingers, reboot! # init 6 -Albert _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
