>Number:         32384
>Category:       install
>Synopsis:       netbsd-2 (2.1_STABLE) to netbsd-3 (3.0) source upgrade woes
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    install-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Dec 25 18:55:01 +0000 2005
>Originator:     Matthew Mondor
>Release:        3.0
>Organization:
Pulsar-Zone
>Environment:
NetBSD hal.xisop 3.0 NetBSD 3.0 (GENERIC) #0: Sat Dec 24 07:18:50 EST 2005  root@hal.xisop:/usr/obj/sys/arch/i386/compile/GENERIC i386
>Description:
I upgraded a single box from netbsd-2 branch (which it successfully
tracked up to a rather recent 2.1_STABLE) to netbsd-3 one prior to
3.0 official release (netbsd-3 eventually expected to become 3.0_STABLE)

I did this from source, remotely, to verify how well it goes, so
that I don't compromise my other boxes (which are more critical).

So here are the issues I discovered:

- postinstall did not update the password database, although it
  appeared necessary, since several postinstall checks couldn't
  run because of apparently unknown format password databases.
  Had to be fixed manually by running vipw and saving, or using
  pwd_mkdb(8).  Then the uid and gid tests could be ran without
  error.

- The uid and gid checks did notify about missing _pflog group
  and pflog user.  However, UPDATING had no information about this,
  so it wasn't obvious to know which IDs to assign them when adding
  them manually.  I had to look into /usr/src/etc to fix these.

- A more important problem is that I couldn't login as root anymore,
  nor su to the superuser after the upgrade.  This was annoying and
  problematic since I had to constantly reboot in single user mode
  until I discovered the reason.  It appears to be PAM/login.conf
  related.  Whenever I have a login.conf or cab_mkdb(8) generated
  db for it, root access can't be obtained.  With no login.conf
  or db, it works again, but then I no longer can set special
  limits on a user to for instance be able to run the Sun JRE which
  requires higher than default limits.
  I noticed the messages about this at
      http://mail-index.netbsd.org/netbsd-users/2005/11/
  but couldn't make a working login.conf.  My config file is:

special|Entry to allow running java:\
        :datasize=512M:\
        :memoryuse=512M:\
        :stacksize=64M:\
        :maxproc=2048:\
        :openfiles=2048:

- The x11 postinstall checks seem to tell to manually migrate
  a number of system-wide configuration directories from
  /usr/X11R6/lib/ to /etc/X11/.  Although it appears to have
  copied them successfully, I had to manually delete the ones
  in /usr/X11R6/lib in order to apease postinstall.  Perhaps
  that this is normal since a user might have had custom
  configurations.

- X11R6 stopped achieving the previous 1280x1024 default
  resolution I set.  X11 now appears to obtain a recommended
  resolution setting from the graphics card:
  (II) R128(0): Not using default mode "1280x1024" because it is larger than the preferred mode (1024x768).
  I didn't try yet to see if XFree86 now has a special directive to
  force using such a mode despite not being the card advertized
  favorite mode.

- Unless I'm wrong, PTHREAD_CONCURRENCY wasn't disabled yet,
  meaning that it's probably possible for an unprivileged user to
  set it high and cause the kernel to panic with some especially
  crafted C code.

Please post followups (if any) appended to this one rather than
contacting me directly via email.
Thanks,

Matt

-- 
Note: Please only reply on the list, other mail is blocked by default.
Private messages from your address can be allowed by first asking.

>How-To-Repeat:
Mostly follow tracking-current procedure but upgrading from
netbsd-2 branch to netbsd-3 branch from source.

Have an /etc/login.conf, reboot remotely, and curse :))
>Fix: