Last week I helped a coworker get his friend's PC running 1.4.2 out of one
partition. The machine now triple-boots Win98, SuSE 6.3 Linux, and NetBSD.

Problem #1. sysinst (both 1.4.1 and 1.4.2) mangles the C/H/S numbers in
the MBR, even though it has been told to "use only part of the disk" and
we didn't change any of the MBR partitions.

I have been unable to reproduce this on my own machines, I think because
all my IDE drives are below 4G. The problem system has an 8gig drive but
our BIOSes all seem to like a geometry of 128 heads, 63 sectors, which
means the 1024 cylinder limit is hit at about 4gig.

The symptom of the problem is that you do a partial disk install in sysinst,
on a disk where the four MBR partitions already cover the whole disk even
though that runs off the 1024-cylinder area. Then you find that the MBR's
C/H/S data is all smushed around: cylinders are off by a factor of two, and
some of the head/sector numbers are off by 1 such that partitions appear to
overlap. This caused no end of weird diagnostics from the boot selector
(System Commander) and other utility programs.

However, the "linear" block numbers in the MBR are perfectly fine, and in
fact, fdisk -u can be used to regenerate the C/H/S numbers from them.
(This is how I fixed the damage after each install we tried.)

The MBR was laid out as follows (in order):

	1 gig for Win98
	1 gig for NetBSD
	2 gig for Linux root
	4 gig in an extended partition, split into Linux swap, /var, etc.

Possibly due to some SuSE weirdness, the latter two partitions containing
Linux stuff started at some weird offset into their cylinder, and it was
legitimate -- the "linear" block numbers matched up and everything. These
guys also were mangled by sysinst, but fdisk -u had no trouble fixing them.
Exact cause of weird offset is still unknown.

Problem #2. i386 precompiled packages for 1.4.2 have very broken dependencies.

This was using pkg_add in a directory on /cdrom that was a strict subset
of the "All" directory on ftp.netbsd.org for i386 1.4.2 packages. System
was not networked, and only binary packages were installed.

Some packages (like navigator-4.7.tgz) perpetually insist that their
dependencies have not been installed (like suse_compat-6.1 or later).
I didn't try -f, because it was getting late and we wanted to call it
a night. I expect that -f would have worked, but the bug's still there.

Other packages (like XF86Setup-3.3.6.tgz) install without errors, but
then fail when you try to run them. Fortunately in the XF86Setup case,
I remembered that its icky dependency was on perl, so I explicitly did
a pkg_add of perl-5.00404.tgz and then XF86Setup started working.

User Whine #1. "mount doesn't auto-detect the type of the filesystem."

I.e., mount -t auto. Seems pretty reasonable to me. Any takers?

User Whine #2. "how do I enable normal user mounting of /cdrom and /floppy ?"

Since those are public mount points, you really want to use a group instead
of a single userid to authenticate the mounting. Tonight I tried to enable
mounting for anyone in group 'wheel' but 1.4.1 didn't want to do it. I don't
normally do this but that's mainly because I'm lazy and never pursued it.
Maybe 'sudo' is TRT for this, and we should do more to help people install
and use it.

User Whine #3. "You mean Ctrl-Alt-Del on the console DOESN'T do a shutdown??"

For total end-users who never run critical apps on their machine, the concept
of making it hard to shoot yourself in the foot is just lost on them. And in
all honesty, I can see some value in having this as an optional feature.
Maybe it takes a sysctl to turn it on, but that'd be a line in rc.conf. BFD.

User Compliment #1. "Our Linux XF86Config file _just_ _worked_ !!"

This was after we fixed the mouse config (PS/2 mouse, argh!!) and there
was some xvidtune tweaking needed (probably because their driver has SuSE
private bits in the SuSE version), but other than that it really did work.

User Compliment #2. "My god, you just ran 'lilo --help' and it did it."

	Linux emulation. it works so well it's spooky.

User Compliment #3. "Gee, it didn't fight us as much as the SuSE install."

Once we got over the MBR problem, it was easy for them to see what a sysinst
install is supposed to be like. Prior to that they were drooling mad about
sysinst because they'd already tried 1.4.1 and had it mangle their MBR, which
scared the crap out of them because they hadn't made backups yet (oops).


I guess that's it, comments welcome...

Todd Whitesel
toddpw @ best.com