Upcoming switch to 3.3.0 and ABI break

[Lionel Sambuc]

Hello everyone,


The MINIX team would like to give some heads up about what is on the short term roadmap.

As you all know, we have been importing a lot of the NetBSD userland, as we feel what makes MINIX special is not the tools one can use, nor the way the sources are built, but its microkernel architecture.

We are going to switch the main source repository to version 3.3.0, in order to prepare for the next release. We are going to use this opportunity to adapt most - if not all - of the base system types to be defined as they are on a NetBSD system.

This will allow us to import more tools and have more packages from PKGSRC available on MINIX3. But this comes at a cost: an ABI break.

We are sorry not to be able to provide full forward, and backward, ABI compatibility this time.

Given our constrained ressources, we felt it was wiser to align as much as currently possible in one step, and ask our community to reinstall from the developper ISO, which will be provided, and spend the saved time on new MINIX hardware support as well as continuing to improve the system capabilities.

Of course we will provide the required steps to upgrade by compiling the new system, but that particular step will still require to generate an ISO, and install from it, over our usual source upgrade.


Regards,

Lionel Sambuc, on behalf of your MINIX team.

[r0ller]

Hi Lionel,

 

Do you happen to know roughly the release date of Minix3.3.0?

 

Regards,

r0ller

[Lazar Stricevic]

And could someone please come up with the list of the most important 3.3.0 changes, especially those which break ABI (I suspect there's more to it than just 'base system types'). A wiki-page would be nice if possible...

Thanks,

Lazar

[Lionel Sambuc]

Hi r0ller,


I don't expect to see the merge I announced published before mid/end of
september, but I wanted to give a heads up to the community for a future
disruptive change.

Now, to switch the mainline tree is a big step towards that. We have a
few other bullet points to achieve before that. So I can't really tell
when we will reach the release. As usual, we will release when we feel
it is ready.


Regards,

Lionel

[r0ller]

Hi Lionel,

 

Thanks, that's enough. I didn't expect an exact release date:)

 

Regards,

r0ller

[Alex B.]

Thanks Lionel,

I believe it's a wise choice to go this route at this time, it's about getting the kernel to a good place and get more developers in the door to work on this project with us. have no ABI compatibility at this time, in my own estimation is minor as compared to what has come forward
out of the hard work everyone has done in the past leading up to this point in time. At a later date, I am sure we can work on ABI and have no doubt we can work on it and have it ready for another stable release in the future. The way I look at it ABI doesn't make sense to implement now when we are constantly changing how the kernel and applications work together, it only hinders development at this time. Once we have all the drivers and the rest of the NetBSD applications and daemons coded for Minix 3 and we hammer out how we want to implement the application binary interface, that would be best.

Otherwise if we were to continue with ABI, we would have to create conversion utilities from one version to the next which in turn sooner rather than later, break the source code of some of the main applications, causing headaches and wasted time attempting to retrofit the old source of the applications to the new system.

[James T. Sprinkle]

snip snip rip

    Once we have all the drivers and the rest of the NetBSD applications and daemons coded for Minix 3 and we hammer out how we want to implement the application binary interface, that would be best.

Does this mean that writing a new driver for 3.2.1 would be a waste of time?

[Thomas Cort]

No, it wouldn't be a waste of time. The size of types will change, but
the API shouldn't change too much. You'll just have to recompile your
driver when the 3.3.0 snapshot comes out.

Thomas

[James T. Sprinkle]

Thanks Thomas!  I guess I misinterpreted the sentence I quoted.  Sounded like under 3.3.0 the drivers for NetBSD would be compilable on Minix.  Wishful thinking!

Jim

[Robert James]

Do we have any idea when the change over is happening as yet? I want to dive in and start developing but I want to wait till the next phase to really get my ears wet or what repo I can clone in to my system to start the process early.

Thanks.

[Lionel Sambuc]

Hi,


The 3.3.0 branch is progressing well, yet there is the main following tasks to be completed:
- Finish importing the /sys/sys headers and definitions.
- Finish PKGSRC bootstrap on 3.3.0.
- Switch time_t to 64bit.
- We also want to take the opportunity to cleanup the IPC protocols of a few
system protocol, as we have now more space available in the messages.

I can't give a deadline. What I can say is that this will not happen before february next year, given what has still to be done.

You can follow the progress on my personal git repository (http://git.minix3.org/?p=minix-lionel.git;a=summary) where you will find branches named 3.3.0[a-z].
The last letter is the latest rebase of the branch.


Regards,

Lionel

> --
> You received this message because you are subscribed to the Google Groups "minix3" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to minix3+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Robert James]

Thanks Lionel,

I just removed my src dir and resynced to your latest branch and now I'm rebuilding the system so get up to date. I like staying ahead of the curve so I'll stay in this branch and dive in where possible.  Keep up the great work and to all others involved, its a great project.

Rob.

[Lionel Sambuc]

Hi,


Just be careful when building, doing a 'make build' will fail, by definition.


Regards,

Lionel

[Robert James]

Yes, I just noticed this as I wasn't paying attention.  Damn stupid brain on Monday mornings. I'll run it via Archlinux and crosscompile.  The advantages of virtual machines.  I presume the steps are the same and its just the automated build that is screwed?

Rob

[Lionel Sambuc]

Hello,


The build is not screwed, it is just as we are breaking the ABI, you can't incrementally update the system, which is what make build does.

Using the two scripts (releasetools/arm_sdimage.sh, releasetools/x86_hdimage.sh) you can directly generate images which are bootable in qemu.

In my case I also add a second disk image which contains what I want to keep between two 3.3.0 changes. I just have to mount it somewhere, and I can work with it without having to transfer every time my work in progress.

This is the most convenient way I found to work with 3.3.0, until I can finish the pkgsrc bootstrap.


Regards,

Lionel

[Robert James]

noted, thanks for information.

Rob

On Wednesday, July 24, 2013 1:38:04 PM UTC+1, Lionel Sambuc wrote:

[Lionel Sambuc]

Hello Everyone, 

End of May has been reached, so I think an update on the state of the ABI break is due.

Before we can merge mainline, a few tasks are still required:

 1) The last task regarding the ABI break itself is being tackled by myself, I hope to see it through in a few days.

 2) PKGSRC has been bootstrapped on 3.3.0, but it is still missing two critical packages:

      - lang/gcc45 (being worked on by Ben right now)

      - minix/clang34

 3) Some minimal testing to check that our usual infrastructure (namely releasetools/release.sh) still works as expected, as well as our script to build the whole PKGSRC repository (so-called "pbulk").

