add libslirp support

[stsp]

https://gitlab.freedesktop.org/slirp/libslirp/tree/master/src

By reverting 2e28995, we can get the librouter code back, which uses slirp. Or maybe just writing a back-end by hands. Doesn't look too difficult.

[jharrison03]

That would be a bummer if that meant getting rid of VDE.

[jharrison03]

If you want to get rid of some networking component, the kernel ditched IPX, and it's always been slower in Dosemu than using a full NDIS stack over a packet driver.

[stsp]

That would be a bummer if that meant getting rid of VDE.

VDE is already disabled. It needs a dozen of patches that the upstream doesn't take (as there is no upstream at all).

Dosemu than using a full NDIS stack over a packet driver.

Since when have you used NDIS stack over the packet driver? This just doesn't work under dosemu. Maybe you meant ODI and/or IPX over packet driver.

[jharrison03]

I meant ODI :), and I use VDE right now.

loadhigh \nwclient\lsl.com
loadhigh \net\pktdrv\pdether.exe
loadhigh \nwclient\ipxodi.com /d
loadhigh \nwclient\vlm.exe /v0

[jharrison03]

$_pktdriver = (on) $_vnet = "vde" $_vdeswitch = "/var/run/vde2/vde0.ctl"

...

PKT: Using device /var/run/vde2/vde0.ctl PKT: VNET mode is 3 66:62:78:32:7c:58:

[stsp]

Arch? Arch guys are quite active, apply patches and re-enable old stuff. :)

[jharrison03]

I've always enabled it explicitly in the build, not knowing there was any particular problem with it. It works well here, at least.

[stsp]

OK, so if they moved from sourceforge, I can try to submit the patches also here, maybe that will help... Thanks for the pointer.

[bolle732]

@jharrison03 How does VDE(2) behave from a user perspective ? Does it need "root" rights ? Can it be installed once and how well does it adapt to changing networks for a mobile user ?

The advantage of slirp is, that it has integrated DHCP / DNS services. I've seen, that there is a slirpvde, but I've never used it.

[jharrison03]

@bolle730,

VDE doesn't need root privileges. I'm using it with a bridged IPX Novell network along with QEMU that ultimately goes out over hardwire, so IP-specific protocols like DHCP or DNS doesn't apply in my particular use case.

[jharrison03]

The whole thing works very nicely now and I would hate to lose this. I would imagine I would need to use TAP on both the QEMU and Dosemu clients if this disappeared.

[stsp]

I think only ubuntu currently provides vde2. Fedora does not. If your favourite distro does provide it and you can always re-build dosemu2 from sources, then lets say you won't lose anything. :)

[stsp]

libslirp support added. Still needs to figure out why dhcp doesn't seem to work, and add some config knobs.

[stsp]

But I only managed to build this on focal and groovy... @skitt is there any work-around, like BuildRecommends or alike, so that the missing build dep to not result in a permanent failure?

[stsp]

Hi @mateuszviste @tkchia @mceric and other freedos experts. :) dosemu2 supported libslirp for quite some time now, but I didn't enable it. The reason was that I couldn't make its builtin dhcp working with wattcp, following the instructions from here: http://wiki.freedos.org/wiki/index.php/Networking_FreeDOS_-_WATTCP

Today, after some random poking around, I figured out that it works if you set my_ip = bootp whereas your instruction says my_ip = dhcp. But that doesn't work.

Question: was the instruction ever verified? And if so, what can it be? Some fault on dosemu2 side? Wrong version of wattcp on my side? But bootp works perfectly. So may I suspect this is just a typo in your documentation? If so - please correct. :)

[mateuszviste]

Hi, my_ip = dhcp is correct. bootp is a different (simpler) protocol that is meant to attribute an IP and possibly provide a TFTP path to a boot image. IIRC it does not provide DNS servers nor even a default gateway. It is worth noting though that AFAIK WatTCP does not support DHCP, this is something that have been added by Watt32 (which is often called "WatTCP", making things sometimes a little bit confusing). Hence if your test application is using the old WatTCP library and not Watt32, then indeed it won't understand my_ip = dhcp. The same goes for any application that has been linked to a Watt32 library that was compiled without DHCP support (ie. without a #define USE_DHCP).

[stsp]

