>I was under impression you only need a custom kernel, so why waste
> time rebuilding everything when you can grab it from CDN/releng? :)
I am hacking onto the kernel itself and adding driver support. So, I'll
need to compile when I make changes.
> The command in that example takes a complete installed system image
> from the release dir
To get you complete installed system image, you need invoke `build.sh
release`
> 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.
Honestly, I misread the redirection operators ("<" and ">") as an
"insert here" placeholder message.
I created the image with:
```
gunzip -c ./vm/disk.img
dd if=/dev/zero of=disk.img seek=1073741824 bs=1 count=1
```
I think that worked.
> 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.
I got that potion from the slides, which has
```
qemu-system-aarch64 \
-kernel netbsd.img \
-append "root=dk1" \
-M virt \
-cpu cortex-a53 \
-smp 2 \
-m 1g \
-drive if=none,file=disk.img,id=disk,format=raw \
-device virtio-blk-device,drive=disk \
-device virtio-rng-device \
-nic user,model=virtio-net-pci \
-nographic
```
And I'm guessing `netbsd.img` is equivalent to
`/obj/releasedir/amd64/binary/kernel/netbsd-DEBUG_KERNEL`
But really, I'm no closer. I chose QEMU because I've used it for
kernel debugging before and the `-s -S` options are particularly nice.
On Wed, Apr 10, 2024 at 5:45 PM Valery Ushakov wrote:
>
> 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
