My experiences with Visopsys install on QEMU virt disk

[andymc]

Thanks Ron,

Ok, yeah that makes more sense now

That list of disks in the installer is 'logical' disks, which for partition-able disks, means partitions. Maybe I should make that a bit more user-friendly and helpful for cases like this. I'll make another note to myself about that one.

[ronaldlees]

The installer works just fine when there's no panic. Click, click and done. But, a person can get caught in a loop if a panic occurs and the disk is partially set up. I went round-and-round for a while myself. Otherwise, with no panic, this thread is entirely unnecessary, and most people could navigate the installation with no issue I think.

This whole project has really progressed well since I last looked at it. Networking will be a very cool addition too, and could make Visopsys viable as a daily driver for some things. I've completely switched to ARM/Odroid XU4 and other similar boards, so need to use QEMU for any x86 OS and programs. Most operating systems run a little sluggishly thru QEMU on those boards - but Visopsys runs very quickly in comparison.

As far as the DHCP thing goes, there must be some "gotcha" that everybody misses. My Photon MCU boards, running FreeRTOS, had the same problem. Just recently Particle issued a patch for the dev libraries, and I have host names on my router now, coming from the Photons. So - maybe something is not correct or clear in the general DHCP documentation about this ...

[andymc]

Hi Ron,

I spent a little while tonight trying to reproduce the DHCP hostname issue, with different VMware network device settings, MAC address. different hostnames and domain names, but I couldn't reproduce this - couldn't get my Linksys router not to see the hostname - it's always whatever it's set to in the Visopsys GUI, though maybe changes don't take effect until after a reboot (this router seems to cache things for a while).

I dunno, maybe I need to go back to the DHCP spec and take a closer look; make sure I haven't missed one of those "gotchas". Perhaps my router is more permissive of something minor, like the absence/presence of NULL character at the end of the string, or what have you. Difficult to debug it here if my router always accepts what I do!

Andy

[ronaldlees]

The DHCP thing is no big deal. I'm just glad it's working. Can't wait for the first of the TCP stuff you've coded, so that I can experiment that ...

[andymc]

Thanks so much for your ongoing interest and support!

This DHCP thing has been bugging me, and also I'm avoiding addressing the one remaining hairy, gelatinous bug that stands between me and an 0.83 release

Could you possibly try this one? https://visopsys.org/files/visopsys/vis ... 08-iso.zip

I've improved (I think) the DHCP option handing, and changed the default behaviour; If Visopsys doesn't have host/domain names set, and the server supplies one, it will use them. Otherwise Visopsys will send them. The previous behaviour was to defer to whatever the DHCP server said, but not apply those values locally. Also got rid of terminating NULL characters when sending names back to DHCP, as I can't see anywhere that says they're required (and my own server doesn't seem to care).

Changing host/domain names in the GUI will still require a reboot to see them show up on the server side, however.

[andymc]

From the DHCP RFC 2132:

Options containing NVT ASCII data SHOULD NOT include a trailing NULL; however, the receiver of such options MUST be prepared to delete trailing nulls if they exist. The receiver MUST NOT require that a trailing null be included in the data.

I guess the NULL characters I've been sending shouldn't have been there, although in theory they shouldn't have caused any problems!

[ronaldlees]

Sure Andy, I'll give it a go tonight.

- Ron

[ronaldlees]

...
Looks good now! Here's the bottom of the router page ...

success-visopsys-in-router.png (11.62 KiB) Viewed 24627 times

So, the null thing must have been the trick.

[andymc]

Super, thanks Ron. Could've been the NULLs, but I suspect your router was sending an auto-generated name, and my DHCP code was just sending it back (i.e. 'accepting' it) rather than replying with its own preferred name. Now it always replaces any auto-generated one in its reply, if a hostname is set locally.

[andymc]

Thanks Ron,

Ok, yeah that makes more sense now

That list of disks in the installer is 'logical' disks, which for partition-able disks, means partitions. Maybe I should make that a bit more user-friendly and helpful for cases like this. I'll make another note to myself about that one.

Hi Ron,

I finally got around to fixing this up in the newly-released 0.9.

The installer now asks which physical disk you want to install to, and then shows the logical disks (partitions) that exist on it, with the option to launch the Disk Manager, as before, to add/change partitions.