How to set a custom image(or any image for testing)

[Fera95]

Hope you're doing well!

Currently I am looking at your project since I am looking to be able to run linux with a TN5250 emulator such as x3270 on a web browser.

I ran your steps until this:

I would like to run this cd debian or test different cd isos

Could you please give me some guidance on this? and how I could implement it in, for example, localhost:8080/debianTest, because I am not understanding how to execute it, I do not know what previous steps are required or in what order/folders to define what the project requires for my image

[CorruptionVR]

Note: 64 bit architectures are not supported by v86

[chschnell]

Try the 32-Bit Debian i386 release, either the netinst CD [645M] or the full DVD [3.7G].

Not long ago I installed Debian into a 2GB image file but I had to repartition during the installation, Debian takes a lot for the swap parttion by default, I ended up with 1.9G ext4 rootfs and ~246K swap. Use an APT mirror if you want to experiment with the netinst CD, it saves a lot of time. I didn't install any desktop (up to you).

This went fine until I ran a larger apt update/upgrade, it resulted in a disk full error.

I never got around to dig further, but what I'd need to continue would be a way to mount a large writeable HD image (16G?) from a local network server into V86 (internally, 2G is the limit for ArrayBuffer, that's why 2G was my ceiling). I'm not sure about 9p, see here for the reason.

So I never published it, in my opinion Debian is relatively heavy for v86, maybe lighter systems (like buildroot) are more adequate. But this of course depends on your use case.

A few notes, hacks and fixes from within the image:

remove grub os-prober

sudo apt remove os-prober

changes to grub config in "/etc/default/grub"

GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX="acpi=off pnpbios=off nosmp nomce nomodeset console=ttyS0,9600 console=tty0 TERM=dumb"
GRUB_TERMINAL=console
GRUB_GFXMODE=640x480

enable autologin on ttyS0

sudo nano /usr/lib/systemd/system/serial-getty@.service

In section [Service] replace:

ExecStart=-/sbin/agetty -o '-p -- \\u' --keep-baud 115200,57600,38400,9600 - $TERM

with:

ExecStart=-/sbin/agetty --autologin me --keep-baud 115200,57600,38400,9600 - dumb

sudo systemctl daemon-reload
sudo systemctl status serial-getty@ttyS0

remaining boot warnings

MPTABLE: no processors registered!
BIOS bug, MP table errors detected!
mce: Unable to init MCE device (rc: -5)

EDIT: Just in case: I simply created a blank 2G file as the HD image file, and passed that to v86. The Debian installer then partitioned and formatted this disk.

[SuperMaxusa]

v86 have two ways to load the OS:

• using a standard hard drive image, it can be loaded completely or in sectors on-demand into an ArrayBuffer (requires a server with Range header support), works for any guest OSes
• using a 9pfs, it loads files on-demand and has no size limits, also you can upload/download files on the runtime, works on modern Linux

You can find docs about Arch or Alpine setup on 9pfs. There were Debian Bookworm image build scripts, here is a more recent build.

If you don't plan on using the 9pfs, you can install any i686 Linux distribution via QEMU in the usual way:

• create a fixed hard drive image:

qemu-img create -f raw harddrive.img <size in gigabytes>G

• run installation (add -accel kvm if available):

qemu-system-i386 -m 1G -net user,model=ne2k_pci -hda harddrive.img -cdrom InstallCD.iso

---

and how I could implement it in, for example, localhost:8080/debianTest

If you want to use v86 as an embedded page, see examples/arch.html and examples/alpine.html for minimal setup, required v86.wasm, seabios.bin and vgabios.bin.

If you want to use with the UI, add your new profile to the oses array in src/browser/main.js.

Example:

{
    id: "debian",
    memory_size: 512 * 1024 * 1024,
    vga_memory_size: 8 * 1024 * 1024,
     // use this for 9pfs
    filesystem: { baseurl: "/path/to/9pfs", basefs: { url: "/path/to/fs.json" } },
    cmdline: "...",
    bzimage_initrd_from_filesystem: true,
     // or this for hdd image
    hda: { url: "/path/to/harddrive.img" }
}

Then run make build/v86_all.js and go to /?profile=debian to run.

[chschnell]

v86 have two ways to load the OS:

[...]

• using a 9pfs, it loads files on-demand and has no size limits, also you can upload/download files on the runtime, works on modern Linux

You can find docs about Arch or Alpine setup on 9pfs. There were Debian Bookworm image build scripts, here is a more recent build.

Thank you @SuperMaxusa, I'd really like to try 9p out. The deprecated Debian bulid script looks very interesting as a starting point.

I might be a bit confused about 9p/v86, and before I dig in I want to make sure I understand this correctly. Two (uninformed) questions:

Is there a 9p file server for Linux which could serve a writeable image (> 4G) to v86, and would the 9p client in v86 support this as a root file system?

In this post "Can virtfs/9p be used as root file system?" from 5 years ago it states that Debian's package manager apt would not work with 9p. Is this still correct (people should have noticed before)?

[SuperMaxusa]

Is there a 9p file server for Linux which could serve a writeable image (> 4G) to v86, and would the 9p client in v86 support this as a root file system?

It doesn't matter how many or how big the files are, it's like a network file system, your server hosts only the index file and files themselves.
When the guest OS wants to read a file for the first time, v86 loads the file from the server and caches it. All writes remain internally to v86.
For example, the archlinux profile has a 5 GB file system and also loads on-demand.

In this post "Can virtfs/9p be used as root file system?" from 5 years ago it states that Debian's package manager apt would not work with 9p. Is this still correct (people should have noticed before)?

Never tested it, QEMU Wiki recommends mounting /tmp as tmpfs to fix fstat bug.

[chschnell]

Thanks, I've also read up a bit more about 9p and I'm better informed now.

Most importantly though, I do now better understand what I'm looking for (sorry about the confusion!), I dug around nfsroot and BOOTP, then came across iPXE. v86 boots the iPXE CD-ROM ipxe.iso from their website without problems.

It allows me to use an NFS server to serve the guest's entire filesystem (including its kernel), persistent and growable like a physical HDD. This has personal use only (and thus is a bit off-topic, I realize), that "writable HDD" is not to be shared on a public website, but it would for example be easy to create a 9p snapshot from an NFS file system and publish it in the current way.

My NAS happens to support NFSv4.1, has plenty of space left and I've used it in the past as a BOOTP server (for Raspberry Pis), I think I should get it wired up with iPXE. Then I only need to get the Debian file system into the NFS share (I'll try to rsync my v86 Debian image into the NFS directory, but there are other ways, too).

[SuperMaxusa]

Interesting idea, reminds me of diskless booting from Novell NetWare. I'm a little bit worried about the networking speed for this idea, shoundn't there be any problems?

[chschnell]

Interesting idea, reminds me of diskless booting from Novell NetWare.

Yes, iSCSI is another interesting concept I came across.

I'm a little bit worried about the networking speed for this idea, shoundn't there be any problems?

Oh absolutley, I just don't know how painful it is going to be :-)

Luckily, it is not much work to find out. I have to create the network environment for network booting and set up the guest OS accordingly, I don't need to modify v86 to test this.

I think the block cache in the guest OS should lessen the network pain in case of iSCSI, I'm not sure about NFS. Linux uses all available free RAM for the block cache.

Today I read a bit more about iPXE, it features a simple scripting language and is well documented, see kernel and sanboot for two example script commands (just take a quick look at the examples there). When you boot ipxe.iso you can break out into an interactive shell, run a DHCP client and then execute a script by URL, and if you build your own ISO you can even link a custom script to be automatically executed.

I might take a shot at it this weekend.