IIRC it does not provide DNS servers nor even a default gateway.

I think it does: https://tools.ietf.org/html/rfc1497

   It provides a means to assign a host its
   IP address, a file from which to download a boot program from some
   server, that server's address, and (if present) the address of an
   Internet gateway.

It is worth noting though that AFAIK WatTCP does not support DHCP

Then I find it difficult to correlate this with Hi, my_ip = dhcp is correct. statement of yours. :) I think if something isn't supported, it shouldn't be documented as supported.

Thanks for the watt32 note. I tried to D/L it, but the binaries are not for DOS. But it is said that it supports the DOS compilers, so could you please point me where to D/L the DOS binaries? IMHO this all should be said in the docs, including the URL to DOS build. Otherwise ppl get wattcp and can't get the working configuration.

[mateuszviste]

You are correct about bootp and default gateway. Looking further into the RFC I see it even has provisions for DNS servers, which means that perhaps one could use the simpler BOOTP instead of DHCP and not even notice that. I must have misremembered then, or perhaps I got bitten by some incomplete bootp implementation back in the day. I'd be curious to know whether current DHCP servers still support BOOTP and fill in all the fields properly.

As for Watt-32, I have always downloaded it from its homepage at https://watt-32.net/ - if the binaries you have there are windows-only, then I guess Gisle gave up about releasing DOS tools since ver 2.2.11... I know that in recent years he was focusing on Windows only. There are at least two serious problems with this latest version anyway: https://github.com/gvanem/Watt-32/issues/2 https://github.com/gvanem/Watt-32/issues/4

...so you might prefer testing on version 2.2.10 instead. It appears that I have a copy of this older version on my gopher node if you cannot locate it anywhere else: gopher://gopher.viste.fr/1/programming/PC/Networking/WATT-32

If you're only looking for a simple Watt32 application to test things, then you might be interested in my Gopherus: http://gopherus.sourceforge.net/

I still stand by "my_ip = dhcp" being correct. But it works only with Watt32 applications, not the old WatTCP things. Perhaps the FreeDOS documentation could mention that. That being said, I am not writing FreeDOS documentation, so my opinion does not matter anyway.

[stsp]

Looking further into the RFC I see it even has provisions for DNS servers, which means that perhaps one could use the simpler BOOTP instead of DHCP and not even notice that.

It can be done in either case, bacause DNS is 8.8.8.8 these days anyway.

if the binaries you have there are windows-only, then I guess Gisle

There is only one binary package to download. Are the DOS binaries supposed to be within, or I should have found a separate binary package for DOS?

There are at least two serious problems with this latest version anyway:

One of which is still with git?

It appears that I have a copy of this older version on my gopher node if you cannot locate it anywhere else:

I've got your watt32s-2.2-dev.11.zip and it seems to be sources only?

If you're only looking for a simple Watt32 application to test things, then you might be interested in my Gopherus:

Wow man, how cool! This really works, and with both bootp and dhcp, with all other options commented out. Which makes me think that even DNS works with bootp.

I still stand by "my_ip = dhcp" being correct.

So far, only for your gopherus app. :) Its really, REALLY hard to find any other app where that would be correct. So my suggestion (maybe not to you, many ppl are listening) to update the docs properly, as currently they advertise the non-working configuration.

[stsp]

@jschwartzenberg would you like the gopherus and other interesting net tools from here: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/net/

[mateuszviste]

Are the DOS binaries supposed to be within, or I should have found a separate binary package for DOS?

The DOS binaries were always included in the same single zip, so if nowadays the tools are built for windows only, then... no luck. You'd have to build them yourself, or rely on the older "binaries release" version of Watt-32.

I've got your watt32s-2.2-dev.11.zip and it seems to be sources only?

Ah, sorry - yes now I remember I mirrored only the source versions, since I was never interested in binaries anyway. The older v2.2 dev 10 is no longer advertised on the watt32 website, but now I discovered that it is still possible to get it through a direct link: http://www.watt-32.net/watt32b-2.2-dev.10.zip

I looked into that zip and hex-opened a few EXEs, they look like DOS executables.

I still stand by "my_ip = dhcp" being correct.

So far, only for your gopherus app. :) Its really, REALLY hard to find any other app where that would be correct.

