Mint boot from HOSTFS or fvdi.sys different location

[Jean]

Hi all,

I am building a Docker image for Aranym booting Mint.

The idea is to connect to this Atari machine via VNC protocol and have kind-of remote Mint.

This is promizing, and I would like to improve this a bit:

In order to automate the screen resolution between Mint and VNC viewer, I would need to define the resolution of Atari machine based on the VNC resolution (typically remove some pixels horizontally and vertically to make this more usable).

So I need to change FVDI.SYS file prior to starting Aranym from the container.

However this FVDI.SYS file is in a .img file, I can't map it to the host file system with an usual Docke volume mapping.

So I see 2 ways to work this out:

- Locate FVDI.SYS not on C:\ but somewhere on a HOSTFS

  Is there a way to tell FVDI.PRG to not look into C:\ and is HOSTFS mounted at the time FVDI.PRG starts?

- Start Mint from a HOSTFS, I just tried but does not work, looks like it can't boot from there (removed {PARTITION0] from Aranym config file and defined a HOSTFS for C)

Any idea?

Thanks,

Jean

[Thorsten Otto]

On Dienstag, 17. Oktober 2023 16:46:42 CEST Jean wrote:
> Is there a way to tell FVDI.PRG to not look into C:\

No, it will look into the root of boot drive.

>is HOSTFS mounted at the time FVDI.PRG starts?

If you boot mint via the bootstrap feature, then yes. But then the whole drive
C: will be a host folder, and if you want to mount also an image file, then
you may have to provide an empty one that is seen as BIOS drive C: (but
overridden on the GEMDOS level by the hostfs)

If you boot mint from an image, then no. In that case hostfs.xfs will be
loaded during booting, after the auto folder.

What you can also do is to run a command in the docker container via "docker
exec", that modifies fvdi.sys to your needs, before running mint.

>Start Mint from a HOSTFS, I just tried but does not work, looks like it can't
boot from there (removed {PARTITION0] from Aranym config file and defined a
HOSTFS for C)

You need mintara.prg for this to work (that is the only version that has the
hostfs.xfs built in), then in the aranym config file set:

[GLOBAL]
EmuTOS = emutos-aranym.img
Bootstrap = mintara.prg
BootstrapArgs = DEBUG_LEVEL=1 BOOT_DELAY=0 MEM_PROT=NO INI_STEP=NO
WRITE_BOOT=1

(the BootstrapArgs are used in place of mint.ini)

I use such a setup every day, and usually don't use hardisk images at all.

[Jean]

Hi Thorsten,

thanks for the hint. I must be doing something wrong on my side; I have updated Aranym config file accordingly but Mint boot is wrong, it ends-up with no partition mounted at all:

(mint boot process)

Starting up u:/c/mint/1-19-cur/sh.tos ... error -33

...

Then Emubox shell and from here a simple ls fails with error -33

I have attached my Aranym config file.

BTW, in auto folder I already have mintara.prg, not sure if this is expected.

I removed it from auto folder and referred it correctly from Aranym config file but same outcome.

Also a little bit confused by https://github.com/aranym/aranym/wiki/manual where full path to mintara.prg is provided; but this mintara.prg is a Atari executable right? Not some bootstrap to run with Aranym.

Sorry, I must be doing something abviously wrong but if you can help.

Cheers,

Jean

[Chris Ridd]

I’m pretty sure you have to provide the path to (specifically) mintara.prg, not some other executable.

Chris

--
You received this message because you are subscribed to the Google Groups "ARAnyM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aranym+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/aranym/e5982877-a6cc-4dca-9f9c-33abf46ea389n%40googlegroups.com.

[Jean]

Hi Chris,

I believe this is the case:

in config file;

EmuTOS = /aranym/emutos-aranym-1.2.1/emutos-aranym.img
GMTime = No
TOS =
Bootstrap = /aranym/host_fs/c/mintara.prg

BootstrapArgs = DEBUG_LEVEL=1 BOOT_DELAY=0 MEM_PROT=NO INI_STEP=NO WRITE_BOOT=1

BootDrive =  C

And from the container:

root@2390198549ae:/# ls -l /aranym/host_fs/c/mintara.prg
-rwx--x--x 1 1000 1000 377796 Jan  6  2080 /aranym/host_fs/c/mintara.prg