As soon as this is cleared, we will be able to finally merge the 3.3.0 branch. We will then wait for a while, in order to get feedback from the community.

This grace period will also serve as a buffer to fix any bugs that may have crawled past our attention, despite our extensive testing.

After that, will we be able to make the new release ISO and official announcement.

 

Regards,

Lionel Sambuc, on behalf of the MINIX team.

[Patrick]

Thanks very much Lionel and the rest of the team !

If gcc 4.5 is not working from pkgsrc is 4.4 still working from pkgin ?

I would like to help with testing. If there are sections in particular you would like to have retested, please let me know.

-Patrick

--

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

For more options, visit https://groups.google.com/d/optout.

[Lionel Sambuc]

Hello, 

pkgin is a front-end to PKGSRC. When I speak about gcc45, I am only speaking for the upcoming 3.3.0 release. On 3.2.1 versions and earlier, it is not planned to spend further effort (at least from the team) to add new packages / security fixes in PKGSRC for those releases.

At the present time we do not have the ressources to maintain multiple GCC versions. We switched to GCC45, as this is the default version (4.5.4) in the NetBSD sources we imported. In other word, GCC44 is being obsoleted, and in the new PKGSRC repository, no attempt will be made to backport our patches from 4.5.4 to 4.4.x, at least from me.

There is not much incentive either to do so, as the main compiler (for MINIX/x86) is LLVM/clang.

If anything, we would prefer to be able to switch to LLVM also for the ARM port, and for PKGSRC packages. The last point seems now possible, as most of the packages do compile with LLVM on NetBSD, at least according to the last quaterly report (http://mail-index.netbsd.org/pkgsrc-users/2014/04/04/msg019510.html) - 13841 compile out of a total of 14255 on NetBSD-current/x86_64.

While those number are not yet achieved on Minix, the ABI break *main* goal is to allow us to reach numbers as close as possible to those.

As far as testing goes, we will need help to test MINIX, and also the packages. There is just too many for us to be able to test them individually. My hope is that when 3.3.0 is released, we will be able to upstream most of the currently required patches we have for MINIX in PKGSRC, and if possible involve the PKGSRC regular maintainers into the process of making their packages work on MINIX. Meanwhile this will be up to our community to help us by trying out packages and reporting if they work or not, maybe even provide fixes.

Regards, 

Lionel 

[Ben Gras]

All,

Hey, big news, the 3.3.0 branch is merged with mainline now.

We need your help testing it for the coming 3.3.0 release.

A new dev iso is available on http://download.minix3.org/iso/snapshot/

This week we've just been doing a lot of final stuff like building packages to make the last pieces come together and it's all done now - all seems fine. So we've done it!

There are lots of changes compared to the old mainline; as you know the original motivation was to do a big NetBSD-aligning ABI break, but the scope has crept a bit so now there's more. See http://wiki.minix3.org/MinixReleases for a (growing.. we have to remember it all) list.

Worth mentioning explicitly: clang and the sources are currently not on the CD due to space limitations. You have to get the sources and clang and binutils after installing in order to rebuild the system. (In the future I think one or both will be there in compressed form.)

A few known limitations to be fixed later:

 - Clang is default now, also for crosscompiling but it doesn't support Minix/ARM yet. There's a workaround in the ARM script that selects GCC using BUILDVARS. So if you set BUILDVARS, include the GCC options already there.

 - The current 3.3.0 package set is quite minimal, a bit smaller than it was, but we'll rebuild a full set soon.

 - Xorg is missing for now.

Please help test the new state for the best Minix release ever!

Cheers,

Ben on behalf of the Minix team

[Thomas Cort]

> the 3.3.0 branch is merged with mainline now.

Way to go!

> There are lots of changes

Indeed, a lot of work has gone into 3.3.0... over 1000 commits[1] by
nearly 40 contributors[2]. I'll do some testing this weekend.

> Please help test the new state for the best Minix release ever!

Testing and updating the documentation is another place to help:
http://wiki.minix3.org/UsersGuide

TC

[1] git shortlog -n -s v3.2.1..master | cut -f 1 | awk '{s+=$1} END {print s}'
[2] git shortlog -n -s v3.2.1..master | wc -l

[JD Begin]

Congrats to everyone who worked on this. Minix 3.2 is dead, long live 3.3!

[r0ller]

Hi All,

First of all, congrats and thanks to everyone for this! I gave it a try and seems to be ok even though it was just a smoke test of a reinstall on a copy of my current 3.2.1 vmware system since my original "test plan" was to set up 3.3.0 and move my project to it. However, as some of the dependencies (zlib, readline, flex, bison, sqlite3) and dev tools (scmgit-base, gcc) are missing, I could not go far enough:( Therefore, the question arises: when do you think that more packages will be available?

Regards,

r0ller

[Lionel Sambuc]

Hi r0ller,


A few notes:
- scmgit-base as been renamed in pkgsrc to git-base (and is available right now)
- binutils is there, as well as all it's dependencies
- clang is there too.
- readline, bison are available as packages, we have zlib, flex and sqlite3 as part
of the base system system now.

- gcc is not available, gmp needs to be fixed when compiled with clang, at least.

I am currently going through a full build, which should take at least around 50 more
hours. I will announce on the mailing list as soon as the repository has been updated,
hopefully by the end of the week.

This will be only a first shot at the repository, we still have a few packages to fix
at least.

If I looked correctly, you should already be good to go, unless clang can't take care
of your sources.


Regards,

Lionel

[r0ller]

Hi Lionel,

Thanks for your answer! Poor me haven't checked if certain pkgs are part of the base system. I also suspected that scmgit-base has been renamed but was unsure. Anyway, then I can already report that when issuing make pkgsrc-create in /usr, it fails as scmgit-base is expected and therefore I get: "scmgit-base is not available on the repository" leading to "Error code 1".

Regards,

r0ller

[Roc Vallès]

Gave it a spin on some old hardware.

Improvements:

- Boot monitor can boot minix3. With 3.2.1, it would reboot immediately after it loaded the kernel (triple fault?) so I had to use grub2 to load it. 3.3.0 just works.

- Keyboard plugged on onboard OHCI USB just worked.

Issues (all with pkgsrc):

- make pkgsrc-create wants scmgit-base. The package is now named git-base.

- bmake not installed by default, but needed by pkgsrc

- trying to actually build a package will expose dependency on digest, and insist it's not there (doesn't like the binary package installed with pkgin)

- pkgsrc is setup to use gcc is used by default, but gcc isn't available via pkgin (only clang is).

At this point, I just gave up. I'll try again some other time. The intent was to build and try a few things, but that can't be done when pkgsrc doesn't work at all; pkgsrc is quite basic functionality and should just work.

[Antoine LECA]

On 2014-08-05 20:27Z, Lionel Sambuc wrote:
> - gcc is not available, gmp needs to be fixed when compiled with clang, at least.
>
> I am currently going through a full build, which should take at least around 50 more

[...]

What is the target plan for pkgsrc's compiler ${PKGSRC_CC}: llvm/clang
as rest of MINIX, gcc as mainstream NetBSD and most other pkgsrc ports
so far, or to have both available and to be able to interchange them
without hurt (like we interchange gnumake and bmake for most packages)?

I see advantages (and hurdles) to any of these proposals :-)

