# NanoBSD created image does not properly work in Virtualbox



## overmind (Jan 22, 2014)

Hi,

I am trying to build a nanobsd.sh image on FreeBSD 10.0 i386 and then to convert it to a VirtualBox hard drive image.

The converted image does not have a proper third partition which is data partition in a nanobsd image.

After booting the image in a VirtualBox machine:


```
Trying to mount root from ufs:/dev/ada0s1a [ro]...
mount: /dev/ada0s3: Invalid argument
mount -o ro /dev/ada0s3 /conf/default/etc failed: dropping into /bin/sh
```

It seems the third partition (the one that holds the data for config files) has errors on it:


```
# disklabel /dev/ada0s3
disklabel /dev/ada0s3
disk label: /dev/ada0s3: no valid label found
```

In my nanobsd.conf I have (20MB for data partition):


```
NANO_MEDIASIZE=2097152
NANO_DATASIZE=40960
NANO_IMAGES=2
```

The image was converted to a VirtualBox hard drive image using:

`# VBoxManage convertfromraw --format VDI source.img destination.vdi`

For VirtualBox host I use OSX Mavericks.

I think the nanobsd.sh script does not properly calculate the size for third partition.


----------



## asteriskRoss (Feb 3, 2014)

*Re: Nanobsd created image does not properly work in Virtualb*

