gsos wrote on 2026-10-12, 02:36:

It seems you are using --module which is used for usb/iso boot (that retroos still can't read themselves and uses grub to provid […]
Show full quote

It seems you are using --module which is used for usb/iso boot (that retroos still can't read themselves and uses grub to provide the necessary files as a grub module ram disk). For a disk based install use

Copy code to clipboard

1./install.sh --prepare --copy-showcase
2sudo ./install.sh

then you can edit retroos.ini and it persist.

Not sure which is better, since the module installation is what was well documented in the README.md in the "machine" package.

Previously, the CONFIG.SYS resides in the CONFIG folder, and the CONFIG folder in the backing partition takes precedence so I could make persistent changes to the configuration files, even with a module installation.
Now that the ini files reside in the boot partition, and that the RETROOS folder in the base image taking higher priority since it contains all the core stuffs, persistent changes to config is no longer possible with module installation.

Personally I consider module installation a bit easier to maintain, as in most cases I only need to replace the kernel and base image file when updating to a new release. No need to touch other stuffs (that reside in the backing partition) in most cases, unless the update introduces something that needs to be applied to existing files.

And by the way, I wonder if there's any work being done on the scaling of DOS screen when using (GOP) framebuffer.
I'd like to test it with widescreen resolutions, if it's now possible to stretch it instead of maintaining aspect ratio.
For now I'm sticking to a 4:3 resolution that I could use and looks okay for DOS texts, but I've kept the option to use my monitor's native (widescreen) resolution available in case this is ready to be tested.

if you want it as a working os, instead of a demo os where you just try booting it from usb and play around, then use the normal non-module install. The 0.9.0 should have the ability to choose a fat.

gsos wrote on 2026-10-12, 03:52:

if you want it as a working os, instead of a demo os where you just try booting it from usb and play around, then use the normal non-module install. The 0.9.0 should have the ability to choose a fat.

I'm not sure if you've revised the README.md in the "machine" package, but right now, it only documented how to perform module install into an existing Linux GRUB menu.
As of 4431318 I don't see any mention of how to perform a non-module install in the README.md from the "machine" package.

Module install already worked very well in my case, as this way the backing partition can be safely cleaned in case of issues, and I normally don't have to touch anything in the backing partition when updating to a newer release build.
Similar to OpenWrt where one normally uses the read-only squashfs for ROM with a writable partition as overlay. Updating will not touch the writable partition by default unless a wipe is required due to incompatibility.
Performing a factory reset is the same as doing a format/wipe on the writable partition, and everything resets to the original state once the writable partition is cleaned.

EDIT: Looks like you've already updated the documentation with 4fb0e37. Will check how the new install process works once it's up.

Tried installing 0.9.1 and found a problem with machine_install.py.

At line 416 there's a "subprocess.run(["update-grub"], check=True)" line that gets run without checking whether "update-grub" really exists.
In some Linux distros, namely those based on Arch Linux, "update-grub" does not exist and instead "grub-mkconfig" should be used. As a result, the install process is broken at this point.
In grub_module_install.py it correctly checked whether "update-grub" exists before executing that command, and use "grub-mkconfig" in case "update-grub" is not available.
However, the lines in question cannot be used in machine_install.py as-is, so for now I simply commented out the line in question in machine_install.py, and recreate grub.cfg manually later on.

Other than that everything seems good. Bundled showcase files get copied with "--copy-showcase" argument, and core OS files get installed to disk.
The installed instance boots without issues. Just that I'm not sure how update works in the future with this kind of on-disk deployment.

fixed.run ./install.sh --prepare, then sudo ./install.sh with the same C: volume. It switches to the new kernel/runtime and keeps your settings and data.

gsos wrote on 2026-10-13, 02:10:

fixed.run ./install.sh --prepare, then sudo ./install.sh with the same C: volume. It switches to the new kernel/runtime and keeps your settings and data.

Thanks for the fix. I just did an install on a different machine and this time it worked without issues.

Took me a while to understand how the mounting config in BOOT.INI works. Something worth noting.
- The "path" is like a Linux mount point. The kernel disallows any other partition than C: to assume root (/). You can use whatever path you want (e.g. /home/data for a secondary partition for data).
- The "subdir" is the option to use if you want to mount a subfolder of a partition. To mount the root of that partition use "/".
- The virtual CD drive is hardcoded to use D: so it cannot be used for other purposes. Other mounts need to start from E:.

Yes, mostly correct, with two clarifications:

- A mount without a DOS drive letter can occupy /, such as your Linux ext4 partition. You can mount a separate Windows/DOS FAT partition at any available mount path and assign it C:. /home/retroos is just an example. If you assign a DOS drive letter to / itself, it must be C:.
- A: and B: are reserved for floppies, and H: for HostFS. D: belongs at /cdrom; the showcase normally uses G:.

Hmmm... Just looked at NT 4 and it seems to set the APIC LVT Timer initial count for roughly 6Hz (disabling IRQ0 on both IO APIC and 8259A PIC) for some reason (isn't that bad for multitasking?).

I added internet support,although currently only my laptop wifi is supported. I will add more general ethernet support. Currently working on getting the linux personality up to the point that it can stable run my linux apps, so I can compile retroos inside retroos and run codex/claude cli, see attached image for codex in retroos.

Anyway with internet available next projects will be
- Dos modem support
- Null modem com1/2 over internet
- Internet support for windows/os2 personalities

gsos wrote on Yesterday, 03:20:

I added internet support,although currently only my laptop wifi is supported. I will add more general ethernet support. Current […]
Show full quote

I added internet support,although currently only my laptop wifi is supported. I will add more general ethernet support. Currently working on getting the linux personality up to the point that it can stable run my linux apps, so I can compile retroos inside retroos and run codex/claude cli, see attached image for codex in retroos.

Anyway with internet available next projects will be
- Dos modem support
- Null modem com1/2 over internet
- Internet support for windows/os2 personalities

Any plans on optimizing the LVT Timer interrupt path? Right now on UniPCemu (even at 3 MIPS or faster) it's simply too slow to handle it, causing an infinite interrupt storm the moment interrupts are enabled with it enabled (it takes longer to return from an interrupt than the interrupt's 1000Hz period (or way more somehow when I do change the CPU speed to become higher)).

Oh that is what you were implying, I didn't realize that this was the issue. Yes I can see what happens if i go to lower interrupts.