Antoine

[Lionel Sambuc]

Hello Antoine,


For C programs we have a solution which allows gcc-compiled packages to
work
on both a gcc-based system and a clang-based system. This is obviously very
experimental.

For C++ programs, we were not able to implement a solution for that.

This is why we decided to switch the main PKGSRC compiler to clang by
default.

This comes with a few limitations:
- As I have not yet completed a full pbulk with clang I don't know how
many packages
will be available.
- The current clang binary we have is about 3-4x slower to compile C++
programs
than GCC.

This means that to compile yourself LLVM/clang, on a good machine,
you have to
expect about 26 hours of build time. Works, just very slowly.

Oddly enough clang is not suffering from this while compiling C
programs. We have
not yet been able to explore this.

In summary, the answers to your questions are:
- We have switched to llvm/clang by default, for PKGSRC.
- Mixing and matching clang/gcc works for C only applications, but we
do not plan on
supporting this officially.


Regards,

Lionel

[Lionel Sambuc]

Hello,


Concerning PKGSRC, I have not yet changed /usr/Makefile to point to the new
pkgsrc repository, as I was waiting for the results of the full build before
creating the new official branch.

If you want to give it a spin before I create the official branch, and
update the
documentation, the development branch is available online there:

git.minix3.org/pkgsrc-ng/3.3.0-lionel.

Regards,


Lionel

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

> <mailto:minix3+un...@googlegroups.com>.

[r0ller]

Hi Lionel,

One more question from a noob like me: how can one tell which pkgs are part of the base system (besides checking /usr/pkg/bin and /usr/pkg/lib)? At least, pkgin ls does not show them (e.g. zlib, flex and sqlite3) as pkgs installed.

Thanks and regards,

r0ller

[Lionel Sambuc]

Hi r0ller,


Well, that's the trick, software which is part of the "base" system is
not found in packages.
There are no package descriptions for those. They might have a packaged
counterpart, but
that is not always the case.

Those are all the programs and libraries outside the /usr/pkg hierarchy.

Put in an other way, everything under /usr/pkg comes as a PKGSRC
package, or all packages
are installed under /usr/pkg.


Regards,

Lionel

> <https://groups.google.com/d/optout>.

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

> <mailto:minix3+un...@googlegroups.com>.

[Antoine LECA]

On 2014-08-06 07:22Z, Lionel Sambuc wrote:
> In summary, the answers to your questions are:
> - We have switched to llvm/clang by default, for PKGSRC.
> - Mixing and matching clang/gcc works for C only applications, but we
> do not plan on supporting this officially.

Thanks for the detailed answer.

> This means that to compile yourself LLVM/clang, on a good machine, you
> have to expect about 26 hours of build time. Works, just very slowly.

Ugh. Not a good news. Particularly since I expect your definition of "a
good machine" to be your 4-core 3.7 GHz i7 G2 with SSD disks... pretty
much more efficient than the '08 Core available to me!

On the other hand, you spoke of 50 hours for a full pbulk, and now 26
just for llvm; do you mean the rest of pkgsrc takes 24 hours? 8-/

Antoine

[Lionel Sambuc]

Hello Antoine,

On 08/06/2014 11:00 AM, Antoine LECA wrote:
> On 2014-08-06 07:22Z, Lionel Sambuc wrote:
>> In summary, the answers to your questions are:
>> - We have switched to llvm/clang by default, for PKGSRC.
>> - Mixing and matching clang/gcc works for C only applications, but we
>> do not plan on supporting this officially.
> Thanks for the detailed answer.
>
>> This means that to compile yourself LLVM/clang, on a good machine, you
>> have to expect about 26 hours of build time. Works, just very slowly.
> Ugh. Not a good news. Particularly since I expect your definition of "a
> good machine" to be your 4-core 3.7 GHz i7 G2 with SSD disks... pretty
> much more efficient than the '08 Core available to me!

Actually, I am building using an HW install of minix, which runs on the
following:
- SATA disk (250GB)
- 3GHz Core2 vPRO intel CPU (multi-core is useless as MINIX doesn't
support it well)
- 2GB of RAM.

>
> On the other hand, you spoke of 50 hours for a full pbulk, and now 26
> just for llvm; do you mean the rest of pkgsrc takes 24 hours? 8-/
>
> Antoine
>

I mean I expect the rest of the pbulk to take 50 hours, without the
clang build, nor
the jail generation.

The new pbulk script works in steps to save time, at the cost of disk space.

Things happens as follow:
1) Jail generation (make build, inclusive binutils & clang), which
takes about 12h.
2) copy the jail to a new folder, then bootstrap pkgsrc in it, takes
about 45min.
3) copy the bootstrapped jail to a new folder, and start the pbulk in
there.
- building clang takes about 26hours
- Last full build, gcc based, took overall 50 hours - clang
compiled in ~4h using gcc.
Given the major slow down is because of C++ programs, it is
hard to predict, as it
depends on the number of C++ packages.

The new pbulk script allows you to restart a pbulk easily.
By default it checks which steps has to be done, and restart from step -
1. This means
if you successfully went through the first two steps, but removed for
any reason the third
jail, you will only incur the cost of copying the second jail to start
the package build.

If the final jail is there, then it just restart the pbulk build. This
means that it will go over the
scan phase from scratch (for a full build this is several hours, as
there are 14255 packages in
PKGSRC now). Then it will only try to build all the failed packages,
while skipping the already
successfully built ones.

We will have to find out why clang is so much slower to compile C++
code. It seems that by
default it is much more aggressive on the optimisations it applies. I
can't really tell where all
the time is spent right now, but hopefully this is something we can
configure / solve easily.


