Re: can't run as root with netbsd-5

[bsd-xen%roguewrt.org@localhost]

On Tue, Mar 03, 2009 at 10:09:34PM -0600, Eric Haszlakiewicz wrote:
> I just tried upgrading one of my machines to netbsd-5.  The process seemed to
> go ok on a test machine, and when I tried it on another machine it started
> out ok, but now I can't run things as root.  Specifically:
>   I copied a netbsd 5 RC2 generic kernel and rebooted. (previously running
>        netbsd 4)
>   After rebooting, I was able to login and run stuff as root just fine.
>   I was going to let it run for a bit and then upgrade userland, but
>    now when I attempted to su to root to do so I get errors like:
> 
> su: /bin/ksh: Resource temporarily unavailable

A major upgrade without physical access ... you're game!

And not syncing your userland and kernel while you have physical
root access, life on the edge! hehe

>   I can use sudo to switch to other users, and running most things seems
> to be fine, but actually executing stuff as root from a setuid process
> fails.  Things that are already running, like apache, seem to be ok, and
> the root owned apache process can fire up additional www owned processes.
> 
>   I would just reboot the machine, but I don't currently have easy
> physical access to it.
> 
>  Does anyone have any suggestions?

How are you doing the upgrade? Via build.sh and the 5.0 release tag or
binary sets?

If I ever have to do a remote upgrade I use build.sh, purely for it's
independence. Not to say I haven't run into problems before. TBH it's only
been an issue when boot specific changes have been made. My upgrades
never jump version to the extent of yours however.

If you are unable to 'su -' and stopping existing processes etc doesn't
help, I can only suggest extracting the sets from some kind of boot media.

I wonder if it's ksh specific and whether sh has the same problem.

I hope someone else can help you but from experience there isn't much
information floating around about borked upgrades. There typically isn't
much that can be done except find a way to sync the kernel and userland.

I find reboots sometimes have issues when there is a kernel/userland 
mismatch. You may find physical access is about the only option.

It's this kind of scenario that makes xen a blessing.

If the environment is sort of stable and you have a lot of time, maybe
cvs and build.sh is a viable way of upgrading *shrug*.

Best of luck.

Sarton