Also all the apps shipped with Watt32 v2.2 dev 10. But I totally agree that better documentation is always a nice thing.

[jschwartzenberg]

@jschwartzenberg would you like the gopherus and other interesting net tools from here: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/net/

It would be useful to have fdnpkg working on a default installation, it's the FreeDOS package manager: http://wiki.freedos.org/wiki/index.php/FDNPKG

Then we could simply install that with the Python scripts and install all other tools using fdnpkg running in dosemu2.

[stsp]

I added the net tools myself. We need to set up most used tools by hands, but things like links and gopherus may indeed go to fdnpkg, as they do not go to BIN. Btw, I've notices that after your scripts there is a lot of pollution on drive C: appinfo, doc, help and other dirs. Is it the same when you install freedos by other means, or is this specific to our scripts?

[jschwartzenberg]

Btw, I've notices that after your scripts there is a lot of pollution on drive C: appinfo, doc, help and other dirs. Is it the same when you install freedos by other means, or is this specific to our scripts?

The scripts do it on purpose as those files were also in the same spots in the dosemu1 freedos tarball and directory layout. The scripts filter out some directories too like the source directories.

My proposal would be to only install fdnpkg through a script and install everything else though that. I think that should work.

[mateuszviste]

My proposal would be to only install fdnpkg through a script and install everything else though that. I think that should work.

The idea is very nice, but as the author of FDNPKG I would rather recommend NOT using it, as it is an end of life product. Instead, I'd recommend using SvarDOS with its (simpler, cleaner) pkg subsystem. http://svardos.osdn.io/ I am very willing to assist with necessary SvarDOS adaptations if needed.

[mateuszviste]

dosemu2 supported libslirp for quite some time now, but I didn't enable it.

As a side note, could you please tell how/where I could obtain such libslirp-enabled dosemu? As of today I am still using an ancient (2013) version of dosemu that I have compiled with my own slirp+taprouter kludge. It works, but I'd gladly upgrade to the latest dosemu2 since I know you did a lot of awesome improvements during the last decade.

[jschwartzenberg]

My proposal would be to only install fdnpkg through a script and install everything else though that. I think that should work.

The idea is very nice, but as the author of FDNPKG I would rather recommend NOT using it, as it is an end of life product. Instead, I'd recommend using SvarDOS with its (simpler, cleaner) pkg subsystem. http://svardos.osdn.io/ I am very willing to assist with necessary SvarDOS adaptations if needed.

Actually that would mean we should use pkgnet instead?

[mateuszviste]

The idea is very nice, but as the author of FDNPKG I would rather recommend NOT using it, as it is an end of life product. Instead, I'd recommend using SvarDOS with its (simpler, cleaner) pkg subsystem. http://svardos.osdn.io/ I am very willing to assist with necessary SvarDOS adaptations if needed.

Actually that would mean we should use pkgnet instead?

Exactly, yes - pkgnet for finding and fetching the package, and then pkg for installing/removing it.

I could prepare some minimalistic SvarDOS image that would allow to boot up dosemu and then use it as a normal SvarDOS install, if Staś would be open to using such "non-vanilla" FreeDOS distro.

[stsp]

Hi guys.

So first, I tried the freedos-packaged tools, like ping, and they indeed work fine with dhcp. So I agree the documentation is mostly correct. It should only mention that if you got wattcp elsehwere, you should use bootp instead.

As a side note, could you please tell how/where I could obtain such libslirp-enabled dosemu?

Its not only I can tell, but its written in our home page: http://dosemu2.github.io/dosemu2/ It references the fedora and ubuntu builds.

As for packages. We have more than one usage scenario. Basic scenario is when you run completely freedos-free. More advanced scenario is when you install the essential user-space tools with this script: https://github.com/dosemu2/install-freedos which is also packaged in rpm/debs. These two scenarios are the main ones, and of course we can add the svardos to the list of the essential tools if it is available in the freedos archives on ibiblio. But there is probably nothing else to do in these scenarios, other than to make sure that svardos works properly.

We also envisioned the fully-freedos scenarios. But currently they are the second-class citizens, and for them we just install the freedos kernel and more tools. This is the same as with any "other-DOS" scenario - we have scripts to install some other DOSes here: https://github.com/dosemu2/install-otherdos This is where the ready-to-use image can get handy. I am perfectly fine with replacing the current "install-freedos-kernel" procedure with "install svardos image".