Regards,

Lionel

[Lionel Sambuc]

PS:

As a side note, what I can give right now is the current build stats:
174 chroot-pbulk/usr/pbulk-logs/meta/error
1065 chroot-pbulk/usr/pbulk-logs/meta/success
1239 total

while currently building:
[10141/14255] Starting build of tomoe-0.6.0nb5

Which means that I have to go through roughly 4000 packages, which are all
now hit-or-miss. Last time I had at the end a bit more than a thousand
failed
packages, and around 4000 successfully build iirc (with GCC). I will see
what
it gives with clang.

Obviously "build" doesn't mean "works", but this is already a good step
in the
right direction.


Regards,

Lionel

On 08/06/2014 11:00 AM, Antoine LECA wrote:

[r0ller]

Hi Lionel,

It was hard to find some time to give it a try but yesterday managed to do so. Besides the pkgs mentioned I need the foma library which I usually just download and compile (see thread https://groups.google.com/forum/#!searchin/minix3/foma/minix3/vZsOUe3NsTw/D7jAz_Gy-b8J for minix specific changes in makefile and CC has to be set to clang for now). Unfortunately though, it seems clang does not seem to cope with that source. Need to wait for gcc to check if it makes any difference. Nevertheless, it just came into my mind that on minix3.2.1 I could try if it works out with clang (with gcc it just works fine on 3.2.1) to spot if clang is indeed the issue or not... I'll try to find some time for that.

Regards,

r0ller

2014. augusztus 5., kedd 22:28:02 UTC+2 időpontban Lionel Sambuc a következőt írta:

[Lionel Sambuc]

Hello everyone,

Heads up for the second developer ISO for the 3.3.0 release. It is available at the usual place:

    http://download.minix3.org/iso/snapshot/

As we have no received much feedback, we are a bit puzzled, so let me say it again:

    We need your help testing it for the coming 3.3.0 release.

We have done our best to bring you the best MINIX release possible, but we are a bit hesitant to

draw the conclusion that "It just works". We need your help to uncover usages of MINIX we don't

have, and make sure it works there as well.

We are looking forward to your feedback, even if it is just to tell us "It works for me!".

Regards, 

Lionel

PS: For those subscribed by email, sorry for the first partial post.

[Michael W. Bombardieri]

Hi Lionel,

Successfully installed minix from snapshot minix3_3_0_ide_20140901_d3434cb.iso.

Minix was installed as a VM on Qemu.

Qemu version: 2.1.0 (win32 port)

OS version: Windows 7 Enterprise

VM disk size: 15 GB

VM memory: 256 MB

Network adaptor selected: Realtek (dp8390)

When booting the VM I see an assert message for dhcpd.

assertion "(char *) NextSlot(p) <= next" failed: file "/usr/r-staging/usr/src/minix/lib/libc/minix-malloc.c", line 237, function "free"

PM: coredump signal 6 for 349 / dhcpd

Rebooted after increasing VM memory to 512 MB; error still present.

Rebooted after changing /etc/inet.conf to "fxp"; error still present.

Is this a known issue?

- Michael

[Ben Gras]

Hi Michael,

Sort of. It happens when dhcp doesn't get a good reply.

[Lionel Sambuc]

Hello Michael,


This is news for me, but now it is on my radar.

Thanks for the feedback!


Regards,

Lionel

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

> For more options, visit https://groups.google.com/d/optout.

[Michael W. Bombardieri]

I don't think any recent code changes to Qemu's internal DHCP server have caused this.

I reproduced the error on an older version of Qemu (1.5.1).

The Qemu binaries I'm using are from 

   http://omledom.com

When I have time I'll try installing the same snapshot on real hardware.

- Michael

[r0ller]

Hi Lionel,

Reinstalled 3.3.0 in vmware using the latest 3.3.0 snapshot and saw a strange message during the reinstall of which I could not take a good snapshot, but some of you may be able to identify the root cause. If not, let me know and I'll reinstall it again so that the complete message can be seen.

Regards,

r0ller

[Jean-Baptiste Boric]

Hi,

I just installed a fresh Minix with the ISO on QEMU (Debian testing on a Dell Latitude E6510).

I have a error on booting (both on Live CD and on the installed system) :

[...]
Starting hotplugging infrastructure... done.
sh: Syntax error: word unexpected
Starting services: random pty uds ipc log printer.
[...]

After installing openssh, there are a bunch of errors on booting/shutdown about $kadmind, $kcm, $kdc and $kpasswdd not set properly/not enabled. The ssh server itself works fine.

There are a bunch of files on the root directory (/SETS.*) which should probably not be there.

Otherwise, Minix works just fine for me so far. I have a ton of PCs (from 1987 onwards) sitting in the basement, I'll try the CD on them and give back the results when done.

[r0ller]

Hi Lionel,

Just managed to give it a try with the new snapshot of 3.3.0. Actually, I've no clue due to what but clang now only generates one warning for the foma lib I'm compiling manually. However, when trying to use it, I got an error, saying 'Shared object "libreadline.so.6" not found' despite its being installed. So I googled a bit for that adding netbsd also as a search criteria and ended up on a page (http://netbsd.2816.n7.nabble.com/libs-are-not-found-LD-LIBRARY-PATH-td222372.html) that happened to solve my problem as well. I guess as we're heading towards netbsd, it's kind of ok but wanted to report it. Unfortunately, I couldn't go further with compiling my project as clang complains now about the headers of the foma lib (fomalibconf.h and fomalib.h) saying that 'unkown type name _Bool' and then comes either '_Bool hascm' or '_Bool is_final'. Need to sort it out. Otherwise the environment could be set up fine and everything works so far. I'll try to connect to 3.3.0 from Eclipse tomorrow through openssh.

Regards,

r0ller

[Michael W. Bombardieri]

I've reproduced the dhcpd assert error in Bochs.

* Bochs version 2.6.6 (win32)

* Minix snapshot installed successfully

* Network adaptor selected: dp8390

* dhcpd dies soon after boot sequence completes

I am not very familiar with Bochs so it is possible my VM network was not configured correctly.

- Michael

[Michael W. Bombardieri]

Further testing on Vmware... dhcp success but ssh tunnel failure.

* VMWare Player 6.0.3

* Minix snapshot (minix3_3_0_ide_20140901_d3434cb.iso) installed successfully

* dhcpd successfully acquired lease on boot (did not fail on previous assert)

* Installed openssh via pkgin

* Tested ssh - standard login session to remote OpenBSD box worked ok

* Problem with ssh forwarding

# ssh -vvv m...@my.domain -L 6667:127.0.0.1:6667 -N

Command is supposed to start a ssh process which listen on

local port 6667. Instead I get the following error.

  bind: Can't assign requested address

  channel_setup_fwd_listener: cannot listen to port: 6667

  Could not request local forwarding

[Michael W. Bombardieri]

Identified system crash in VMware when building perl with clang.

* Installed clang and binutils via pkgin

* Successfully compiled pcc using clang

http://pcc.ludd.ltu.se/ftp/pub/pcc/pcc-current.tgz

  # pcc -version

  pcc 1.1.0.DEVEL 20140904 for i686-pc-minix

I don't think minix is a supported target for pcc, so compiling a test program with pcc fails

  # pcc test.c

  ld: cannot find -lpcc

  error: ld terminated with status 1

The standalone preprocessor works though.

  # pcpp test.c test.i

  # clang test.i

  # ./a.out

  test

* Kernel panicked and rebooted during compile of perl-5.14.4

Screenshot of crash:

http://bom.nom.co/minix/perl_crash_20140904.png

Replication steps

  # tar xzf perl-5.14.4.tar.gz

  # cd perl-5.14.4

  # ./Configure -d

[r0ller]

Hi All,

Connecting to minix3.3.0 from Eclipse using RSE through ssh works just fine:)

Regards,

r0ller

[Antoine LECA]

On 2014-09-04 03:17Z, Michael W. Bombardieri wrote:
> Identified system crash in VMware when building perl with clang.
>
> * Installed clang and binutils via pkgin
> * Successfully compiled pcc using clang
>
> http://pcc.ludd.ltu.se/ftp/pub/pcc/pcc-current.tgz
>
> # pcc -version
> pcc 1.1.0.DEVEL 20140904 for i686-pc-minix

I am not sure here but I sort of remember there was a choice to
standardize on i386 as a platform, regardless on the actual processor;
was I wrong?

> I don't think minix is a supported target for pcc,

Can you document the support for your thought? It happened to be
supported; then there was a change in the driver some time ago, and it
is possible I did not successfully pushed the required patch for Minix
toward LTU to stay on line. OTOH you did not report problem while
_building_ so I assume it is still working.

> so compiling a test program with pcc fails
>
> # pcc test.c
> ld: cannot find -lpcc

... however, if you did not build pcc infrastructure, it is difficult
for it to work: as the error message says, you need a support library
for pcc, aptly named libpcc.a, which apparently you did not build.


It is possible to improve the support for pcc on Minix, both by pushing
updated versions to pcc "upper stream", and by actually enable the
already inheritable (from NetBSD) support within Minix. I stopped doing
the former task because I lacked time, there were clearly no interest
outside mine, and the Minix target was unstable until recently.
The later task (using pcc from NetBSD tree, MKPCC etc.) did not attract
any interest and was not approved for inclusion when I presented it.


Antoine

[Michael W. Bombardieri]

TBH i was just happy to be able to build pcc without errors.

I don't expect anyone to work on supporting pcc on minix.

I'm more interested in why building perl caused the system to crash.

- Michael

[Lionel Sambuc]

Good to hear!


Regards,

Lionel

[Lionel Sambuc]

Hello Jean-Baptiste,


A patch from Ben is under its way (http://gerrit.minix3.org/2812) for
the "sh: Syntax error" issue.

I am working on preventing those pesky SETS.* files to lend on the CD in
the first place.


Regards,

Lionel

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

> <mailto:minix3+un...@googlegroups.com>.

[r0ller]

Hi Lionel,

Did any of you happen to have time to look at the 'arith: syntax error' stuff during reinstall?

Regards,

r0ller

[Lionel Sambuc]

Hi r0ller,


I am on it actually. The source of the problem seems to be around
setup.sh:322, but I have to dig some more.


Regards,

Lionel

> > an email to minix3+un...@googlegroups.com <javascript:>
> > <mailto:minix3+un...@googlegroups.com <javascript:>>.

> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

[Lionel Sambuc]

Small correction: line 422, not 322.

[David van Moolenbroek]

Thank you all for the feedback! Keep it coming.. :)

On Thursday, September 4, 2014 10:19:15 AM UTC+2, Michael W. Bombardieri wrote:

I'm more interested in why building perl caused the system to crash.

Just as an update, we've determined the cause of the VFS crash: a relatively new assert going off when executing an invalid binary. Fortunately it will be easy to fix - we're working on it. Your screenshot has been crucial here, so thank you :)

