SSHD not starting due to error

[guff666]

SSHD has stopped on my server and won't restart. The log shows:

Code:

Jun 13 18:13:39 freenas notifier: Starting sshd.
Jun 13 18:13:39 freenas notifier: /libexec/ld-elf.so.1: /usr/lib/libkrb5.so.10: Undefined symbol "_krb1_AES[spring_to_$efault_iterator"
Jun 13 18:13:39 freenas root: /etc/rc.d/sshd: WARNING: failed to start sshd
Jun 13 18:13:39 freenas notifier: /etc/rc.d/sshd: WARNING: failed to start sshd

It looks like a corruption somewhere. What should I do?

version is FreeNAS-8.3.0-RELEASE-x86 (r12701M)

 

[joeschmuck]

I'd tell you to try a few things but first the easiest thing to do is to reboot your FreeNAS to see if it comes up.

Are you running an encrypted system? The AES caught my eye and I've never dealt with encryption on FreeNAS.

Thanks for listing your FreeNAS version. I assume you know there is another version out there. And do you need to run the 32 bit version? I know it's a bit off topic.

 

[guff666]

Thanks Joe
I've rebooted it and the problem persists.
I'm not aware that I'm running an encrypted system. How would I know?

No particular reason for running 32-bit that I can recall. The processor is 64-bit capable (Celeron 420) but it's underpowered and there's only 2GB of RAM.
Would there be a benefit of moving to 64-bit?
How would I migrate and keep all the settings?

 

[joeschmuck]

2GB of RAM is low. The benefit to running the 64 bit version is more people use it so more bugs get fixed over the 32 bit version in general.
You would know if you had encrypted drives as it's a selection when you setup your ZFS pool, assuming you are using ZFS and not UFS.

Let me ask you this question, have you ever had this running and if so for how long?

As to migrating to the 64 bit version, if you have a simple setup, just create a backup of your configuration (read the manual). My personal opinion is to use a second flash drive and install the newer 64 bit version on to it. This gives you the ability to roll back to the older version if needed very easily. And if there is corruption, the new installation should fix that.

Good Luck.
P.S. You should always backup your important data, do so first even though you shouldn't have any data risk it's just the smart thing to do.

 

[guff666]

Ta
Oh yes, this has worked fine since the system was created last October. I noticed it wasn't because the ZFS Snapshots from my media server weren't being backed up to the freenas server. I then found I couldn't log in using ssh.

freenas is currently running on an old Fujitsu Scaleo box that used to run to run Windows Home Server. The mb won't take more than 2GB. I'll be installing a new media server soon, so Freenas can have the current media server; which runs OpenIndiana.

 

[jgreco]

If he's only got 2GB, then the x86 version may be a better choice. The image sizes for the 64-bit stuff are a bit bigger, and basically you'd be further stressing the system for no apparent return.

 

[joeschmuck]

Then maybe I stand corrected. I didn't realize the loaded image was larger, I thought it was only compiled for 64bit vice 32bit.

 

[guff666]

I'll try updating freenas and see what it's like after that.

 

[jgreco]

Then maybe I stand corrected. I didn't realize the loaded image was larger, I thought it was only compiled for 64bit vice 32bit.

It is a necessary and ugly side effect. A 64-bit instruction implies 64-bit pointers, addressing, and in many cases data as well. This makes the individual instructions larger, which makes the executables larger, which makes the amount of memory consumed by the system larger.

In FreeBSD, for server use, if your service involves lots of processes and none of them (including the kernel) require the ability to address more than 2 or maybe 3GB of memory, 64-bit was considered a fool's option; you could HAVE more than 4GB of RAM in a system with PAE, and 8GB systems in particular were quite common mid-2000's. The trick is that the memory management was mapping different physical addresses to 32-bit virtual address ranges used by FreeBSD's kernel and processes, and each of those maps was separate.

Even today, we deploy 32-bit FreeBSD for a vast majority of VM's, because if you can have a 32-bit VM or a 64-bit VM and they do the same task, and the only difference is that one consumes more memory to accommodate 64-bitness, that's stupid.

But with FreeNAS, the whole point behind the 8GB RAM thing we keep pounding at users is that the kernel and ZFS use this for ARC and other related stuff: the Kernel Virtual Address space needs to be able to address almost all of that, so 64-bit is required on FreeNAS to make best use of ZFS and 8GB.

So today, the economics are all different. With 128GB of memory costing what maybe 8 or 16GB of memory did back in the mid-2000's, you're probably not going to install a new physical server with only 4GB of RAM anymore. And configuring PAE is vaguely annoying and doesn't work quite right on some platforms under obscure conditions. So physical servers are generally x64 these days anyways, while i386 is good for VM's.

 

[guff666]

Re-installing that release did the trick. Somehow, something got corrupted.
I tried to update to the newer release initially, but the box wouldn't boot and as it's headless, I couldn't work out why.

I'll worry about updating another time, at least my ZFS snapshots can sync from my Openindiana box OK now.

Gareth