2024-05-12 l_*.sh - run the needed intermediate steps (named after ia32-hw-implementation, kind of) [...xyz]_*.sh - scripts doing the hard work NOTE: "grep %%%" shows the relevant sha256sum results in the corresponding logs, for easy comparison. A REMINDER: Do *NOT* trust the scripts, you *MUST* examine and understand them for the verification to be meaningful; you also have to adjust the scripts for your actual platform. The expected usage is: 1. prepare an empty writable build directory with several hundred MiB available space 2. set up the references to the relevant paths, in Bourne shell notation, "/XXXX" denotes the absolute path to the original file tree, "/YYYY" the absolute path to your writable build directory: A=/XXXX ; B=/YYYY ; export A B 3. examine and possibly adjust "$A"/SCRIPTS/?_*.sh or create new ones using the present ones as templates 4. run sh "$A"/SCRIPTS/your_choice_of_?_...sh check the resulting checksums by 'grep %%% "$B"/*Log*' and verify against the expected values (in ../README.txt and ../VERIFY_SHA256, then also against ../VERIFY_SHA512) ----------------------------------------------------------- On systems lacking /dev/zero, a sufficiently large file filled with zeros will do as well. Otherwise a small program, even without changes in the scripts, if combined with a named pipe in /dev. ----------------------------------------------------------- To start Minix on real hardware you may have to adjust the memory end address down in the Minix boot monitor (with the emssize=.... command) otherwise it can be too much for Minix to recognize. You will probably need at least 64MB (emssize=65536). ----------------------------------------------------------- To start Minix on real hardware you may have to switch to the bios disk driver (hd=bios) in the monitor. The hardware must support the traditional (aka "legacy") bios boot, to be able to boot Minix and our build of Linux. -----------------------------------------------------------