Regards,
David

[Jean-Baptiste Boric]

Hi,

I booted the CD on four "retro" computers so far, and one of them crashes Minix with a page fault.

It's a Pentium MMX with 128 Mio of RAM from 1997 or so. I know for sure it can boot the latest Debian Live CD, so I can extract informations about the hardware with Linux if required.

Here's a screenshot with verbose=3 : https://docs.google.com/file/d/0B6W_A9KOtYU2Wnpkc2J6anExNEU/edit?pli=1

I might try other computers if I have time.

[Lionel Sambuc]

Hi all,


Let me first say this: Thanks for the feedback! This is priceless to us.

Here are a few more patches for a few of the reported problems, they are in the pipe,
and will be merged soon:

- Library path problem:
http://gerrit.minix3.org/#/c/2814/

- SETS.* files incorrectly taken over on the install CD, and then on the newly
installed system:
http://gerrit.minix3.org/#/c/2815/

- Syntax error when upgrading an install in setup:
http://gerrit.minix3.org/#/c/2816/


Regards,

Lionel

On 5 sept. 2014, at 10:15, Lionel Sambuc <lionel...@gmail.com> wrote:

> Hello Antoine,

>
>
> On 09/04/2014 09:33 AM, Antoine LECA wrote:
>> On 2014-09-04 03:17Z, Michael W. Bombardieri wrote:
>>
>>> Identified system crash in VMware when building perl with clang.
>>>
>>> * Installed clang and binutils via pkgin
>>> * Successfully compiled pcc using clang
>>>
>>>
>>> http://pcc.ludd.ltu.se/ftp/pub/pcc/pcc-current.tgz
>>>
>>>
>>> # pcc -version
>>> pcc 1.1.0.DEVEL 20140904 for i686-pc-minix
>>>
>> I am not sure here but I sort of remember there was a choice to
>> standardize on i386 as a platform, regardless on the actual processor;
>> was I wrong?
>>
>