Cheers,

Jean

[Jean]

And of course:

[HOSTFS]
C = /aranym/host_fs/c/

[WongCK]

Once I played with Aranym with a small C partition.

And I copied most of my Falcon stuff in C drive to it... and it was full.

So I did a hostfs K: drive mapped to a folder on my Windows drive.

Then I use symbolic link (sln) to link a atari folder to hostfs K.

Suddenly I have plenty of space on my C: drive... of course it is using hostfs behind and is the folder in Windows.

So you can make c:/fvdi or whatever folder you want to be on your host drive this way.

HTH

rgds

WongCK

https://groups.google.com/d/msgid/aranym/c45a1048-577a-4ff4-bc59-336b1265a795n%40googlegroups.com

.

[Thorsten Otto]

On Dienstag, 17. Oktober 2023 22:50:38 CEST Jean wrote:
> Bootstrap = /aranym/host_fs/c/mintara.prg

mintara.prg is loaded by aranym, so it does not have to be accessible inside
the host_fs (although that should work too, if the path is correct)

>BTW, in auto folder I already have mintara.prg, not sure if this is expected.

No it does not belong there.

>but this mintara.prg is a Atari executable right?

Yes, but it has to be loaded by aranym (indirectly through the NF BOOTSTRAP
feature issued by emutos), because it is the first thing loaded after emutos,
and at this point neither device drivers nor filesystem drivers are available.

If everything works as expected, you should see messages similar to this using
startup of aranym:

EmuTOS 2023/09/18 loading from '/aranym/emutos-aranym-1.2.1/emutos-
aranym.img'... [OK]
EmuTOS version 1.2.1.1+ 20230918
NF BOOTSTRAP_ARGS(DEBUG_LEVEL=1 BOOT_DELAY=0 MEM_PROT=NO INI_STEP=NO
WRITE_BOOT=1)
NF BOOTSTRAP(/aranym/host_fs/c/mintara.prg -> $0100010c, 536870900)
NF BOOTSTRAP($0100010c, 536499477) -> 371423

[David Gálvez]

One thing you could consider to help you achieve what you want is that
you can build a custom FVDI.PRG which look for fvdi.sys in the path
you need

https://github.com/freemint/fvdi/blob/e242d3c13d9ca9f6ac8828eab47bbed187baa64e/fvdi/engine/loader.c#L1321


> Any idea?
> Thanks,
> Jean

>
> --
> You received this message because you are subscribed to the Google Groups "ARAnyM" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to aranym+un...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/aranym/edcff215-5313-4b8d-9aa4-d70c1d672f39n%40googlegroups.com.

[Jean]

Hi all,

thanks for your inputs; however I'm still having same issue :-(
@Thorsten:
Boot messages I see are like the ones you mention:

NF BOOTSTRAP_ARGS(DEBUG_LEVEL=1 BOOT_DELAY=0 MEM_PROT=NO INI_STEP=NO WRITE_BOOT=1)
NF BOOTSTRAP(/aranym/host_fs/c/mintara.prg -> $0100010c, 536870900)

NF BOOTSTRAP($0100010c, 536493104) -> 377796
But then I get the booting process failing (see attached picture).

In AUTO folder, for working configuration (with FVDI.SYS on C:\ being easymint_c.img), I have:
- mintara.prg (should be mint040.prg BTW but it works)
- nfjpeg.prg
- nvdi.prg

I guess I should remove mintara.prg from AUTO folder in case I use Aranym bootstrap to mintara.prg but no change, still same outcome as attached picture.

@ dgalvez75: problem is that I can change fvdi.prg to load fvdi.sys somewhere else but it should be on a hostfs so I can run a container script to modify it. However hostfs is not accessible at this point without Aranym bootstrapping mecanism. And if bootstrapping mecanism is there, better move whole C: to a hostfs then.

@wonck: I tried a symlink C:\FVDI.SYS --> H:\FVDI.SYS ; it looks it's working but actualy it works after a reboot of the container. Once started, c:\fvdi.sys is as expected but when fvdi.prg started it was using the previous version.So not very satisfying but as Thorsten mentionned at the time fvdi.prg starts, hostfs is not available:-(

 

So still on it...

Cheers,
Jean

[Thorsten Otto]

