Re: Failing to build a bootable custom kernel

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

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 <machine>.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 <arm64.img.gz >~/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