On Tue, 14 Nov 2023, Manuel Bouyer wrote:
On Tue, Nov 14, 2023 at 09:55:55AM +0000, Stephen Borrill wrote:On Tue, 14 Nov 2023, Stephen Borrill wrote:On Mon, 13 Nov 2023, Brian Buhrow wrote:hello. If you place an uncompressed copy of netbsd-INSTALL.gz from the kernels directory of a release build as /netbsd on the iso image that you boot from, do you then find you can boot and, then, format and populate the xbd disk that shows up? I've done this to build NetBSD systems under hosted VM offerings, specifically Linode's offerings.I expect this would get the installer going, but without the cd being accessible, I would have to resort to trying to fetch the sets over the network. Lack of access to the ISO library may cause problems later too. In PVH mode, the cdrom device is present in the xenstore at all times, but its status does not change when an ISO image is inserted: # xenstore-read domid 11 # xenstore-ls /local/domain/20/device/vbd [snip] 5696 = "" backend = "/local/domain/0/backend/vbd3/20/5696" backend-id = "0" device-type = "cdrom" state = "1" virtual-device = "5696" Compare this to PV mode. The vbd only appears when the ISO image is inserted, but looks like this: # xenstore-read domid 11 # xenstore-ls /local/domain/11/device/vbd [snip] 51760 = "" backend = "/local/domain/0/backend/vbd3/11/51760" backend-id = "0" device-type = "cdrom" event-channel = "19" protocol = "x86_64-abi" ring-ref = "494" state = "4" virtual-device = "51760" From this it is clear the PVH device is not properly initialised and a clue to this is found in dmesg: xenbus0: ignoring device/vbd/5696 type cdromComparing to a Linux PVH VM, I can see my logic isn't quite right. The device, as listed in the xenstore, is identical to that found on NetBSD. Nothing changes in the xenstore as a result of inserting an ISO. The device is explicitly skipped: https://nxr.netbsd.org/xref/src/sys/arch/xen/xenbus/xenbus_probe.c#455 Is this because xbd doesn't have the concept of 'not ready'?Mainly because (as the commit log says) the emulated device isn't disabled so the virtual cd would show up as both cd0 and an xbd instance.
There is no cd0, but I think the virtual cd shows up as the broken wd0: wd0 at atabus0 drive 0 wd0: <ST506> wd0: 69632 KB, 1024 cyl, 8 head, 17 sec, 512 byte/sect x 139264 sectors wd0d: error reading fsbn 0 (wd0 nb 0; cn 0 tn 0 sn 0), xfer 30, retry 0 wd0: (aborted command)I can confirm that commenting out the code that skips the type=cdrom devices does lead to a hang as described in the commit message, but ONLY if the virtual cd drive is empty, i.e. not ready. If the machine is booted with an ISO inserted, it boots just fine and mount_cd9660 /dex/xbd1a /mnt works as expected. So the problem is more how xbd(4) copes with not ready devices.
However I think that in the same way that the emulated NIC is masked when the PV NIC is present, the virtual cd should be presented as an xbd device.
-- Stephen