What does this image mean? We usually boot from the directory structure, not from the real images. So perhaps you can just update the scripts to extract your svardos image?

On the same topic. We currently don't have any mechanism to quickly install DOS games. I don't think svardos can help with that, or maybe it can? That would be the much more interesting use-case, as I really suspect there are not too many people out there who care about having the full stack of freedos software with GUIs etc. No one uses those. :) But if we can get games into the picture, everything changes.

[stsp]

My proposal would be to only install fdnpkg through a script and install everything else though that. I think that should work.

In "other-DOS" scenario, which also includes "full-freedos", anything can work. But in freedos-userspace scenario I don't like such idea, as that scenario should consist of a blob-free installer only. Also think about the deployment tools like MAAS: they do not rely on the guest OS usually IIRC. They just make things available with PXE and nfs. This is much simpler, faster and more reliable than to fiddle with the guest OS's side.

[mateuszviste]

So perhaps you can just update the scripts to extract your svardos image?

The SvarDOS image is in fact a set of diskettes (or CDROM image, or USB pendrive image) that is meant to install SvarDOS onto a PC or VM. I believe this is not what DOSEMU expects -- it should rather obtain some minimalist "preinstalled" set of files. I will see to prepare such bundle, should be easy enough.

We currently don't have any mechanism to quickly install DOS games. I don't think svardos can help with that, or maybe it can?

It depends whether or not those games may be legally distributed. If yes, then SvarDOS can include them in its repository so they can be easily installed. The project's rules about that are much more flexible than what vanilla FreeDOS requires, but I still must abide by the law. Exact rules are here: http://svardos.osdn.io/phpamb.php?fname=help/help-en.amb&f=pkgrules.ama

Now, if you refer to some commercial games from the 90s, then I am afraid there is no legal way to distribute them, except for the few that went open-source at some point or another. A possibility would be to distribute only shareware/demo versions of these commercial titles, but I am unsure that people will actually like that... although maybe?

Mateusz

[stsp]

The idea is not to distribute the games, but rather to have the installer that get them from the existing collections, that are many. I believe this doesn't put any law "pressure" on yourself. You can have a check-box like "enable the non-free repos with games". And whoever doesn't click that, will have to live with demos/free games only. :)

[stsp]

it should rather obtain some minimalist "preinstalled" set of files. I will see to prepare such bundle, should be easy enough.

I think this mainly mean replace our installer scripts with some others, and replace the ibiblio/freedos collection with something else, right?

[mateuszviste]

The idea is not to distribute the games, but rather to have the installer that get them from the existing collections, that are many.

Then no, SvarDOS will be no help indeed, as it expects specifically crafted packages and cannot operate on anything else. That being said, I like the idea. I will see if I can easily hack something that would provide "games metadata", and based on that pkgnet+pkg would be able to work with a stupid "dump" of files. I will explore the idea, perhaps something cool could come out of this.

it should rather obtain some minimalist "preinstalled" set of files. I will see to prepare such bundle, should be easy enough.

I think this mainly mean replace our installer scripts with some others, and replace the ibiblio/freedos collection with something else, right?

It could mean that, yes, but I do not think that duplicating the build scripts that SvarDOS already has is an efficient thing to do. Instead, I'd prefer SvarDOS building some "dosemu-special" set of files that dosemu would only have to unzip and boot off from. I will tinker with that and get back here once I have something working.

[jschwartzenberg]

My proposal would be to only install fdnpkg through a script and install everything else though that. I think that should work.

In "other-DOS" scenario, which also includes "full-freedos", anything can work. But in freedos-userspace scenario I don't like such idea, as that scenario should consist of a blob-free installer only. Also think about the deployment tools like MAAS: they do not rely on the guest OS usually IIRC. They just make things available with PXE and nfs. This is much simpler, faster and more reliable than to fiddle with the guest OS's side.

My main motivation for this would be to do it because we could share more code with other DOS environments. The current solution is specific to dosemu and will thus get less maintenance. If however someone else's cool package manager could be installed through our script, then when that package manager gains repos/packages/features, we essentially get them for free.

