On Thu, Aug 21, 2008 at 08:50:47AM -0400, James Carlson wrote: > Jens Elkner writes: > > actually I wanna upgrade our desktop pools to Nevada b95 using > > jumpstart (they are still on snv b55b :( ). > > First suggestion: use Live Upgrade. It's far easier and much less > risky than upgrading via standard upgrade.
Must admit, that I haven't yet the time, to study live upgrade (and also reading about some bugs tells me to give it not a high priority). Anyway, for servers it might be useful and will probably try it when u6 is out, however for clients we do fresh installs since 10+ years without any problems ;-) > > a) the DHCP client is unable to get its hostname. > > That suggests that the DHCP server isn't configured to supply one, and > the profile doesn't have one. We probably ought to do something > smarter by default, and this issue is in the domain of the "Network > Automagic (NWAM)" project. Yepp - resolved. Found out, that the DHCP server in the test LAN was the only one, which had no 'use-host-decl-names' entry in its config file :( > > core '/tmp/root/core' of 4725: /usr/sadm/install/bin/pkginstall -R > > /a -O parent-zone-name=global -O p > > ac62327e strcmp (1f00, 8045bd0) + de > > 08066787 already_mounted (80457b4, 0, 8045bd0, 809d770) + 43 > > 0806743b get_mntinfo (1, 0) + 26f > > That looks like a new one to me. It's a crash in libinst and (at a > guess) it's a bad vfstab entry. Excellent guess! Since pkgadd -M ... worked, I mangled the entries until it worked. Strange result: It seems, that as soon as more than 3 nfs entries are in /a/etc/vfstab, pkginstall coredumps. So commenting out 2 entries in my case (really doesn't matter, which ones) makes pkgadd work (see http://iws.cs.uni-magdeburg.de/~elkner/jumpstart/vfstab) > File a bug using bugs.opensolaris.org. Done. > > Since this works with u5 I thought, it might be a good idea to > > replace SUNWpkgcmdsu in the b95 miniroot with the same package > > from u5, but the problem still exists (BTW: the pstack above is from > > the u5 iso package). > > I think running system-supplied packages on a different system is > unlikely to be a good idea in any case. Since Sun sales people always don't forget to tell stories wrt. backward compat. of solaris, I thought, stressing this a little bit can't hurt ;-) > > So, has anybody an idea, how to workaround the bug? > > As a workaround, I'd pick a different package access mechanism. > try using the automounter: > /net/192.168.224.1/export/lnf/i386 Didn't work either. > Or set up the package to be accessible via HTTP or FTP, which pkgadd > also supports. Tried the vfstab modifications first, since less work ... > > PS: Sorry for posting on opensolaris, but since SXDE doesn't exist > > anymore, I can't open a case and don't know, where nv related > > problems can be reported/discussed - AFAIK there is no nevada > > dedicated list/"bugzilla" :((((( > > bugs.opensolaris.org OK. Thanx a lot, jens. PS: Hopefully the bug gets fixed soon ... -- Otto-von-Guericke University http://www.cs.uni-magdeburg.de/ Department of Computer Science Geb. 29 R 027, Universitaetsplatz 2 39106 Magdeburg, Germany Tel: +49 391 67 12768
