home | tech | misc | code | bookmarks (broken) | contact | README

# NetBSD troubleshooting

## Error Device not configured when mounting partition

When you try to mount a partition you may get an error like Device not configured. cat'ing the partition will also not work:

# cat /dev/wd0k
cat: /dev/wd0k: Device not configured


The reasons can be totally different. If you installed a system in after NetBSD, in this computer, you probably forgot to update the disklabel(5). You can view partitions with the mbrlabel /dev/wd0 command, but you can't view them with disklabel /dev/wd0. NetBSD looks up information about partitions in its disklabel, not mbrlabel. So, all you have to do is to manually update your disklabel with:

# mbrlabel -w wd0


This link helped me with this, although the problem the guy had was different.

## tap device being created after the bridge that it should be attached to

You might have a computer with a tap(4) device and you might also want to attach it to a bridge(4) device (like in a Xen server environment.

When creating configuration files for the tap and bridge devices (the /etc/ifconfig.* files, you might achieve a configuration like the following:

# cat /etc/ifconfig.bridge0
create
!brconfig $int add tap0 up # cat /etc/ifconfig.tap0 inet 10.0.0.1 netmask 0xffffff00 up  But that is not correct. It will create bridge0 before tap0, and it will try to attach a device (tap0) that doesn't exist yet. Instead, just create the bridge and make the attachment in the tap0 configuration file: # cat /etc/ifconfig.bridge0 create # cat /etc/ifconfig.tap0 inet 10.0.0.1 netmask 0xffffff00 up !brconfig bridge0 add$int up


This entry in NetBSD mail list helped me to solve this simple problem.

## diocwdinfo: read-only file system when setting a disklabel on a cgd device

It isn't very clear for me the cause of this problem, but I was trying to setup a cgd device on the first partition on a secondary HDD in my laptop. After I set the first partition to an ordinary filesystem and let cgd on a second one, it worked fine. Maybe there are some problems setting a cgd device on the beginning of the HDD? If you have an idea about that, please, let me know.

## resize_ffs: Can’t map ... bytes for inodes: Cannot allocate memory

NetBSD guys build an image ready to be copied to a Raspberry Pi SD Card. You just have to dd(1) it to the SD Card using another computer, as described in NetBSD/evbarm on Raspberry Pi page.

This image has 1.6 GB, so if you dd it to a larger SD card, at the first boot. It will resize its partition to fill the whole SD card up.

Therefore, you don't have the opportunity to create your own extra partitions.

If you try to use resize_ffs(8) after the first boot, you will receive an error message:

resize_ffs: Can’t map ... bytes for inodes: Cannot allocate memory


I believe it is because Raspberry Pi don't have enough memory to perform the operationg. This link also reports the same.

I tested it with NetBSD 7.0 and Raspberry Pi 2. I don't know if the same is valid for other versions of NetBSD or Raspberry Pi 3 or later (since newer versions have more memory).

One possible solution would be to create your image, but I found a simpler solution: just insert the SD card in another more powerful computer and resize the partitions there.

In my case, after inserting the SD card, I had to:

# resize_ffs -p -s 30183424 /dev/ld0a


Where -s accepts the new size as parameter. This is the number of blocks, where the block for this is 512-byte (always check the resize_ffs man page).

After that, I had to update the disklabel with the correct partition size:

# disklabel -i ld0
a

30183424s
W
y
Q


It's done.

Important

Note the two blank lines for disklabel, which means, "don't change what was already known for disklabel".

## su: pam_start failed

Once, I got the error su: pam_start failed when trying to su within a chroot environment (actually, I was already root but the script I was trying to use, executed su to run other scripts as an unprivileged user).

The problem is that I wrongly changed permissions of the /etc tree, which was not owned by root anymore, but by an unprivileged user. When I returned permissions to root, it worked fine.

Later, I got the same problem because I was also playing with permissions of the /usr directory itself (not child directories). After returning /usr ownership to root, su worked.

A further investigation pointed that, on the first case, the file that should not have changed is /etc/pam.d/other, but nevertheless it is good to not play with /etc nor /usr! :-)