[stsp]

I'd prefer SvarDOS building some "dosemu-special" set of files that dosemu would only have to unzip and boot off from.

But this is similar to what we do now. :) We use the set of zip files at ibiblio. Our scripts only D/L them and unzip. So yes, indeed you'll replace our scripts with something else, and that's fine if it works.

I will see if I can easily hack something that would provide "games metadata",

See the dosbox-oriented collections. That likely already have some metadata, and definitely provide the games in some uniform way.

[stsp]

If however someone else's cool package manager could be installed through our script, then when that package manager gains repos/packages/features, we essentially get them for free.

There is nothing against adding the package manager to the set of the installed tools. It just shouldn't be essential for the freedos-userspace scenario. Note that there is really a very little possible use for any package manager here, because all we do, is to D/L the files from ibiblio and unzip. Package manager will do the same thing, no added benefits, and depending on a blob to get the freedos-userspace installed, is a very big drawback.

[mateuszviste]

Note that there is really a very little possible use for any package manager here, because all we do, is to D/L the files from ibiblio and unzip. Package manager will do the same thing, no added benefits

The package manager will actually do more: it will download the package, make sure there is no collisions with existing files, extract it to a user-specified directory (eg. games go into C:\MYSTUFF\COOLGAMES, while drivers may go to C:\SYSTEM\DRIVERS) and it will also allow the user to periodically check whether or not there is an updated version of the package, and of course it will make it easy to remove the package in a clean way from the system.

Anyway, I prepared a little SvarDOS-DOSEMU image, it may be downloaded here: http://svardos.osdn.io/download/svardos-dosemu.zip

Once downloaded, one needs to do this: unzip svardos-dosemu.zip -d ~/.dosemu/drives/c/

Make sure the drives/c directory does not exist already of course.

Unfortunately when I run "pkgnet search something", I get an error message saying "no packet driver found", I assume this is because I installed DOSEMU2 from the latest pre-built rpm, where the slirp option is not compiled in (yet). Will have to fiddle with that later.

The svardos-dosemu image is part of the svardos build process now, which means that whenever svardos is updated, the image will be updated as well. The exact part that computes this is here: https://osdn.net/projects/svardos/scm/svn/commits/321

[stsp]

The package manager will actually do more

Yes, I agree: our scripts are much simpler, as they only install the fixed set of software. So no choices, no removals, no updates, no blobs. I'd like to keep it that way because the simplicity is good. But if you can make it so that the package manager can work after our scripts, i.e. customize/remove/update what our scripts installed, that would be great.

Anyway, I prepared a little SvarDOS-DOSEMU image, it may be downloaded here:

Thanks. Would you like to also update the https://github.com/dosemu2/install-otherdos with the pull request, so that I can try out all together? Currently this install-otherdos depends on a scripts in install-freedos, which is bad. It seems you can solve that, as obviously to D/L your image, nothing is needed from install-freedos repo.

because I installed DOSEMU2 from the latest pre-built rpm, where the slirp option is not compiled in (yet).

That's quite strange, as the rpm rebuilds are instant, per every commit. If you have dosemu2-0.0.git.2472.cf292dcf-1 and no packet driver, we need to investigate. But I suspect you still have some custom config which probably enables tap or something instead of slirp?

[mateuszviste]

I'd like to keep it that way because the simplicity is good. But if you can make it so that the package manager can work after our scripts, i.e. customize/remove/update what our scripts installed, that would be great.

When the packager (either the old FDNPKG or the ancient FDPKG or the newer PKG) installs a package, it takes care to save a listing of all the files that have been installed within the user's system. Your method does not do that, so there is no way to know what files belong to what "package" (or to know that such a package is installed at all). That would be like dumping a random tar.gz into your Linux system and expecting rpm or apt-get to figure out what to do with that.

Would you like to also update the https://github.com/dosemu2/install-otherdos with the pull request, so that I can try out all together?

I will look into this tomorrow, should be simple (I guess) since the entire operation is about doing a single wget + a single unzip.

That's quite strange, as the rpm rebuilds are instant, per every commit.

I used the rpm from https://github.com/dosemu2/dosemu2/releases but now I see that I probably should have used one of the "daily build" instead of following the "pre-alpha build" link... It's not easy to find the correct rpm :) Tried it now, but ooops my package manager (OpenSUSE) does not seem happy with the rpm:

