Created at:

Modified at:

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

disklabel(5)

The following message helped me with this, although the problem the guy had was different.

'mbrlabel vs. "Device not configured" - MARC

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

(2014-02-20)

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

tap(4)

bridge(4)

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

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

tech-net: Re: configuring clone interfaces before bridge at boot-time?

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

(2016-03-15)

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

(2019-01-01)

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:

NetBSD/evbarm on Raspberry Pi

dd(1)

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

resize_ffs(8)

I believe it is because Raspberry Pi don't have enough memory to perform the operationg.

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

(2019-01-19)

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! :-)

NetBSD cannot mount ext2fs: "incorrect super block"

When receiving that error when trying to mount a partition formatted with mke2fs, instead of doing mke2fs <device>, try to type the following command: 

    # mke2fs -r 0 -O none <device>

port-cobalt: Update: Can't boot from EXT2FS problems.