Re: 1.6D sysinst... [long]
Hauke Fath <hauke <at> Espresso.Rhein-Neckar.DE>
2002-07-20 21:04:26 GMT
At 10:31 Uhr -0500 20.7.2002, Frederick Bruckman wrote:
>On Sat, 20 Jul 2002, Hauke Fath wrote:
>> # Treat /usr/X11R6/lib/X11 like /etc, don't just overwrite its contents.
>Why? It's a bad idea, in general, to customize installed files. Nor is
Like '/etc/*'? Frederick, you've just sounded like Microsoft. ;)
This is a really old installation, significantly older than NetBSD-pkg. I
set it up shortly after Allen enabled X11 support for the Quadra 700.
[hauke <at> q700] ~ # ls -lt /usr/X11R6/lib/X11/ | tail
r--r-- r-- 1 root wheel 4767 Jul 6 21:00 XKeysymDB
drwxr-xr-x 2 root wheel 512 Jun 3 21:42 wmx
drwxr-xr-x 2 root wheel 512 Nov 18 1999 etc
drwxr-xr-x 2 root wheel 512 Nov 18 1999 doc
drwxr-xr-x 5 root wheel 512 Nov 18 1999 XF86Setup
drwxr-xr-x 3 root wheel 512 Jun 7 1997 afterstep
drwxr-xr-x 2 root wheel 512 May 22 1997 sample.fvwmrc
drwxr-xr-x 2 root wheel 512 May 22 1997 fvwm2
drwxr-xr-x 2 root wheel 512 May 22 1997 fvwm
drwxr-xr-x 2 root wheel 512 May 22 1997 chimera
A vanilla X11 app will stuff its global preferences in
'/usr/X11R6/lib/X11', since this is the traditional /etc equivalent of X11.
And so will X11 based packages unless you go with xpkgwedge.
NetBSD/mac68k has shipped the same barebones X11 setup for seven years or
so. Its xdm setup does not deal with an Xmodmap ("everyone has a US kbd"),
it does not deal with ssh keys (Xsession)... I'd have to look up what else
I have changed there. X11 application resource defaults come to mind.
>For "xdm" for example, you could copy
>/usr/X11R6/lib/X11/xdm/ to /etc/X11/xdm/, customize the files in /etc,
>and set `xdm_flags="-config /etc/X11/xdm/xdm-config"' in /etc/rc.conf.
Thanks for the pointer. I will do that.
>> # Factor out actions like transition a.out -> elf, upgrading /etc or
>> /usr/X11R6/lib/X11, and make them available in a menu.
>What's the issue with the a.out -> ELF transition? It should be a
>one-time thing, and be unobtrusive for systems which are ELF already.
Finer control? The ability to retry/re-do specific steps instead of doing
it all over? You're right, though, that transition is a bad example since
sysinst realizes when it has already done that and does not retry. But
there are other things like the /etc update, making devices or whatever
that you might want to factor out. Minor point, agreed.
>For "/etc", you could always decline to install the "etc.tgz" set, and
>let "etcupdate" take care of it after booting into the new system.
Sigh... That was exactly my summary: Don't trust sysinst for the upgrade,
do it manually. *If* you tell sysinst to upgrade an existing installation,
one of the first things it does is move the existing /etc aside and
install etc.tgz which is then partly adjusted during the upgrade procedure.
And if sysinst drops the ball, you have to find out what has been done so
far and clean up after it. In my case, not even fstab was in place, which
makes it impossible to e.g. reinstall selected sets.
The etcupdate/postinstall combo is vastly superior to what sysinst offers
and incompatible with the latter. As I said, the INSTALL document of the
20020706 snapshot does not mention it at all, and postinstall for all its
beauty and power is undocumented other than by its source and folklore on
In case I haven't made that clear enough: My issue is with sysinst, mainly.
The fact that I can boot a ramdisk kernel on mac68k and work from it is way
cool, and the performance of /etc/postupdate is the one major pleasant
surprise in this experience.
>> Overall impression: While sysinst has become quite polished in some areas,
>> its structure is still very rigid and unforgiving. Stroll from the Right
>> Path, and you're done for.
>> At this point, I'd advise to ignore sysoinst and upgrade the traditional
>> way: Boot with the new kernel to single user, unpack the tarballs, upgrade
>> /etc with /etc/postinstall and /usr/sbin/etcupdate.
>While most of the problems you point out are valid (and they all look
>fixable), I think your overall assessment is overly harsh.
Due to these valid problems, I needed ~15 sysinst runs to get the upgrade
done. And it is not even the first time I went through this. 'Overly harsh?'
>You can get used to sysinstall's warts: If the install bombs because
>of a typo in the nfs path, for example, you can just hit ^D and
>start again -- no need to reboot.
I rebooted _once_ because fsck claimed to mark a fs clean and did not, and
sysinst did see this as an error. The other fourteen sysinst runs resulted
of simply 'starting again'. Bad enough, though, since you have to manually
clean up after sysinst (and find out the hard way _what_ you have to take
care of) before you can restart it.
>I could never get used to the old Mac OS installer
The MacOS installer is irrelevant for this discussion - I haven't even
>taking 24 hours to unpack the sets on a Quadra, and what you call "the
>traditional way" is hard to support (though I do that myself on the
>one headless Quadra, it's not a very nice thing to present that
>procedure to a new user), and won't do at all for new installs.
I am not talking about new installs, either. I am talking about the sysinst
upgrade procedure, only. While new installs have been just as problematic
for me in the past, at least there is no danger of trashing existing data
(unless sysinst trashes the wrong partition, that is...).
[Btw.: I went through this three days ago. Fifteen times, each time kicked
out with a different trivial error, cleaning up, re-starting from zero. I
can be pretty stubborn in such cases, and I decided to make sort of a
project out of it. When did _you_ (or Bob) do your last NetBSD upgrade
through sysinst? Just curious...]
/~\ The ASCII Ribbon Campaign "They that can give up essential liberty
\ / No HTML/RTF in email to obtain a little temporary safety
X No Word docs in email deserve neither liberty nor safety."
/ \ Respect for open standards -- Benjamin Franklin, 1759