Have a few issues...
(pardon the laundry list :)
Background:
Fresh install of RC2 (4.0-20000214-CURRENT).
Fresh meaning remove slices, create, yada...
After install, tweak some minor things while building an SMP kernel,
install pdksh and less from ports, and install CVSup.
Update source, check commit mail, update once more, wait a few hours, check
mail. Nothing new or reported broken. Good.
That was Sunday around 5am CST.
Build, install, new kernel, remake devices.
Good so far. Not quite lunch now.
Reboot and neither ad1 or ad0 are seen.
Used the exact same kernel config file. WTF?
A salute of the 3 finger style, interrupt boot, unload kernel, load
kernel.old, boot and all is well.
Same thing happened with Friday sources in the same scenario, but realized
the MAKEDEV part was forgotten.
The problem is that the newer kernels do not like my loader.conf file
entries and the only thing different is that I turned off a couple things:
autoboot_delay="5"
bootfile="/kernel,/kernel.old,/kernel.GENERIC"
cd9660_load="NO"
mfs_load="YES"
nfs_load="NO"
vinum_load="NO"
Except for vinum none of the other modules are compiled into the kernel,
but when mfs_load is "YES" ad(0|1) are not seen. When "NO" the modules
still loads automagically, which is kind of nice and a new feature with 4.0.
Why would loading a module cause the kernel not to recognize the IDE drives?
Also found an install nit while trying the
on-my-floppies-still-called-novice install. Both novice and custom will
not allow you to build a custom distribution. Didn't try "express" yet,
but rebooting for each attempt failed forcing the choice of a predetermined
distribution. This used to work and did so for 3.4R and RC1.
Next issue is with OpenSSH.
>From the discussions here I inferred that doing a build and install and
*then* installing RSAref should "just work."
Happy to say that it does!
However...
$HOME/.ssh mode 510 owner: root group: <user's group>
$HOME/.ssh/authorized_keys mode 440 owner: root group: <user's group>
Same as it was when using ssh from the ports, but now with openssh if other
does not have execute permission on the dir and read on the file it will
fail, which is ironic considering this bit from sshd(8):
$HOME/.ssh/authorized_keys
Lists the RSA keys that can be used to log into the user's ac-
count. This file must be readable by root (which may on some ma-
chines imply it being world-readable if the user's home directory
resides on an NFS volume). It is recommended that it not be ac-
cessible by others. The format of this file is described above.
Good suggestion, but it isn't working in practice unless $HOME is set
correctly.
Lastly it appears that Vinum is no longer shutting down when rebooting
(some processes... ps axl advised). As per my messages to Greg this
happens with either 'shutdown -r now' or by doing a 'shutdown now' followed
by a 'shutdown -r now' from single user mode. The latter displays it for
each shutdown and after the first the only daemon in addition to the normal
system ones for single user, is Vinum. Unmounting any volumes before going
single user or after does not change this behaviour.
Except for the fact that I cannot induce a panic this is *exactly* what I
reported back in September and is once more 100% consistant. The lack of a
panic and the filesystems being marked clean make this a minor issue.
To avoid this one can add 'umount <volume(s)>' and 'vinum stop' to
/etc/rc.shutdown.
Damn! Time to step back to the (a) ssh problem.
After doing a few reboots to check if the Vinum issue is repeatable and
consistant with what the last time I diagnosed it... Well, with nothing
other than a dozen or so reboots it is no longer possible to authenticate
with RSA. The error is:
fatal: rsa_private_decrypt() failed
Saw this earlier when working out authenticatin failing, which meant I was
restarting sshd a few time. Fresh boot and it fails. Restart sshd and it
works. Seem to recall something like this being discussed.
Just a wild guess, but it seems that something creeped in that is affecting
modules. I'm seeing problems with loading mfs before the kernel and Vinum
isn't dying nicely. Others have issues with loading them in a certain order.
Can't pinpoint the time for my 2 issues, but sometime in the sevenday
before the 25th.
Pardon the ramble, but I've been trying to nail down these problems and
have one more to look at, as well as a trace for Greg. <sigh>
Time to go out and watch the grass turn green. 8-)
Jeff Mountin - [EMAIL PROTECTED]
Systems/Network Administrator
FreeBSD - the power to serve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