On Mittwoch, 18. Oktober 2023 15:42:30 CEST Jean wrote:
> In AUTO folder, for working configuration (with FVDI.SYS on C:\ being
> easymint_c.img), I have: - mintara.prg

As already mentioned, *don't put it in auto folder* if you already bootet it
by aranym. That will certainly cause trouble.

- nfjpeg.prg
- nvdi.prg

When booted from hostfs, its safer to run them from mint.cnf via exec. The
bootorder on a host fs is otherwise not predictable (most likely just in
alphabetic order, but that depends on the filesystem)
Also if you plan to use fvdi, you most likely don't need nvdi at all (you can
use them both, but then nvdi is only responsible for the GDOS part, and you
must remove/rename its screen drivers)

Also in the picture it looks like u:\c and u:\h are indeed mounted. Maybe it
is something totally trivial that is going wrong (PATH not set correctly,
UNIX_MODE not set or wrong, missing symlinks in U: etc.

[Jean]

Hi Thorsten,

Here is what I did:

- I have a working configuration using easymint_c.img.

- From Mint, I copy contents of C to a folder on host_fs (host_fs/c)

- From host, I run sudo chmod -R docker:docker host_fs/c to allow docker process to access (as after previous step root is the owner)

- I change Aranym configuration accordingly:

Bootstrap = /aranym/host_fs/c/mint/1-19-cur/mintara.prg

BootstrapArgs = DEBUG_LEVEL=1 BOOT_DELAY=0 MEM_PROT=NO

BootDrive = C

...

[PARTITION0]
Path =
Present = No
PartID = BGM
ByteSwap = No
ReadOnly = No

[HOSTFS]
H = /aranym/host_fs/h/
C = /aranym/host_fs/c/

And I now end-up with the attached screenshot.

What seems strnage is that mint.cnf is read but grep is not found.

As this is coming from easyMint, D is actually where typical Linux stuff is. But D does not mount apparently. Why? It is declared in Aranym config file the same way as for boot on easymint_c.img:

[PARTITION1]
Path = /aranym/easyMint/easymint_d.img
Present = Yes
PartID = LNX
ByteSwap = No
ReadOnly = No

Additional question: if I have Bootstrap line set in Aranym config file, should I have mint040.prg for instance in auto folder?

Cheers,

Jean

[Jean]

Forgot attaching screenshot of previous message.

I tried to do the same with drive D (copy it for Mint to host fs).

Looks like troubles are coming from this D easyMint drive as I now have more see other screenshot).

And I can now see some files.

But Mint wants to perform a filesystem check on a host fs, does that make sense? Not sure this D could be on host fs.

[Thorsten Otto]

On Mittwoch, 18. Oktober 2023 18:32:16 CEST Jean wrote:
> But D does not mount apparently. Why?

Most likely because emutos assigns it the letter C. Thats a problem when you
mix hostfs and images. Solution: configure an empty image that is assigned as
C: (but will not be visible since after boot C: is the hostfs).

[Chris Ridd]

On Wed, 18 Oct 2023 at 17:32, Jean <jlus...@gmail.com> wrote:

Additional question: if I have Bootstrap line set in Aranym config file, should I have mint040.prg for instance in auto folder?

I bootstrap mintara.prg and have *no* auto folder at all. Everything gets started by adding lines to mint.cnf

Chris

[Thorsten Otto]

On Mittwoch, 18. Oktober 2023 18:41:18 CEST Jean wrote:
> if I have Bootstrap line set in Aranym config file, should I have
> mint040.prg for instance in auto folder?

Did you read my previous message?

[Jean]

Hi,

I actually have this in config file:

[PARTITION0]
Path =
Present = No
PartID = BGM
ByteSwap = No
ReadOnly = No

[PARTITION1]
Path = /aranym/easyMint/easymint_d.img
Present = Yes
PartID = LNX
ByteSwap = No
ReadOnly = No

[PARTITION2]
Path = /aranym/easyMint/easymint_e.img
Present = Yes
PartID = BGM
ByteSwap = Yes
ReadOnly = No

So I understand D and E should be mounted but boot process fails without having any drive mounted (boot2.gif). If I move D to hoist fs, it is mounted.

@Thorsten:" Did you read my previous message?"