The rpm I tried is from there: https://download.copr.fedorainfracloud.org/results/stsp/dosemu2/fedora-34-x86_64/02167580-dosemu2/dosemu2-0.0.git.2472.cf292dcf-1.fc34.x86_64.rpm

I have forced the package to be installed but I still get into troubles: mateusz@mateusz:~> dosemu bash: /usr/bin/dosemu: /usr/bin/bash: bad interpreter: No such file or directory mateusz@mateusz:~/Downloads> which bash /bin/bash mateusz@mateusz:~/Downloads>

mateusz@mateusz:~> dosemu.bin dosemu.bin: /lib64/libm.so.6: version GLIBC_2.29 not found (required by dosemu.bin) dosemu.bin: /lib64/libc.so.6: version GLIBC_2.27 not found (required by dosemu.bin) dosemu.bin: /lib64/libc.so.6: version GLIBC_2.33 not found (required by dosemu.bin) dosemu.bin: /lib64/libc.so.6: version GLIBC_2.28 not found (required by dosemu.bin) dosemu.bin: /lib64/libc.so.6: version GLIBC_2.32 not found (required by dosemu.bin) mateusz@mateusz:~>

Obviously all this is because I try installing an RPM from one distro on a different distro... Well, life's not easy. I will sort this out tomorrow, but the important thing is that indeed I was testing an old release of DOSEMU, so hopefully the latest one will be good.

[stsp]

listing of all the files that have been installed within the user's system. Your method does not do that

