- Make our isohybrid create an MBR with partition type 0x96.
This properly assigns a drive letter to the Live-CD and lets me boot into desktop using "qemu -hda livecd.iso".
Fixes CORE-13184
svn path=/trunk/; revision=75586
- Only call mkhive once, as it always generates all 6 binary hives (and if you don't give it all inf files, some of the hives will end up empty).
- Remove no longer needed dependency of efisys on bcd_hive
CORE-13241
svn path=/trunk/; revision=74537
Patch all our ISOs (bootcd, bootcdregtest, livecd, hybridcd) with isohybrid in order to make them bootable from HDDs or any kind of USB drives.
The added MBR at the beginning of each ISO doesn't cause any harm for normal CD booting anymore after my patch in r74460.
There is also no need for the dedicated isohybrid targets anymore.
Our ISOMBR master boot record now successfully loads our ISOBOOT boot sector. ISOBOOT loads FreeLdr and indicates that we're booting from HDD, so that FreeLdr can successfully load the kernel.
We then bugcheck in the kernel with either 0x0000007B (INACCESSIBLE_BOOT_DEVICE) using bootcd or 0x0000006B (PROCESS1_INITIALIZATION_FAILED) using livecd.
Testcase is:
qemu-system-i386 -m 512 -hda bootcd_or_livecd.iso
Needs more investigation, but these are separate bugs and I consider CORE-12648 fixed.
svn path=/trunk/; revision=74461
Update mkisofs to schily-2016-12-14 giving us the following features:
- Support for -duplicates-once to store duplicate files in the tree only once in the filesystem (see also CORE-9266)
I've enabled this for the hybridcd target where it actually saves us 25 MB.
- Proper System-ID "Win32/MinGW" and "Win32/MSVC" under Windows hosts depending on the compiler
CORE-12578
svn path=/trunk/; revision=73520
- Make our build system create the required empty directory for mkisofs, instead. (It's not the purpose of the SVN to hold special files/directories just to make host tools happy; instead it's the job of the buld system to create them.)
- Place the boot files (catalog & co.) preferably at the beginning of the ISO image (it makes ISO image analysis easier, and is back-compatible with cdmake & oscdimg & windows ISOs): use the build system to generate the mkisofs sorting file. See the CMakeLists.txt for more details.
- Set in one place the ISO manufacturer & volume name strings so that it makes easier to bulk-change them (and makes features like CORE-12233 a bit easier to maintain).
- The EFI image must be set up with no emulation mode! (See section "12.3.2.1 ISO-9660 and El Torito" of the UEFI spec v2.4 errata B, for example).
[MKISOFS]: Add some useful offline documentation.
CORE-11988
svn path=/trunk/; revision=73104
Import a minimal version of the highly portable mkisofs tool from schily-2016-10-27 (https://sf.net/projects/schilytools) and use it for creating ReactOS ISOs from now on.
mkisofs is the de-facto standard ISO creation tool on most platforms and actively maintained.
Compared to cdmake, its features have matured and it adds ISO9660:1999 support among many other things.
I can import its UDF features as soon as we need them.
mkisofs has been integrated into our buildsystem in the sdk/tools/mkisofs folder with these subfolders:
* "reactos"
Host-specific include files that are usually generated by the upstream buildsystem. For us, I have handcrafted them to be enough for mkisofs and compatible with Windows, Linux and Mac OS X.
Follow the original layout of the generated files whenever you have to edit these.
* "schilytools"
Contains the actual mkisofs code and dependencies while maintaining the original directory layout.
Only synchronize with newer versions, but never modify. Submit patches upstream instead :)
ISOs are now being built with a single ISO9660:1999 filesystem instead of classic ISO9660 + Joliet.
For the moment, you can switch back to cdmake using -DUSE_MKISOFS:BOOL=0 on the CMake commandline. cdmake will be completely removed in about a month if no problems occur.
CORE-11988
svn path=/trunk/; revision=73051
[BOOTMGR/BOOTLIB]: Fix factorings that were incorrect but not noticed when bootmgr was the only bootlib user. Now with rosload in the picture, they became obvious.
[EFISYS]: BCD should not be on the EFISYS.BIN, only on the boot volume, just like a Windows DVD.
svn path=/trunk/; revision=70626
- Add BCD creation.
- Add BCD to bootcd, and also to EFISYS.BIN. Verified the BCD is now present on the EFI partition.
svn path=/trunk/; revision=69156
* Allow customizing the 8-letter volume label from the FAT header.
* Make the efisys.bin have EFIBOOT as a label.
* Improve a bit the help text.
svn path=/trunk/; revision=69140
Thanks gigaherz for the "fatten" utility!, and others for testing.
[CDMAKE]
- Add multi-boot CD support, following El-Torito specification, such that we can the usual ISO boot sector on BIOS-based PCs, and the UEFI loader on UEFI-based PCs.
- Load segment should be stored in little endian.
- Fix the computation of the sector count (count in 512 byte sectors and rounded up).
- Rework the command-line options to make them more compatible with CDIMAGE / OSCDIMG.
CORE-10120
[BOOTDATA]
- Activate the UEFI boot support for our ISOs.
svn path=/trunk/; revision=69139
* Change the number of FAT copies stored by the formatting code to 2.
* Implement /BOOT command, to apply a boot sector to the image (FAT12/16 only, for now).
* Make use of the command above to finally get the generated efisys.bin loading in 7zip as a floppy.
svn path=/trunk/; revision=69135
* Fix folder creation and external file access.
* Add fatten as a host-tool.
* Add a target for creating efisys.bin from the bootmgfw
TODO: Make the name of the boot*.efi depend on the platform (ia32/x64/arm).
TODO: Add efisys as a dependency to the bootcd, when we need to make use of the efisys.bin file for the iso (waiting for hbelusca's cdmake work).
svn path=/trunk/; revision=69109
Add basic Hybrid-CD generation to our build system.
Few changes were needed, especially in how we deal with the CD target "all": it's only for all the CD targets *BUT* the hybridcd. For the hybridcd you need to always specify the target manually (like in "... FOR all hybridcd" or "... FOR bootcd hybridcd" for example).
Since at the moment we cannot have the bootcd in RAMDISK, and I want to be able to either have the hybridcd booting livecd from within the CD (i.e. read/writes from the CD) or in RAMDISK, I need to also add the files that are going to be copied into the bootcd or livecd into the hybridcd.
CORE-9069 #resolve
svn path=/trunk/; revision=66051
[CDMAKE]
* Introduce a way to create an iso using a file map instead of the current on-disk layout. This allows us to massively reduce the IO and the disk space needed to perform the creation of the 3 ISOs, and at the same time speed up the process. Brought to you by Art Yerkes (arty) with review/bug fix by Thomas Faber.
[CMAKE]
* Leverage the newly introduced cdmake feature.
* Silence cdmake verbosity.
* Write the contents of the file lists at once, instead of appending to it one item by one.
[VGAFONTS]
* Don't include the cab file twice.
svn path=/trunk/; revision=59547
- make generated files depend on their generator
It seems stupid, but I removed this quite some time ago, don't ask me why.
Now, you just have to build the tools and do an incremental build each time a tool is updated.
svn path=/trunk/; revision=53088