Looking at the /usr/src/tools/tools/nanobsd.sh script on 9.2-RELEASE (I do know you're using 10.0-RELEASE, but I'm expecting it hasn't changed much, if at all), I wouldn't expect that /dev/ada0s3 would return a valid label from a bsdlabel(8) query.  I would expect /dev/ada0s3 to be a UFS filesystem.

Let's eliminate the possibility that the conversion to a VirtualBox image has caused the problem.  On the FreeBSD machine you used to generate the NanoBSD image, let's take a look at the image.  Using mdconfig(8) we can access the contents of the image file (this assumes you used the NanoBSD defaults for working directories and file names):

```
# mdconfig -a -t vnode -o readonly -f /usr/obj/nanobsd.full/_.disk.full -u 99
```

If the command runs successfully, this should have created the device /dev/md99.  Let's have a look at how your image has been partitioned.  I would expect to see (my annotations after # character):

```
$ ls /dev/md99*
/dev/md99
/dev/md99s1
/dev/md99s1a    # <--- first NanoBSD partition
/dev/md99s2
/dev/md99s2a    # <--- second NanoBSD partition
/dev/md99s3     # <--- /cfg partition
/dev/md99s4     # <--- /data partition
```

You can take a look at the contents of the configuration partition by mounting it:

```
# mount -t ufs -o ro /dev/md99s3 /mnt
# ls /mnt
```

The log file relating to the image generation would be found at /usr/obj/nanobsd.full/_.di.  It will be quite long as it lists all the copied files but also logs the filesystem creation.  Is there anything in there that is not what you were expecting?

To ascertain whether the issue is with the NanoBSD image itself, you could create a virtual machine with associated hard disk in VirtualBox and then write the NanoBSD image to a virtual disk from within it; this would avoid using the VBoxManage tool to perform a conversion.  Alternatively you could write the image to a real disk and see whether it boots properly on a real machine.


----------



## overmind (Feb 3, 2014)

*Re: Nanobsd created image does not properly work in Virtualb*

I've followed your instructions and it seems the problem is with nanobsd.sh script, and not with virtualbox.


```
# ls /dev/md99*
/dev/md99	/dev/md99s1	/dev/md99s1a	/dev/md99s2	/dev/md99s2a	/dev/md99s3
#
# mount -t ufs -o ro /dev/md99s3 /mnt
mount: /dev/md99s3: Invalid argument
```

I think the problem is with partition size compute and it might be from FreeBSD 10.x and not from the nanobsd.sh script.

I will use nanobsd.sh script from FreeBSD 9.2 and see if it works.

It might be the issue described here:  http://freebsd.1045724.n5.nabble.com/nanobsd-dd-problem-tt5866880.html#none . The issue is on FreeBSD 11.x


----------



## overmind (Feb 3, 2014)

*Re: NanoBSD created image does not properly work in Virtualb*

I've used nanobsd.sh script from FreeBSD 9.2 and it seems to work.

Here is a diff comparing nanobsd.sh scripts from FreeBSD 9.2 and FreeBSD 10:


```
# diff nanobsd_92.sh nanobsd_10.sh
362,363c362
< 	rmdir tmp || true
< 	rm tmp || true
---
> 	test -d tmp && rmdir tmp || rm -f tmp
416,421c415,421
< 	test -z $2 && dir=${NANO_WORLDDIR}/var/empty
< 	test -d $dir || dir=${NANO_WORLDDIR}/var/empty
< 	echo "Creating ${dev} with ${dir} (mounting on ${mnt})"
< 	newfs_part $dev $mnt $lbl
< 	cd ${dir}
< 	find . -print | grep -Ev '/(CVS|\.svn)' | cpio -dumpv ${mnt}
---
> 	echo "Creating ${dev} (mounting on ${mnt})"
> 	newfs_part ${dev} ${mnt} ${lbl}
> 	if [ -n "${dir}" -a -d "${dir}" ]; then
> 		echo "Populating ${lbl} from ${dir}"
> 		cd ${dir}
> 		find . -print | grep -Ev '/(CVS|\.svn)' | cpio -dumpv ${mnt}
> 	fi
543c543
< 		dd if=/dev/${MD}s1 of=/dev/${MD}s2 bs=64k
---
> 		dd conv=sparse if=/dev/${MD}s1 of=/dev/${MD}s2 bs=64k
567c567
< 		dd if=/dev/${MD} of=${IMG} bs=64k
---
> 		dd conv=sparse if=/dev/${MD} of=${IMG} bs=64k
572c572
< 		dd if=/dev/${MD}s1 of=${NANO_DISKIMGDIR}/_.disk.image bs=64k
---
> 		dd conv=sparse if=/dev/${MD}s1 of=${NANO_DISKIMGDIR}/_.disk.image bs=64k
590a591
> 	true
```


----------



## asteriskRoss (Feb 4, 2014)

*Re: NanoBSD created image does not properly work in Virtualb*

I agree that it is looking like the VBoxManage utility is not the source of your issue.  The described issue you found certainly looks a lot like the issue you're experiencing.  Did you try applying the patch to the kernel the thread talks about?

You said the partition size for the /cfg partition is wrong.  What size were you expecting and what size do you get?  Can you also see the incorrect partition size in the _.di log file?

Thank you for posting the changes to NanoBSD.  You said the nanobsd.sh script from 9.2-RELEASE worked.  Does that mean you now have a working NanoBSD image based on 10.0-RELEASE?  Did you run the script on a 9.2-RELEASE installation or a 10.0-RELEASE installation?  If the latter, I wonder whether editing the nanobsd.sh script from 10.0-RELEASE to remove the conv=sparse argument from all the calls to dd(1) may offer a workaround for you without needing to patch and rebuild the kernel.  I offer no guarantees, of course  

As an alternative workaround, I believe it should be possible to use a 9.x installation to build a NanoBSD image based on 10.0-RELEASE, 10-STABLE or 11-CURRENT using the appropriate source tree (which includes the nanobsd.sh script), though I've not tried it myself.  If you are installing packages for the image you will likely need to install ports-mgmt/pkg on the 9.x build system.


----------



## MalnPr0 (Apr 8, 2014)

*Re: NanoBSD created image does not properly work in Virtualb*

I was beating my head against a wall trying to get NanoBSD working with 10. I had a functional 7.3 image and had luck rebuilding that one but not with version 10. Luckily I stumbled across this thread.

I tested the proposed patch against /sys/kern/vfs_bio.c without any luck. I removed "conv-sparse" from nanobsd.sh on my FreeBSD 10 host build server and was able to successfully install NanoBSD on a Dell R320.


```
diff nanobsd.sh.bak nanobsd.sh
543c543
<               dd conv=sparse if=/dev/${MD}s1 of=/dev/${MD}s2 bs=64k
---
>               dd if=/dev/${MD}s1 of=/dev/${MD}s2 bs=64k
567c567
<               dd conv=sparse if=/dev/${MD} of=${IMG} bs=64k
---
>               dd if=/dev/${MD} of=${IMG} bs=64k
```

Thank you!!!!!!!!


----------



## junovitch@ (Apr 9, 2014)

*Re: NanoBSD created image does not properly work in Virtualb*

I tried this command on my image.
`VBoxManage convertfromraw --format VDI source.img destination.vdi`

The image boots just fine.  Perhaps not setting sizes properly in advance is causing issues.  I would highly recommend that you do set sizes in advance though as will be far more future-proof for when you update the secondary partitions.

Here is my config for a 16 GB drive:

```
# ada0: 15104MB (30932992 512 byte sectors: 16H 63S/T 16383C)
NANO_DRIVE=ada0
NANO_MEDIASIZE=30932992
# 3 GB Data partition
NANO_CODESIZE=6291456
# Zero out second disk partition for better compression
NANO_INIT_IMG2=0
# 512 MB Reserve for CONF partition
NANO_CONFSIZE=1048576
# Remainder for Data rw mounted partition
NANO_DATASIZE=-1
```


----------