Yes I did :-) I understand that there should be no programS in AUTO because host fs cannot guarantee the loading order but was not sure if mint should be started from there and mintara is just a trick to enable host fs at boot. Anywway, now it's clear.

[Eero Tamminen]

Hi,

On 18.10.2023 20.22, Jean wrote:
> Yes I did :-) I understand that there should be no programS in AUTO because
> host fs cannot guarantee the loading order but was not sure if mint should
> be started from there and mintara is just a trick to enable host fs at
> boot. Anywway, now it's clear.

mintara.prg *is* MINT (compiled with Aranym specific options).

You do not want to run another MiNT version under MiNT.


- Eero

[Paul Wratt]

@Jean

What Ero said, and other people mention, to _boot_ ARAnyM with MiNT,
use ARAnyM Bootstrap= _or_ Atarist AUTO folder, but not both. However,
It is okay to keep other autostart items inside AUTO folder location,
just remember you _can not_ control the _order_ of files mounted via
HOSTFS settings.

You say you have problems mounting the easymint_d.img :
is it a _partition image_ or a _disk image_ , they are different, and
ARAnyM has seperate entries for both?

BTW, for ARAnyM, are you using EasyMiNT _or_ EasyARAMiNT !

Also, there is absolutely no problem copy easymint_d.img contents to
.../hostfs/d/ (same for E: drive) as long as it is an EXT format,
because permissions are very important. The main reason for keeping it
seperated in an disk / partition image, is that MiNT (EasyMiNT) will
use its _own_ user and groups _names_ , which may not map properly to
HOSTOS user and group _numbers_ , AND MiNT is by default "root"
(without any user login), which may also cause problems accessing your
HOSTFS once Docker is running.

NOTE: the simplest approach to boot ARAnyM to MiNT, is the one taken
by the AFROS Live CD, which is essentially what (collectively)
everyone is trying to say. FWIW Pack 3D uses Falcon compatible AUTO
folder on disk _and_ partition images to boot ARAnyM, where as
BeePi/BeePC/BeeUSB use a mixed approach

BTW, if fvdi.sys _is_ in the HOSTFS, why do you have to wait for
ARAnyM to start before you modify fvdi.sys, you underlying HOSTOS
already has acces to it at that point.

NOTE: After that, he only "trick" part is getting ARAnyM to record
your resolution in its NVRAM file, and for that you need to start
ARAnyM once, then exit it, without booting the ARAnyM VM. If you dont,
the boot process uses a different screen resolution, even though
EmuTOS & MiNT will correctly pick up what has been set in your
fvdi.sys