> This might be a problem with uname again?
> - uname -m returns i686,
> - while uname -p returns i386
> I need to check the expected (a.k.a NetBSD) behavior on that.

>
>>> I don't think minix is a supported target for pcc,
>>>
>> Can you document the support for your thought? It happened to be
>> supported; then there was a change in the driver some time ago, and it
>> is possible I did not successfully pushed the required patch for Minix
>> toward LTU to stay on line. OTOH you did not report problem while
>> _building_ so I assume it is still working.
>>
>>
>>> so compiling a test program with pcc fails
>>>
>>> # pcc test.c
>>> ld: cannot find -lpcc
>>>
>> ... however, if you did not build pcc infrastructure, it is difficult
>> for it to work: as the error message says, you need a support library
>> for pcc, aptly named libpcc.a, which apparently you did not build.
>>
>>
>> It is possible to improve the support for pcc on Minix, both by pushing
>> updated versions to pcc "upper stream", and by actually enable the
>> already inheritable (from NetBSD) support within Minix. I stopped doing
>> the former task because I lacked time, there were clearly no interest
>> outside mine, and the Minix target was unstable until recently.
>> The later task (using pcc from NetBSD tree, MKPCC etc.) did not attract
>> any interest and was not approved for inclusion when I presented it.
>>
>>
>> Antoine
>>
>>

> I am not very hot about adding support for yet another toolchain (although I very much like the PCC project goals), mainly because it is my feeling the current community simply does not have the development power to maintain 3 different toolchains. I would actually like to be able to convert all the supported platform to clang, as some feature we want to get mainline requires LLVM BitCode IR anyway.
>
> Those are my main objections / fears. If someone wishes to take on the challenge, and the patches are clean, then we can get those in.
>
> The only thing AFAIC is that there should be no expectation about me taking care of keeping it working / making it working in all the compilation scenario we now support.
>
>
> Regards,
>
> Lionel

[r0ller]

Hi Lionel,

I couldn't resolve the issue (clang complaining about C99 _Bool type) with compiling my stuff with the foma headers. Most probably it's a picnic but just to make sure I'd like to ask: you don't have problems with clang when using _Bool, do you? The issue is pretty strange as I don't get any problems on 3.2.1 using gcc/g++ when I'm linking my C++ code with the foma lib which is written in C (compiled as std=C99). I'll come back as soon as I have anything new -be it a question or an answer:)

Regards,

r0ller

[Lionel Sambuc]

Hi r0ller,

Here is a small test I did about your issue:
#include <stdbool.h>

int main(int argc, char **argv) {
bool b1;
_Bool b2;

return 0;
}
# cc -std=c99 test.c -o test
# ./test
#

Agreed the test case is extremely simple, but it compiles fine. Could it
be that the foma libraries are missing the stdbool.h include?

I can take a look at it, but I will need a link to the library sources,
and if possible a copy-paste style set of commands you use to build it.


Regards,

Lionel

> <http://gerrit.minix3.org/#/c/2816/>
>
>
> Regards,
>
> Lionel

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

> <mailto:minix3+un...@googlegroups.com>.

[Lionel Sambuc]

Hello Antoine,


So I installed NetBSD 6.1 (i386) and checked the values returned by uname.

In both cases it returns i386. I have no problem adapting uname or the source of uname's information to have the same behavior. I know for sure this would allows us to remove a patch in the Makefile of make, for example.

As anyone any strong objections about adapting uname to match NetBSD behavior?

Regards,

Lionel

On 5 sept. 2014, at 10:15, Lionel Sambuc <lionel...@gmail.com> wrote:

> Hello Antoine,
>
>
> On 09/04/2014 09:33 AM, Antoine LECA wrote:

>> On 2014-09-04 03:17Z, Michael W. Bombardieri wrote:
>>
>>> Identified system crash in VMware when building perl with clang.
>>>
>>> * Installed clang and binutils via pkgin
>>> * Successfully compiled pcc using clang
>>>
>>>
>>> http://pcc.ludd.ltu.se/ftp/pub/pcc/pcc-current.tgz
>>>
>>>
>>> # pcc -version
>>> pcc 1.1.0.DEVEL 20140904 for i686-pc-minix
>>>
>> I am not sure here but I sort of remember there was a choice to
>> standardize on i386 as a platform, regardless on the actual processor;
>> was I wrong?
>>
>

> This might be a problem with uname again?
> - uname -m returns i686,
> - while uname -p returns i386
> I need to check the expected (a.k.a NetBSD) behavior on that.
>

>>> I don't think minix is a supported target for pcc,
>>>
>> Can you document the support for your thought? It happened to be
>> supported; then there was a change in the driver some time ago, and it
>> is possible I did not successfully pushed the required patch for Minix
>> toward LTU to stay on line. OTOH you did not report problem while
>> _building_ so I assume it is still working.
>>
>>
>>> so compiling a test program with pcc fails
>>>
>>> # pcc test.c
>>> ld: cannot find -lpcc
>>>
>> ... however, if you did not build pcc infrastructure, it is difficult
>> for it to work: as the error message says, you need a support library
>> for pcc, aptly named libpcc.a, which apparently you did not build.
>>
>>
>> It is possible to improve the support for pcc on Minix, both by pushing
>> updated versions to pcc "upper stream", and by actually enable the
>> already inheritable (from NetBSD) support within Minix. I stopped doing
>> the former task because I lacked time, there were clearly no interest
>> outside mine, and the Minix target was unstable until recently.
>> The later task (using pcc from NetBSD tree, MKPCC etc.) did not attract
>> any interest and was not approved for inclusion when I presented it.
>>
>>
>> Antoine
>>
>>

[u-l...@aetey.se]

On Fri, Sep 05, 2014 at 02:01:36PM +0200, Lionel Sambuc wrote:
> So I installed NetBSD 6.1 (i386) and checked the values returned by uname.
>
> In both cases it returns i386. I have no problem adapting uname or the source of uname's information to have the same behavior. I know for sure this would allows us to remove a patch in the Makefile of make, for example.
>
> As anyone any strong objections about adapting uname to match NetBSD behavior?

This is probably the only logical choice, as the semantic difference
between the i[34567]86 names is hardly well defined and varies depending
on the context.

So it is better to avoid referring to something which different parties
assume different meanings for.

Rune

[Antoine LECA]

On 2014-09-05 11:55Z, Lionel Sambuc wrote:
> Here is a small test I did about your issue:
> #include <stdbool.h>
>
> int main(int argc, char **argv) {
> bool b1;
> _Bool b2;
>
> return 0;
> }
> # cc -std=c99 test.c -o test
> # ./test
>

