NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Substantial COMPAT_LINUX changes in netbsd-5?

On Jan 15, 2010, at 4:55 PM, Christos Zoulas wrote:
In article <>,
Fredrik Pettai  <> wrote:
On 1/14/10 6:16 PM, Hauke Fath wrote:

after upgrading a few i386 servers to netbsd-5, wip/tsm (5.2.2, now 5.2.5)
terminates with an OOM error:


I also hit problems running the Veritas Netbackup client for Linux after
upgrading to netbsd-5 (from netbsd-4).

Any idea what changes in COMPAT_LINUX shipped with netbsd-5 might be

First, the suse(100)_base package has an "error" then running netbsd-5,
since linking outside the emulation root is not permitted. See:
The symlink /emul/linux/etc/mtab should point to /proc/mounts instead of /emul/linux/... The NetBackup client use /etc/mtab, which then fails if
it isn't corrected.

Second, the filesystems never worked to backup unless they where mounted
inside the emulation root. So I NFS-mounted them under
/emul/linux/netbackup/... instead.
However, the df command (which Netbackup also uses during backups) shows the real path (which is /usr/pkg/emul/...), so I mimiced the directory tree under /emul/linux/... (usr/pkg/emul/linux), and a netbackup symlink
at the top, pointing back to /netbackup.

After that, we at least got a full backup to work, but the incremental backups still fails. It doesn't feel stable ATM. I just noticed that the
df command seems to get "blocked" during a incremental backup try.


I think that the namei changes that handle the emulated root could be at
fault here, or NFS. Have you tried using a loopback mount?

No, but I will try that now then.

Unfortunately, we did try to go for loopback mounts under netbsd-4, (worked well under netbsd-3-1) but it proved to have some sort of small memory leak, so the system crashed after many days of uptime and huge numbers of Gigbytes of data reads for the backups.

he@( did tracing on that problem, but I don't know if he managed to gather enough data for pinpointing the actual code that caused these leaks.


Home | Main Index | Thread Index | Old Index