Indeed. How difficult is for your package manager to re-create the metadata from, for example, the list of URLs from where we got the archives? Or for example from appinfo/*.lsm?

I used the rpm from https://github.com/dosemu2/dosemu2/releases

OK, unlinked that now.

Obviously all this is because I try installing an RPM from one distro on a different distro...

You can try rpm for older fedora. https://download.copr.fedorainfracloud.org/results/stsp/dosemu2/fedora-32-x86_64/02167580-dosemu2/dosemu2-0.0.git.2472.cf292dcf-1.fc32.x86_64.rpm This is for fc32.

[mateuszviste]

Indeed. How difficult is for your package manager to re-create the metadata from, for example, the list of URLs from where we got the archives? Or for example from appinfo/*.lsm?

You mean guessing what packages the DOSEMU maintainers may or may not have dumped into the filesystem (partially or not), assuming that they used a specific URL at some given point of time and that said packages never changed afterwards AND that the maintainers used some well-known, hardcoded paths to install the programs? Well, the package manager would have to be really smart for such a feat, and quite complex, too - and the entire thing would be very easy to break anyway. One of the values of the new pkg system is that it is extremely simple, and - let me quote a wise man here - "I'd like to keep it that way because the simplicity is good." ;-) The package manager thing is an all-or-nothing deal, just like on Linux: either you use it and do not fiddle with installing stuff by hand, or you don't use it and do whatever you wish. Both approaches are fine, but one cannot mix them together and expect things to stay consistent.

You can try rpm for older fedora.

Tried that, but even the FC32 rpm fails on my OpenSUSE 15.2 due to some GLIBC versions mismatch.

Now I compiled DOSEMU2 from source using the "zipball master" link from the main page of the project (called simply ".zip"), but still no slirp: mateusz@mateusz:~/Downloads/dosemu2-dosemu2-af7f27b/bin> ./dosemu ERROR: Unknown vnet mode "slirp" I grepped through the longish output of the ./configure script but did not locate any occurrence of "slirp". Am I missing something obvious? To build the thing I followed the instructions from INSTALL, ie: /autogen.sh ./default-configure make

[stsp]

No problem about package manager: we just dont need to include it into freedos-userspace scenario.

You can try make rpm to build an rpm.

[mateuszviste]

my error was stupid: I was fetching the "master zipball" from the project's website, while this apparently leads to an old(er) version of dosemu, without slirp. Now I retrieved a zip dump of the "devel" branch directly from github, and there is slirp. Still unable to boot dosemu, though, now it exits with "ERROR: Drive unbootable, exiting" (but the same configuration works with older versions of DOSEMU). I think I will wait for slirp support to land in a formal release and retry then, there's more hoops than I expected. In any case, my svardos-dosemu image works fine when used when an older dosemu, feel free to rely on it if you wish (myself I will use it as my main dosemu system from now on, and it will be kept autogenerated through the svardos build process)

ps. I tried generating a RPM, but it seems this is possible only when working on a git tree, not from the zip package of the devel branch downloaded from github: $ make rpm fatal: not a git repository (or any parent up to mount point /) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). Non-git builds deprecated git clean -fd fatal: not a git repository (or any parent up to mount point /) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). make: *** [Makefile:60: rpm] Error 128

[stsp]

The "hoops" are very minor. What prevents you from moving away ~/.dosemu just to check the fresh install? 10 times faster than posting 1 msg here.

Yes, unfortunately rpkg only works with git afaik. You can try rpkg local but I think it will also complain on no git.

[stsp]

Of course in addition to ~/.dosemu, you would also need to remove /etc/dosemu.conf and ~/.dosemurc to try out the fresh setup.

[mateuszviste]

What prevents you from moving away ~/.dosemu just to check the fresh install?

I should have mentioned that I did not install dosemu on my system, so I didn't get any configuration created. Anyway, mystery is solved: apparently now dosemu looks for DOS kernels in ~/.dosemu/drive_c while before it was ~/.dosemu/drives/c After a quick renaming of my configuration dosemu2 boots now. Yaay! :) I can now confirm that slirp works fine out of the box (and that is a MAJOR improvement, thanks!) and my svarog/dosemu image boots perfectly - the package manager is also able to list packages from its online repository right away. Very cool! It is not able to download anything because of some fatfs errors, but it's unrelated to networking itself. I get lots of such error messages from dosemu2: ERROR: fatfs write ignored: dir /home/mateusz/.dosemu/drives/c_svardos, sec 503, len 1 ERROR: fatfs write ignored: dir /home/mateusz/.dosemu/drives/c_svardos, sec 29527, len 1 ERROR: fatfs write ignored: dir /home/mateusz/.dosemu/drives/c_svardos, sec 29528, len 1

Yes, unfortunately rpkg only works with git afaik. You can try rpkg local but I think it will also complain on no git.

Actually I did download the sources from git, but then "make rpm" complained about "rpkg command not found"... I looked into the repos of my distro and there is no such tool here, so I didn't investigate further. Doesn't matter anyway - I am able to compile dosemu from sources now and run it as-is so it's all good - I only have to figure out what's going on with the fatfs errors (happens even with a "echo hello > hello.txt" test).

[stsp]

I should have mentioned that I did not install dosemu on my system, so I didn't get any configuration created.

I don't understand. You say you had ~/.dosemu/drives/c. Which obviously means you could just move away ~/.dosemu. Now you still have problems with fatfs. Could you PLEASE move away ~/.dosemu instead of listing more reasons why you can't do that? :) I'd be happy to discuss any customizations you have, but before doing so, I'd pretty please like you to try out the fresh install. Its much easier to start from the working basis.

complained about "rpkg command not found"

So if opensuse doesn't have rpkg, then we'll need to support yet another build method... :( Maybe later.

[stsp]

Please, read my lips: mv ~/.dosemu ~/.dosemu.old && rm -f ~/.dosemurc && dosemu

[mateuszviste]

Please, read my lips: mv ~/.dosemu ~/.dosemu.old && rm -f ~/.dosemurc && dosemu

That's very kind of you sir, thank you for the idiot-compatible tutorial :-) In fact I already had a minimal configuration before, hence the reason why I didn't bother with the above. But okay, let me do it:

$ mv ~/.dosemu ~/.dosemu_BACKUP $ mv ~/.dosemurc ~/.dosemurc_BACKUP $ ./dosemu ERROR: Bootable drive not found, exiting -> here dosemu created a new .dosemu directory with a mostly empty "drive_c" subdirectory (except a single "tmp" subdirectory). I populated this directory with a few basic FreeDOS files (kernel.sys, autoexec.bat, config.sys, command.com...) $ ./dosemu -> here dosemu launches, boots the FreeDOS kernel, and whenever I try to write a file, dosemu outputs a "fatfs write ignored" error message on the host's console BOOT.LOG attached. boot.log