> Agreed the test case is extremely simple, but it compiles fine.
> Could it be that the foma libraries are missing the stdbool.h include?

The very point of using _Bool (instead of bool) is that you do NOT need
to #include <stdbool.h> ; and it should link just fine (in C.)


The fact it compiles fine for you is a good show that the compiler is
correctly handling _Bool, which is to be expected given -std=c99

If you try with -std=c90, chances are it /could/ break: _Bool is in the
reserved namespace so the compiler is free to define it or not, but it
would be arguably a sane decision to *not* declare that _Bool type while
operating in C90 mode; can you test same program with -std=c90 ?

> I can take a look at it, but I will need a link to the library sources,

Another problem linked with the library could be a lack of extern "C"
around _Bool declarations, which would prevent C++ name mangling and
would prevent proper linking... but then no C++ compiler would succeed.


Antoine

[Lionel Sambuc]

On 09/05/2014 04:17 PM, Antoine LECA wrote:
> On 2014-09-05 11:55Z, Lionel Sambuc wrote:
>> Here is a small test I did about your issue:
>> #include <stdbool.h>
>>
>> int main(int argc, char **argv) {
>> bool b1;
>> _Bool b2;
>>
>> return 0;
>> }
>> # cc -std=c99 test.c -o test
>> # ./test
>>
>> Agreed the test case is extremely simple, but it compiles fine.
>> Could it be that the foma libraries are missing the stdbool.h include?
> The very point of using _Bool (instead of bool) is that you do NOT need
> to #include <stdbool.h> ; and it should link just fine (in C.)
>
>
> The fact it compiles fine for you is a good show that the compiler is
> correctly handling _Bool, which is to be expected given -std=c99
>
> If you try with -std=c90, chances are it /could/ break: _Bool is in the
> reserved namespace so the compiler is free to define it or not, but it
> would be arguably a sane decision to *not* declare that _Bool type while
> operating in C90 mode; can you test same program with -std=c90 ?

It just works as well, which I think means it is also defined there.

# cat test2.c

int main(int argc, char **argv) {

_Bool b2;

return 0;
}
# cc -std=c90 test2.c -o test2
# cc -std=c99 test2.c -o test2

Just works as well. I think this is expected behavior, apart of _Bool
being also defined in C90 mode, which is debatable it seems. I have
not read the C90/C99 specifications so I can't really say if this is
(in)correct behavior.


Regards,

Lionel

[Antoine LECA]

On 2014-09-05 14:36Z, Lionel Sambuc wrote:
> Just works as well. I think this is expected behavior,

Agreed. And it dispels potential problems with clang.

<OT>

> apart of _Bool being also defined in C90 mode, which is debatable it
> seems. I have not read the C90/C99 specifications so I can't really
> say if this is (in)correct behavior.

It is certainly correct behaviour in any case, C90-conforming programs
are prevented to make use of _Bool so the compiler can go both ways.

Both choices of implementation have pro and cons: to support _Bool in
any mode is certainly easier to deal with internally, so make the
compiler quicker, leaner (which probably means less bugs down the road)

To make a difference will make the C90-mode compiler choke on
(erroneous) constructions using _Bool, so such code would need to be
either rewritten to conform to C90, or the building infrastructure
(perhaps just documentation) would have to be updated to state that C99
compiler is required --or at least support for _Bool; so for example,
VC2013 and up are ok here, even if it does not fully support C99...

</OT>

Antoine

[r0ller]

Hi Lionel, Antoine,

Well, as mentioned it's rather a picnic since the small test compiles fine here as well both in case of c90 and c99. I need to create some small test for foma to check why it poses a problem in its header. Thanks for your help anyway but at least this means that it's no issue for minix:)

Regards,

r0ller

[Michael W. Bombardieri]

More info from Minix snapshot running under VMware player 6.0.3.

1. OpenSSH

[SUCCESS] sshd starts on boot

[SUCCESS] Establish local ssh session (ssh user@localhost)

[SUCCESS] Used sftp and scp to download files from remote server

[SUCCESS] Established reverse SSH tunnel

  # ssh -nNT -R 2222:localhost:22 us...@my.domain

[SUCCESS] ssh session to minix system via tunnel worked ok

2. Apache

[SUCCESS] Installed apache2 via pkgin

[SUCCESS] Started apache2 server using default configuration

[SUCCESS] Connected to apache2 from remote system

[SUCCESS] Streamed an Ogg-Vorbis audio file hosted on Minix/apache2 to my desktop's VLC media player

[FAIL] I had problems running apache2 CGI processes in /usr/pkg/libexec/cgi-bin

  *. Ensured all cgi-bin files executable (chmod 755 *)

  *. Experienced "premature end of script headers" error with cgi test code written in Shell, Perl, and C

  *. I can run the cgi code from the commandline

  *. Maybe I missed something obvious

[Michael W. Bombardieri]

1. thttpd

[SUCCESS] Installed thttpd from pkgin
[SUCCESS] Tested basic perl/CGI program in thttpd
[NOTE] Still unable to get CGIs working in apache2

Whatever I do I still get error.
Premature end of script headers: test.cgi

2. cvs

[SUCCESS] Built GNU cvs 1.11.23 from source with clang
[SUCCESS] Initialised a new CVS repository (cvs init)
[SUCCESS] Checked out CVS repository from remote system (via SSH)

  $ export CVSROOT=user@minixbox:/path/to/cvs/repo
  $ export CVS_RSH=ssh
  $ cvs co test

[SUCCESS] Remote cvs operations work ok (diff, log, commit)

[Michael W. Bombardieri]

I forgot to add this in my previous update.

 

* Noticed there is no sqlite3 package listed in pkgin

* Built perl libraries DBD-SQLite 1.43_08 and DBI 1.631 from source

* Example perl/sqlite3 code works ok

[Dy Gn]

Hi All. First of all, thank you for such a good project!

I found some strange things:
1. I don't know is it a bug or a feature, but thttpd default page shows banner "Site Driven By NetBSD".
2. When I tried to install Minix on 4GiB disk using 'expert' partitioning mode, installer failed on:

...

    Root subpartition:  /dev/c0d0p0s0    64 MB
    /home subpartition: /dev/c0d0p0s1    731 MB
    /usr subpartition:  /dev/c0d0p0s2    rest of c0d0p0

