Re: compile kernel
Here in my of my config file for and64. My goal is to remove all these devices. In 2 or 3 devices only keep this one, and this one. SEE: PCI network (wm0) ; MII / PHY (inphy0) ; IDE (keep pciide* AND ahcisata*) # $NetBSD: GENERIC,v 1.599.4.5 2023/11/03 08:56:36 martin Exp $ # # GENERIC machine description file # # This machine description file is used to generate the default NetBSD # kernel. The generic kernel does not include all options, subsystems # and device drivers, but should be useful for most applications. # # The machine description file can be customised for your specific # machine to reduce the kernel size and improve its performance. # # For further information on compiling NetBSD kernels, see the config(8) # man page. # # For further information on hardware support for this architecture, see # the intro(4) man page. For further information about kernel options # for this architecture, see the options(4) man page. For an explanation # of each device driver in this file see the section 4 man page for the # device. include "arch/amd64/conf/std.amd64" options INCLUDE_CONFIG_FILE# embed config file in kernel binary #ident"GENERIC-$Revision: 1.599.4.5 $" maxusers64# estimated number of users # delay between "rebooting ..." message and hardware reset, in milliseconds #options CPURESET_DELAY=2000 # This option allows you to force a serial console at the specified # I/O address. see console(4) for details. #options CONSDEVNAME="\"com\"",CONADDR=0x2f8,CONSPEED=57600 #you don't want the option below ON iff you are using the #serial console option of the new boot strap code. #options CONS_OVERRIDE# Always use above! independent of boot info # The following options override the memory sizes passed in from the boot # block. Use them *only* if the boot block is unable to determine the correct # values. Note that the BIOS may *correctly* report less than 640k of base # memory if the extended BIOS data area is located at the top of base memory # (as is the case on most recent systems). #options REALBASEMEM=639# size of base memory (in KB) #options REALEXTMEM=15360# size of extended memory (in KB) # The following options limit the overall size of physical memory # and/or the maximum address used by the system. # Contrary to REALBASEMEM and REALEXTMEM, they still use the BIOS memory map # and can deal with holes in the memory layout. #options PHYSMEM_MAX_SIZE=64# max size of physical memory (in MB) #options PHYSMEM_MAX_ADDR=2048# don't use memory above this (in MB) # Standard system options options INSECURE# disable kernel security levels - X needs this options RTC_OFFSET=0# hardware clock is this many mins. west of GMT options NTP# NTP phase/frequency locked loop options KTRACE# system call tracing via ktrace(1) options CPU_UCODE# cpu ucode loading support # Note: SysV IPC parameters could be changed dynamically, see sysctl(8). options SYSVMSG# System V-like message queues options SYSVSEM# System V-like semaphores options SYSVSHM# System V-like memory sharing options MODULAR# new style module(7) framework options MODULAR_DEFAULT_AUTOLOAD options USERCONF# userconf(4) support #options PIPE_SOCKETPAIR# smaller, but slower pipe(2) options SYSCTL_INCLUDE_DESCR# Include sysctl descriptions in kernel # CPU-related options options USER_LDT# User-settable LDT, used by Wine options SVS# Separate Virtual Space options PCPU_IDT# Per CPU IDTs # GCC Spectre variant 2 mitigation makeoptionsSPECTRE_V2_GCC_MITIGATION=1 options SPECTRE_V2_GCC_MITIGATION # CPU features acpicpu*at cpu?# ACPI CPU (including frequency scaling) coretemp*at cpu?# Intel on-die thermal sensor est0at cpu0# Intel Enhanced SpeedStep (non-ACPI) hyperv0 at cpu0# Microsoft Hyper-V #odcm0at cpu0# On-demand clock modulation powernow0at cpu0# AMD PowerNow! and Cool'n'Quiet (non-ACPI) vmt0at cpu0# VMware Tools #Xen PV support for PVH and HVM guests options XENPVHVM options XEN hypervisor*at mainbus?# Xen hypervisor xenbus* at hypervisor?# Xen virtual bus xencons*at hypervisor?# Xen virtual console xennet* at xenbus?# Xen virtual network interface xbd*at xenbus?# Xen virtual block device # experimental: PVH dom0 support #options DOM0OPS #pseudo-device xenevt #pseudo-device xvif #pseudo-device xbdback # Alternate buffer queue strategies for better responsiveness under high # disk I/O load. #options BUFQ_READPRIO options BUFQ_PRIOCSCAN # Diagnostic/debugging support options #options DIAGNOSTIC# inexpensive kernel consistency checks # XXX to be commented out on release branch
Re: Failing to build a bootable custom kernel
> You might want to watch a recent talk by riastradh@ at EuroBSDCon that > gives an overview of build.sh and stuff: https://youtu.be/gm-F3GnM8yM > and skim throgh BUILDING. While build.sh wraps things up nicely, the > NetBSD build system is still just makefiles, and you can still use > good old make inside some specific directory to build just the stuff > you need. On a fast modern box you can build everything in a > reasonable time, but it's still a bit of an overkill for just the > kernel :). Thanks! I actually watched it and that is what originally inspired me. And I have read `src/BUILDING`. There's just some parts that confuse me. For the script itself, I settled with: ``` #!/usr/bin/sh export DESTDIR=/home/jared/Projects/netbsd/obj/destdir export RELEASEDIR=/home/jared/Projects/netbsd/obj/releasedir cd src/ ./build.sh -u -O ../obj -U -m amd64 -N1 -j24 -V MKCROSSGDB=yes tools ./build.sh -u -O ../obj -U -m amd64 -N1 -j24 kernel.gdb=DEBUG_KERNEL ``` for now. It works (I think), but I don't have any gunzipped images. I have a raw kernel under `obj/sys/arch/amd64/compile/DEBUG_KERNEL/netbsd-DEBUG_KERNEL.debug` And this seems to align with what is says under the make target ``` kernel.gdb=kconf Build a new kernel with debug information. Similar to the above kernel=kconf operation, but creates a netbsd.gdb file alongside of the kernel netbsd, which contains a full symbol table and can be used for debugging (for example with a cross-gdb built by MKCROSSGDB). ``` I do see that there is a `releasekernel=kconf` target which does create a gzip(1)ed copy of the kernel. It creates a `obj/releasedir/amd64/binary/kernel/netbsd-DEBUG_KERNEL.gz`. In "How to get started hacking NetBSD", I was confused on where .img.gz file come from and was confused by the following command: ``` # Create a disk image. mkdir ~/vm cd ~/obj/releasedir/evbarm-aarch64/binary/gzimg gunzip -c ~/vm/disk.img # Make it a sparse 10 GB image. cd ~/vm dd if=/dev/zero of=disk.img oseek=10g bs=1 count=1 # Make a symlink to the kernel. KERNDIR=~/obj/sys/arch/evbarm/compile/GENERIC64 ln -sfn $KERNDIR/netbsd.img . ``` But booting into QEMU is proving challenging, the slide provided in the video specifies the following But the `-c` flag writes to stdout, and I don't understand why that's needed. Can't I use the uncompressed kernel created with `kernel.gdb=DEBUG_KERNEL`? To boot into Qemu, I have ``` #!/urs/bin/sh /usr/bin/qemu-system-x86_64 \ -kernel = ./obj/releasedir/amd64/binary/kernel/netbsd-DEBUG_KERNEL \ -append = "root=dk1" \ -M virt \ -m 1g \ -drive if=none,file=disk.img,id=disk,format=raw \ # Created with `dd if=/dev/zero of=disk.img seek=10 bs=1 count=1` -device virtio-blk-device,drive=disk \ -device virtio-rng-device \ -nic user,model=e1000 \ -nographic \ -machine 'ubuntu' ``` And this yields the following error" ``` WARNING: Image format was not specified for './obj/releasedir/amd64/binary/kernel/netbsd-DEBUG_KERNEL.gz' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions. qemu-system-x86_64: root=dk1: drive with bus=0, unit=0 (index=0) exists ``` Any suggestions? On Mon, Apr 8, 2024 at 8:05 PM Valery Ushakov wrote: > > [gmail seems to require from senders antispam setup, so I can't reply > directly. it's better to use the mailing list] > > Forwarded Message > Subject:Re: Failing to build a bootable custom kernel > Date: Tue, 9 Apr 2024 02:54:33 +0300 > From: Valery Ushakov > To: Jared Barnak > > > > On Mon, Apr 08, 2024 at 19:16:35 -0400, Jared Barnak wrote: > > > > Install programs, libraries, and documentation into DESTDIR. > > > Few files will be installed to DESTDIR/dev, DESTDIR/etc, > > > DESTDIR/root or DESTDIR/var in order to prevent user supplied > > > configuration data from being overwritten. > > > > So to clarify, userspace programs (the distribution) will be installed > > in `DESTDIR` and `RELEASEDIR` will have the kernel image. Is this > > right? > > Long long time ago NetBSD used to get built and installed directly > into the live running system. That was changed around 1.6 time when > we've got build.sh and crossbuild infrastructure. When DESTDIR was > the root of your system, you didn't want stuff installed in you live > /etc :) > > Unless you are going out of you way, you are no longer building like > that. Instead the system gets built into DESTDIR, and in unpriveleged > mode the ownership and permission info is recorded in a metalog, not > as actual ownership/permissions. > > My guess is that the above paragraph used to talk about your / but was > changed to talk about DESTDIR. It might use some further edits... > > Anyway, "distribution" will get you complete userland built into > DESTDIR. "s
just a 10.0 installation comment
Hello. Thanks and congratulation for 10.0 (again). I installed it last week (VM) and it occurred to me that at one time it asked for a network mechanism, without any help or comment around. I ^D or ^Z, and tried to figure out in the manual (also online, thanks to VM-only), i could simply invoke dhcpcd and the interface was up and running, but after ^D and back at the install thing all bets were off. I have forgotten how i made that great, in the end the "mechanism" was just somehow, magically, "". Any hint for red flag waving idiots like myself would be very much appreciated (for 11.0, then). (I mean, sure, "Stander Z" aka red flag is forgotten German speaking for what female have to go through monthly. Bitter. And bloody.) Thank you. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: IRC
Steffen Nurpmeso wrote in
<20240410190923.scQRM5JN@steffen%sdaoden.eu>:
|pms-...@outlook.com wrote in
| :
||Justin Parrott wrote:
||> Anybody want to talk about an IRC client?
||
||Which one?
||Most people use web-based interface nowadays AFIK.
|
|irssi. On the server it runs as a "boxed" proxy (for libera.chat
|via TLS and "SASL"), to which i connect via VPN.
|In my .irssi/startup i have
|
| LOAD perl
| SCRIPT LOAD adv_windowlist
|
|(only script in ~/.irssi/scripts) which is a great thing i could
|not live without. (Or, better, it should be part of the program
|as such.)
Ie: on the laptop. On the server it is "LOAD proxy", and
3153 root 0:00 /usr/bin/unshare --ipc --uts --pid --fork --mount
--mount-proc /usr/sbin/chroot /tmp/.boxircp-steffen/root /init
and with init being (all that build during service startup and
dependent on the used unshare/(su(do)|doas|..) infrastructure):
#!/bin/sh -
[ -n "y" ] && /bin/mount -n -t proc -o nosuid,nodev,noexec proc /proc
if [ -n "" ]; then
arg1="-u steffen"
arg2=
else
arg1='-p -c'
arg2=steffen
fi
exec /usr/bin/su ${arg1} sh -c '
dtach -n /tmp/.steffen-irssi /usr/bin/irssi
read x < /linger_control
pkill -TERM /usr/bin/irssi
sleep 1
pgrep /usr/bin/irssi && pkill -KILL /usr/bin/irssi
echo done > /linger_control
' ${arg2}
Yes it is hacky (but portable to busybox-only once i did it) and
so, but i can even enter irssi on the server when i am there via
ssh (but only windowlist, then). Works for four years i think.
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: Failing to build a bootable custom kernel
On Wed, Apr 10, 2024 at 15:04:51 -0400, Jared Barnak wrote: > for now. It works (I think), but I don't have any gunzipped images. Do you mean installation images? Like http://ftp.netbsd.org/pub/NetBSD/NetBSD-10.0/images/NetBSD-10.0-amd64-live.img.gz I was under impression you only need a custom kernel, so why waste time rebuilding everything when you can grab it from CDN/releng? :) > In "How to get started hacking NetBSD", I was confused > on where .img.gz file come from and was confused by the > following command: > > ``` > # Create a disk image. > mkdir ~/vm > cd ~/obj/releasedir/evbarm-aarch64/binary/gzimg > gunzip -c ~/vm/disk.img > # Make it a sparse 10 GB image. > cd ~/vm > dd if=/dev/zero of=disk.img oseek=10g bs=1 count=1 > # Make a symlink to the kernel. > KERNDIR=~/obj/sys/arch/evbarm/compile/GENERIC64 > ln -sfn $KERNDIR/netbsd.img . > ``` > > But booting into QEMU is proving challenging, the slide provided in the > video specifies the following > > But the `-c` flag writes to stdout, and I don't understand why that's > needed. Can't I use the uncompressed kernel created with > `kernel.gdb=DEBUG_KERNEL`? The command in that example takes a complete installed system image from the release dir (if you grab it from cdn/releng it will be in your downloads dir) and create a disk instance for you VM from it. > gunzip -c < arm64.img.gz > ~/vm/disk.img It uses -c b/c you want the original image from the build process (self-built or downloaded) to be left intact and create an instance that your VM will use. The "> ~/vm/disk.img" redirection does just that. > # Make it a sparse 10 GB image. > cd ~/vm > dd if=/dev/zero of=disk.img oseek=10g bs=1 count=1 But since that image is small, you want to give the system a bit more space, so you write a single byte at 10GB. The disk.img nominally becomes a 10GB file, but the space between the end of the original uncompressed content and that one byte is not actually allocated on the disk, hence such file is called "sparse". The disk blocks for the contents inside that "hole" will be allocated on demand as you use that disk image. > To boot into Qemu, I have > > ``` > #!/urs/bin/sh > > /usr/bin/qemu-system-x86_64 \ > -kernel = ./obj/releasedir/amd64/binary/kernel/netbsd-DEBUG_KERNEL \ [...] > And this yields the following error" > > ``` > WARNING: Image format was not specified for > './obj/releasedir/amd64/binary/kernel/netbsd-DEBUG_KERNEL.gz' and > probing guessed raw. > Automatically detecting the format is dangerous for raw > images, write operations on block 0 will be restricted. > Specify the 'raw' format explicitly to remove the restrictions. > qemu-system-x86_64: root=dk1: drive with bus=0, unit=0 (index=0) exists > ``` (disclaimer: I never tried to run NetBSD/amd64 under qemu. I'm kinda partial to VirtualBox :) I'm not sure netbsd kenel can be direct-booted by qemu with --kernel. The live image should be bootable as a normal disk and it comes with GENERIC already installed. You will have to boot into the VM and install the new kernel inside the VM, I gather. I'm sure there are people on this list that are more knowledgeable about this than I am. -uwe
Re: IRC
pms-...@outlook.com wrote in : |Justin Parrott wrote: |> Anybody want to talk about an IRC client? | |Which one? |Most people use web-based interface nowadays AFIK. irssi. On the server it runs as a "boxed" proxy (for libera.chat via TLS and "SASL"), to which i connect via VPN. In my .irssi/startup i have LOAD perl SCRIPT LOAD adv_windowlist (only script in ~/.irssi/scripts) which is a great thing i could not live without. (Or, better, it should be part of the program as such.) --End of --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: NetBSD 9.3 to 10.0 upgrade failure - check for DOS fs
Hi Martin, Martin Husemann wrote: On Tue, Apr 09, 2024 at 10:28:46PM +0200, Riccardo Mottola wrote: So I have a perfect working 9.3 installation on on an HP ProBook laptop. I boot the CD which works fine Try the BIOS-only install image instead - I bet your system boots the CD via UEFI, but the original installation was BIOS only. Your explanation sounds plausible. However, "UEFI Boot Mode" is disabled in BIOS, I don't know if it is still used by the CD or "detected" somehow anyway. How can I tell further? I did get the "bios image". I see it is USB only? no ISO? Of course my USB Key decided to strike, but I used a spare external hard drive. Much faster to write too :) It boots. but tries to do the same silly thing, fsck a non-existing MS-DOS partition. Yes, this is a bug, the installer should find out and deal with it. Well, I suppose it can find out at least what partitions are there? Other attempts and workarounds? I already have a half-assed system using sysupgrade, so I want to avoid that. My goal was to use this system with the classic upgrade and then maybe compare files like wscons, etc. (Although I already have noticed that the framebuffer uses the silly low-resolution font). Do we have install kernels like I used on OpenBSD before the upgrade tool? download and boot from hard-disk and hope it figures out things better... Riccardo
Re: NetBSD 9.3 to 10.0 upgrade failure - check for DOS fs
Hi, Martin Husemann wrote: Try the BIOS-only install image instead - I bet your system boots the CD via UEFI, but the original installation was BIOS only. when booting from CD, I see: NetBSD/x86 BIOS Boot Revision 5.11 Is this meaningful? Riccardo
Re: NetBSD 9.3 to 10.0 upgrade failure - check for DOS fs
Robert Elz wrote: | no "e" of course... and no MS-DOS in sight. It was already a fully | BSD-ized system. What does fdisk show? (ie: the MBR label). fdisk on wd0 run from the utility shell of the install cd says: 0: NetBSD (sysid 169) bootmenu: NetBSD start 2048, size 625140400, Active 1: 2: 3: Bootselector disabled. First active partition: 0 If I just boot into 9.3 an run it (so I can easily copy it instead of typing it from screen): Disk: /dev/rwd0 NetBSD disklabel disk geometry: cylinders: 620181, heads: 16, sectors/track: 63 (1008 sectors/cylinder) total sectors: 625142448, bytes/sector: 512 BIOS disk geometry: cylinders: 1022, heads: 255, sectors/track: 63 (16065 sectors/cylinder) total sectors: 625142448 Partitions aligned to 16065 sector boundaries, offset 63 Partition table: 0: NetBSD (sysid 169) bootmenu: NetBSD start 2048, size 625140400 (305244 MB, Cyls 0/32/33-38913/80/63), Active 1: 2: 3: Bootselector disabled. First active partition: 0 Drive serial number: 3120074710 (0xb9f88fd6) which seems consistent. Riccardo
Re: NetBSD 10 and framebuffer consoles setup vs 9.3 (font, multiple...)
Hi, comparing to my old 9.3 system and doing some experimenting... I found some difference and have questions. Riccardo Mottola wrote: I used the sysupgrade method for the first time, I hope I didn't mess up with etcupdate step with required a lot of manual work. Also, since the console was in 80x24 mode, checking diff of etcfiles was really cumbersome. I can reboot and login, however my consoles don't behave as expected comapred to 9.3. How can I fix it? Did I miss some configuration? 1) Font size. The framebuffer is enabled (I notice during boot the switch from VGA) but the displayed font gives me 80x24 anyway... how can I do high-res as before (not 8x8 size on VGA, but classic expected framebuffer I got before... this new setup is very unusual) Do I need to mess in wscons.conf? boot.cfg? Here I found that enabling fonts helps. To restore the old behavior, I explicitely need to set: setvar ttyE0 font Terminus16B-ISO8859-1 apparently otherwise something which looks like 32B seems to be used... 2) multiple consoles. ctrl/alt/F1 doesn't open a new login... just the basic console Here I enabled: ttyE0 "/usr/libexec/getty Pc" wsvt25 off secure ttyE1 "/usr/libexec/getty Pc" wsvt25 on secure ttyE2 "/usr/libexec/getty Pc" wsvt25 on secure ttyE3 "/usr/libexec/getty Pc" wsvt25 on secure And now I have all my consoles. 3) basic console behaves strange. login and shell does work, but if I do vi, I cannot navigate, keyboard is mapped wrongly, cursor keys do not work... totally crazy. Also certain promts spit out withyout newline, only carriage-return. Like it is not behaving as vt100? This is a very nasty thing. However, now that I have 4 consoles, I notice that 1,2,3 work fine, it is console 0 that doesn't work well! But it is also... the first one and the only one I had at the beginning. On 10.0 I notice: console "/usr/libexec/getty Pc" vt100 off secure constty "/usr/libexec/getty Pc" vt100 on secure While on 9.3: console "/usr/libexec/getty Pc" wsvt25 off secure constty "/usr/libexec/getty Pc" wsvt25 on secure notice vt100 vs wsvt25? However if I compare dmesg, I see almost the same 10.0 [ 5.876542] wsdisplay0 at radeondrmkmsfb0 kbdmux 1: console (default, vt100 emulation), using wskbd0 [ 6.006667] wsmux1: connecting to wsdisplay0 [ 8.609158] wsdisplay0: screen 1 added (default, vt100 emulation) [ 8.609158] wsdisplay0: screen 2 added (default, vt100 emulation) [ 8.609158] wsdisplay0: screen 3 added (default, vt100 emulation) [ 8.609158] wsdisplay0: screen 4 added (default, vt100 emulation) 9.3 [ 6.442132] wsdisplay0 at intelfb0 kbdmux 1: console (default, vt100 emulation), using wskbd0 [ 6.467386] wsmux1: connecting to wsdisplay0 [ 14.397163] wsdisplay0: screen 1 added (default, vt100 emulation) [ 14.397163] wsdisplay0: screen 2 added (default, vt100 emulation) [ 14.397163] wsdisplay0: screen 3 added (default, vt100 emulation) [ 14.397163] wsdisplay0: screen 4 added (default, vt100 emulation) except intel vs. radeon, they both say vt100, so I am puzzled, it looks as the 9.3 is inconsistent ! Riccardo
Re: NetBSD 10 and framebuffer consoles setup vs 9.3 (font, multiple...)
On Thu, 11 Apr 2024, Riccardo Mottola wrote: Here I found that enabling fonts helps. To restore the old behavior, I explicitely need to set: setvar ttyE0 font Terminus16B-ISO8859-1 apparently otherwise something which looks like 32B seems to be used... There are 2 fonts compiled into the GENERIC kernel by default: $ fgrep FONT_ /usr/src/sys/arch/amd64/conf/GENERIC options FONT_BOLD8x16 options FONT_BOLD16x32 $ and the system will now use the larger font if you have a high enough display. Otherwise, you would end up with an unreadable chars. on, say, 4K displays. While installing, you can escape into the shell, then do: wsconsctl -dw font=Boldface then carry on with the installation. 3) basic console behaves strange. login and shell does work, but if I do vi, I cannot navigate, keyboard is mapped wrongly, cursor keys do not work... totally crazy. Also certain promts spit out withyout newline, only carriage-return. Like it is not behaving as vt100? This is a very nasty thing. However, now that I have 4 consoles, I notice that 1,2,3 work fine, it is console 0 that doesn't work well! But it is also... the first one and the only one I had at the beginning. On 10.0 I notice: console "/usr/libexec/getty Pc" vt100 off secure constty "/usr/libexec/getty Pc" vt100 on secure While on 9.3: console "/usr/libexec/getty Pc" wsvt25 off secure constty "/usr/libexec/getty Pc" wsvt25 on secure notice vt100 vs wsvt25? Is this mis-behaviour seen always or only if you sudo? https://mail-index.netbsd.org/pkgsrc-users/2024/03/23/msg039239.html I see this only when using a recent sudo, and only on constty. -RVP
Re: NetBSD 9.3 to 10.0 upgrade failure - check for DOS fs
On Wed, Apr 10, 2024 at 11:42:22PM +0200, Riccardo Mottola wrote: > Your explanation sounds plausible. > However, "UEFI Boot Mode" is disabled in BIOS, I don't know if it is still > used by the CD or "detected" somehow anyway. > > How can I tell further? Can you boot the original install CD you used, exit the installer and check the output of: sysctl machdep.bootmethod This should either tell you BIOS or UEFI, and this is how the installer decides what kind of setup the booted system later will need. Martin
Re: NetBSD 9.3 to 10.0 upgrade failure - check for DOS fs
On Wed, Apr 10, 2024 at 11:52:04PM +0200, Riccardo Mottola wrote: > 0: NetBSD (sysid 169) > bootmenu: NetBSD > start 2048, size 625140400, Active > 1: > 2: > 3: > Bootselector disabled. > First active partition: 0 Can you show us the /etc/fstab file from the NetBSD partition? Martin