NOTE: Also, if you know the VNC resolution before you start the Docker
instance, then use and APPEND PIPE to tag on your new resolution to
fvdi.sys, or a variable replacement using HERE STRING that outputs to
.../hostfs/c/fvdi.sys, or use an _inline replace_ on fvdi.sys with SED
COMMAND. each has its only benefits, but the point is the resulting
changes will be discarded when the Docker instance is exited, as long
as you dont make .../hostfs/* a permanent (or a write-back) mount in
Docker

Hope at least some of this was useful

Cheers

Paul

> --
> You received this message because you are subscribed to the Google Groups
> "ARAnyM" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to aranym+un...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/aranym/92fe6f3c-1182-4e2c-8a90-ce756dbd164e%40helsinkinet.fi.
>

[Jean]

Hi Paul,

thanks for your detailled response, here are my responses:

- Got that point, mintara.prg as bootstrap or mint040.prg is auto folder

  However, on the config I have (see below) if I replace mintara.prg by mint040.prg, system is no longer stable (e.g. can't exit) and if I change NVDI to FVDI there is a crash at boot. I know mintara should not be in UATO folder but this is the most stable version I can find.

< is it a _partition image_ or a _disk image_ , they are different, and
ARAnyM has seperate entries for both?>

- I'm using EasyMint; D: is a partition image:

[PARTITION1]
Path = ./easyMint/easymint_d.img

Present = Yes
PartID = LNX
ByteSwap = No
ReadOnly = No

- Basically, I'm trying to dockerize this Aranym setup: http://vision.atari.org/download/Aranym.7z

- I'll have a look at AFROS as a base for having a boot on a host fs

< NOTE: Also, if you know the VNC resolution before you start the Docker
instance, then use and APPEND PIPE to tag on your new resolution to
fvdi.sys, or a variable replacement using HERE STRING that outputs to
.../hostfs/c/fvdi.sys, or use an _inline replace_ on fvdi.sys with SED
COMMAND. each has its only benefits, but the point is the resulting
changes will be discarded when the Docker instance is exited, as long
as you dont make .../hostfs/* a permanent (or a write-back) mount in

Docker>

This is my original goal: change fvdi.sys from Docker. Unfortunatly, I can't make this work with my easymint.

Still a lot o learn on Mint/Aranym boot process option, but will make it at the end!

Cheers,

Jean

[Paul Wratt]

Admittedly I have not used ARAnyM outside current RPi build versions
(same as BeePi, 1.0.1 I think, or 1.1.0), you should not be getting
any instability when running Bootstrap technique, unless you are using
an older MiNT with Memory Protection enabled.

Also the type of ARAnyM you use does make a difference to stability,
-MMU, -JIT, combined or without either. Also there were different
library options for MMU (IIRC)

As for NVDI, I used the approach described in the fVDI docs (or maybe
in fvdi.sys in AFROS LiveCD)

Also, in docker, just mount the partition / drive images byte-swapped
and do the edit then umount them before running ARAnyM. On that note
though, if you have access to the machine, you can always use a local
HD partition / drive in ARAnyM instead of an image file, although, if
you want to distribute a docker "playlist" then HD _image files_ would
be safer. The only reason I used an E: / F: image file, was that I
did not have the spare drives to do it at that time (and the week
after I figured out how to build an original AFROS LiveCD, in 2012, I
lost my 20Gb AtariST+MSX+CP/M Archive drive to direct sun heat, with
_everything current_ on it) - FWIW those image partitions were RAW
(MINIX) (0x80?) & 0x83 (EXT2) both formatted with ext2fs

BTW I still dont understand why you are having a problem accessing
fvdi.sys when using C as a HOSTFS, that is the exact approach I used
with my old setup (based on AFROS LiveCD aranym.cnf). I had scripts
inside my C:\MiNT folder that would change aranym.cnf, fvdi.sys,
mint.cnf, xaaes.cnf and myaes.cnf, which were _all_ on the HOSTFS C:
drive, and those scripts detected if OS was MiNT or HOSTOS (just in
case something getting screwed up and could not boot), so I know what
you are trying to do is totally possible, and practical.

OH, one thing just occurred to me now, AtariST compatible EOL, cant
remember if that affected fvdi.sys or not.

LASTLY, IIRC you need to boot up the AFROS LiveCD, in order to be ably
to copy the aranym.cnf off of it

BTW as of last night, I have my build server up and running, so I can
probably test some docker scripts if you put it up on GitHub or GitLab
or SourceForge .. etc

BTW (again?) I will be wanting to build ARAnyM and both Vincents,
Thorstens & George cross-toolchains for x86_64, armr6, arm7l, arm8,
riscv64 in the coming weeks (if that gives you any ideas)

So, yeah, dont give up yet :)

Cheers

Paul

> https://groups.google.com/d/msgid/aranym/dab23e0a-4b6c-4ebe-a5a5-93e05b97888dn%40googlegroups.com.
>

[Paul Wratt]

here is said config file (from AFROS LiveCD - one of the few things I
still have from that 20G drive) - found it by accident

[Jean]

Hi Paul,

thanks for your response; actually I think my easyMint based setup at http://vision.atari.org/download/Aranym.7z even if damn stable is for some reason not easy to move to a C: host fs to boot on. Also many components are way too old and crashes when used in fulscreen (which is probably the best option see below).

In the meantime I tried another Aranym more simple setup based on Olivier Landemarre and I can boot on a host fs.

Looks promising but I have to add all Linux/network stuff.

Also note that using this last setup I can run Aranym full screen (which causes a crash using the easyMint based distri). That would even avoid touching fvdi.sys.

So I have a couple of options on the table I can look into when back from vacations.

Also need to look into BeePi as this could give me some nice ideas as well.

As you mentionned for Docker, best would be to use disk images to avoid any grant conflict when deploying a host fs to a new host.

Not giving up for sure; need some time to digest more, my goal is of course to share this Docker container with all as soon it is stable and usable.

Cheers,

Jean