Creating /dev/c0d0p0s0 for / ..
Creating /dev/c0d0p0s1 for /home ..
mkfs.mfs: zero size device.
#

Automatic mode worked well. When I tried to do the same thing with 8 GiB disk, everything also worked well.


Regards,
Demetry.

// Sorry for my broken English

[Dy Gn]

And, by the way, there's a problem with "free" utility:
When I'm trying to run it:

# free
Kid, get yerself a System: www.netbsd.org
#

It looks, that "free" utility is a script that uses vmstat and checks the system before running and hangs if it's not NetBSD.

[Робур]

Hi Lionel,

I've successfully installed the minix3_3_0_ide_20140901_d3434cb release on VMware Player 6.0.3 build-1895310 (Windows 7 Host).

Finally the network is working with NAT WM settings (previous release was not working :-()

Thank you.

[Michael W. Bombardieri]

* Re-tested minix snapshot (minix3_3_0_ide_20140901_d3434cb.iso) on new qemu release (qemu 2.1.1)

* Installation completed cleanly

* Booted into VM (memory=256M nic=e1000)

* DHCP successfully obtained a lease (previosuly qemu 2.1.0 didn't work with minix 3.3.0 dhcpd)

* Updated pkgin database

OpenSSH

-------

[OK] Installed openssh via pkgin

[OK] Established simple ssh session with remote server

[OK] Successfully connected to minix sshd using qemu's NAT (qemu -redir tcp:2222::22)

[ERR] SSH tunnel establishment problems (reported previously)

Clang

-----

[OK] Installed clang via pkgin

[ERR] After installing clang I'm still not able to compile hello.c

  * linker (ld) isn't installed as an auto-dependency of clang

  * after manually installing binutils via pkgin I can build hello.c

Wget

----

[OK] Installed wget via pkgin

[ERR] Problems downloading a remote file via HTTP

  # wget http://bom.nom.co

  libidn: warning: libiconv not installed, cannot convert data to utf-8

  ...

  HTTP request sent, awaiting response... Read error (Function not implemented) in headers

  * I get same result after installing libiconv via pkgin

Curl

----

[OK] Installed curl via pkgin

[OK] Downloaded file from remote server (http)

[OK] Downloaded file from remote server (ftp)

Lynx

----

[OK] Installed lynx via pkgin

[OK] Used lynx to browse an HTTP mirror site: http://ftp.iinet.net.au/pub

[OK] Downloaded tar.gz file from mirror site

Perl

----

[OK] Installed perl via pkgin

[OK] Performed basic perl test with CPAN library Crypt-Elijah

Vim

---

[OK] Compiled vim 7.4 using clang

[Ok] Vim launches alright; syntax highlighting seems to work

[hoefnix]

Hello everyone,

I installed 3.3 beta on VMware Player 6.0.3 on Win7 64-bit. With 2 cpu's and 512Mb ram, 4 Gb drive, Bridged network, DHCP and e1000.

After rebooting there is an error displayed: "sh: Syntax error: word unexpected"

Ping doesn't work. There is no network.

Regards,
Gerard

[r0ller]

Hi Gerard,

If I'm not mistaken, this has been solved and merged in current. At least, judging by the answer to Jean-Baptiste's comment (see quoted text):

https://groups.google.com/d/msg/minix3/8ldFwTdrkr4/dRaqNQjn-doJ

Regards,

r0ller

[hoefnix]

Thanks for the reply. Looking in previous Q&A in this thread brought me to set networking to NAT and now it works ok.

[Antoine Leca]

​

2014-09-02 15:36 GMT+02:00 Lionel Sambuc <lionel...@gmail.com>:

Small heads up for the second developper ISO which is now available at the usual place:

We need your help testing it for the coming 3.3.0 release.

​Hi:

I finally found some time to test MINIX again. No ARM device at hands, so I keep testing i386, sorry.

I found a number of very minor issues, which are not likely to annoy anyone beyond me, but some of them might actually need to be fixed some days. Please advise in which ways you want them to be fixed (examples range from, just delete those now useless things, to doing this or that.)

In more or less order of appearance:

* Pressing F1 before logging creates a very strange listing; it becomes more OK after logging in

* "tasks" [-5] to [-1] are still shown in F1 (Kernel process table), F3 (system image), F4 (privileges), and ShiftF9 (stack traces) listings, despite being long gone.

* F5 debug key is useless on screen (or serial terminal without *many* lines memory), it does not stop at screen full so only shows interrupts 4x to 63, all unused

* In debug listing ShiftF1 and ShiftF2 (PM), "readclock.drv" does not fit within the design and makes the listing hard to read.
* In Shift-F6 (RS) it fits much better, but overflows on 80 columns, probably not needlessly

Please consider reassign kernel procs[] table to F2 (from F1), then key map to F1 (from Shift-F5)

* Autopart did not succeed on a blank disk (2.04GB, 987 cyl. × 64 hd. × 63 sect.) Is it a local problem?

​* ​

Part/Autopart does not know about NetBSD id

​* ​

Setup expects a program named mkfs.$FSTYPE, so needs to restore

​​

 cd /sbin && ln newfs_ext2fs mkfs.ext2

​* Just installing git-base needs 257MB in addition to the original 667MB​ required by setup; then the src git tree will add around 580M; my original 1GB partition proved too tiny even more quickly than anticipated

* ext2 server bombs on a freshly created 600MB file system (newfs_ext2fs -b4k -O1 /dev/c0d0p1)​; I suppose it should work as I seem to remember it was included in the testing plan, so what should I investigate?

Antoine

[Roman Bekkiev]

Hi Minix folks! \o/

Not sure this is the right thread to post it, but since I've ended up here by googling "mkfs.mfs: zero size device", I'd like to share my "solution". Since at the end there is console prompt, I've just typed setup again, and re-done partition once more time in "expert" mode. I'm not exactly sure, but I've left partition table the same as previous time but set different size for /home. My first guess was that I've just mistyped /home size the first time and set too large so there no space for /usr left. Finally I've ended up with
    Root subpartition:  /dev/c0d0p0s0    128 MB
    /home subpartition: /dev/c0d0p0s1    16000 MB
    /usr subpartition:  /dev/c0d0p0s2    rest of c0d0p0

But since Dy Gn has only 731 MB allocated for the /home, this is probably not the case. So, either I'v changed something accidentally in partition table (most likely head from 0 to 1) or it's just a heisenbug and I can't reproduce it.

In either case: just re-run setup. Change things and see what happen!  ᕕ( ᐛ )ᕗ