OPENSTEP-BOOTCD-INTEL

KO | EN

gitlite — search

#ai-agent #proxy #generative-ai #api #git #monitoring #css #video #anthropic #claude

OPENSTEP-BOOTCD-INTEL

(★ 9)

OPENSTEP 4.2J — building a single El Torito bootable installation CD from a 4.3BSD UFS disc

파일 탐색기

ZIP 다운로드

- bootblock.h
- F288.img.zip
- F288.vmdk.zip
- NS_CKSUM.ZIP
- OPENSTEP42CD.Block00.ElTorito.lbl.zip
- OPENSTEP42CD.Block00.ElTorito.m68k.lbl.zip
- OPENSTEP42CD.Block00.lbl.zip
- - ns_checksum.c
- - F288C.img
- F288D_bootdrivers.img
- F288E_picfix.img
- F288G_hintfix.img
- mkopenstepiso.sh
- OPENSTEP42JCD_makeafter.lbl
- README_scripts.txt
- writelabel.sh
- - Adaptec78XXSCSI.pkg.tar
  - ATIRageDisplayDriver.pkg.tar
  - BusLogicFPSCSI.pkg.tar
  - CirrusLogicGD546xDisplay.pkg.tar
  - EIDE.pkg.tar
  - EtherExpress16.pkg.tar
  - EtherLinkXL.pkg.tar
  - IBMThinkPad760CDDisplayDriver.pkg.tar
  - MatroxMGA2064WDisplayDriver.pkg.tar
  - Number9Imagine128S2DisplayDriver.pkg.tar
  - PCMCIABus.pkg.tar
  - SoundBlaster16.pkg.tar
- - 4.2_Beta_Drivers_1.img
  - 4.2_Beta_Drivers_1_v401.img
  - 4.2_Beta_Drivers_2.img
  - 4.2_Driver_Disk.img
  - 4.2_Install_Disk.img
  - OPENSTEP_Boot_and_Driver_Disk_Images.rtf
- - 00_main_onion.txt
  - 01_ref_peterwong.txt
  - 02_ref_t3RRa.txt
  - 03_bootblock_desc.txt
  - 04_iso9660_header.txt
  - 05_vmdk_make.txt
- 86box-430vx.cfg.sample
- cd_eide_dual.py
- cd_eide_upgrade.py
- cd_kernel_pic.py
- check_repo.sh
- inspect_lbl.py
- make_boot1f_diag.py
- make_eide_debug_iso.py
- mkopenstepiso.sh
- nexttar.py
- ns_checksum
- patch_kernel_pic.py
- pic8259_replay.py
- qemu-boot.sh
- qemu-fdd.sh
- qemu-session.sh
- qemu-trace.sh
- run86.sh
- ufs_cg.py
- ufsfsck.py
- ufspatch.py
- ufsread.py
- ufswrite.py
- 01_baseline_no_cdrom_found.png
- 02_eide_loaded_cd_detected.png
- 03_mountroot_sd0_panic.png
- 04_atapi_interrupt_timeout.png
- 05_fdd_boot_root_mounted_OK.png
- 06_fdd_boot_installer_reached.png
- 07_eltorito_secmaster_same_timeout.png
- 08_fdd_run1_success.png
- 09_fdd_run2_SAME_FAILURE.png
- 10_PATCHED_eltorito_success.png
- 11_install_phase1_completed.png
- 12_install_copying.png
- 13_hdd_boot_ok.png
- 14_hdd_rootfs_present.png
- 15_final_install_completed.png
- 16_secondphase_driverdisk_prompt.png
- 17_secondphase_panic_after_skip.png
- 18_bootfloppy_rejected_as_driverdisk.png
- 19_geometry_error_288_vs_144.png
- 20_betadisk_rejected.png
- 21_stockdisk_accepted_starting.png
- 22_driverdisk_ACCEPTED_after_version_match.png
- 23_NO_PROMPT_straight_to_starting.png
- 24_oneshot_script_hddboot_ok.png
- 25_rebuild_eltorito_boot.png
- 26_rebuild_installer_reached.png
- 27_second_phase_installer_reached.png
- 28_unpatched_kernel_interrupt_timeout_loop.png
- 29_full_workspace_desktop.png
- 30_runA_control_no_dual_channel.png
- 31_runB_dual_channel_rsd0a_clean.png
- 32_runB_second_phase_device_summary.png
- 33_runB_configure_irq_14_15.png
- 34_runB_packages_available.png
- 35_runB_cdless_boot_workspace.png
- 36_recipe_built_first_hdd_boot.png
- 37_clean_shutdown_safe_to_turn_off.png
- 38_recipe_built_cdless_workspace.png
- 39_realhw_eide_debug_mountroot_panic.png
- 40_realhw_ali_unsupported_pci.png
- baseline_md5.txt
- deleted_20260828.txt
- VERIFICATION.md
- 01_pic_interrupt_bug.md
- 02_cd_ufs_upgrade.md
- 03_driverdisk_discriminator.md
- 04_beta_driver_disks.md
- 05_realhw_boot_failure.md
- boot1f_diag.bin
- boot1f_orig.bin
- EIDE_reloc_401.bin
- EIDE_reloc_403.bin
- mach_kernel.bin
- mach_kernel_patched.bin
- standalone_boot.bin
- standalone_sarld.bin
.gitignore
HANDOFF.md
README.ko.md
README.md
WORKNOTE.md

# CDN으로 사용하기

jsDelivr

jsDelivr는 공개 GitHub 리포지토리를 별도 설정 없이 CDN으로 즉시 서빙합니다. 버전과 파일을 고르면 웹페이지에 바로 붙일 수 있는 링크와 예시 코드가 만들어집니다.

버전

파일

링크

예시

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

*English · [한국어](README.ko.md)*

The filesystem on the OPENSTEP 4.2 installation CD is **4.3BSD UFS**, not ISO 9660.
As shipped, the CD does not boot on a PC. This repository documents how to
build a **single El Torito bootable ISO** from the original CD image and a 2.88 MB
boot floppy, together with the evidence behind every change.

**Status: complete under emulation. Real hardware varies by machine; the project is frozen.**
The scope verified in qemu is: boot from the CD → complete the installation → boot the
installed system from the hard disk **without it asking for a driver floppy**, through the
installer's second phase, all the way to **the Workspace**. Booting with the CD removed
behaves the same way.

**Two older boards (Intel 430VX, ALi Aladdin V) failed; a Core 2 Duo era board booted
successfully over IDE. A Pentium II or later is recommended.** See the
[FAIL NOTICE](#fail-notice--it-failed-on-two-older-boards) below.

**★ The CD-ROM must sit in the master position of its IDE channel.** OPENSTEP abandons a
channel whose master is absent, so a CD alone as a slave is never detected. qemu detects a
lone slave, so the constraint is invisible there.

---

## FAIL NOTICE — it failed on two older boards

**This boot CD fails on older machines. A Pentium II or later is recommended.**
What follows is limited to what was actually observed.

### Real-hardware results

| Machine | Result |
|---|---|
| Intel 430VX (Award BIOS ID `2A59GB3I`, 64 MB) | **Failed** |
| ALi Aladdin V (M1541 / M1533 / M5229, 256 MB) | **Failed** |
| Core 2 Duo era board, attached over IDE | **Booted successfully** |

Completing the installation and reaching the Workspace was confirmed under emulation.

### Succeeded (emulators)

| Environment | Result |
|---|---|
| qemu 6.2.0 | Boots from CD → installation completes → reaches the Workspace. Booting with the CD removed behaves the same |
| 86Box (430VX/PIIX3, real Award BIOS ROM, Pentium MMX 200, 64 MB) | Boots from CD → reaches the install screen |

### Symptoms on the two boards that failed

**Board A — Intel 430VX, Award BIOS ID `2A59GB3I`, 64 MB**

With the CD alone on the IDE secondary slave, the boot stops right after the `boot:` prompt.

```
Config file "/private/Drivers/i386/System.config/Default.table" not found
System config file 'System' not found
```

Moving the CD to the secondary master lets the boot proceed further.

**Board B — ALi Aladdin V (M1541 / M1533 / M5229), 256 MB**

The kernel starts, the EIDE driver attaches, and the CD is detected.

```
sd0: HL-DT-ST DVD-RAM GH22NP20 1.00
sd0: Device Block Size: 2048 bytes
sd0: Disk Label:        OPENSTEP_4.2J
```

But `Registering: sd0a` never appears, and mounting root stops.

```
sd0a: Read attempt with no valid label
vfs_mountroot: error=5
panic: (Cpu 0) vfs_mountroot: cannot mount root
```

`error=5` is EIO. Which board produced this particular log **was not confirmed.**

### Tried, with no change in outcome

- `Multiple Sectors = No` (multi-sector transfers disabled)
- Several different CD-ROM drives
- Booting with `-v`

### Limits established by measurement

- **The 4.03 EIDE driver accepts exactly four PCI IDE controllers** — PIIX `0x12308086`,
  PIIX3 `0x70108086`, PIIX4 `0x71118086` and RZ1000 `0x10001042` (confirmed by disassembling
  the driver). ALi M5229 `0x522910b9` is not among them. Setting `Bus Type = PCI` on board B
  produces `hc0: Unsupported PCI hardware` and `Instance 0 of Dual EIDE failed the probe.`
- **A slave is not detected on an IDE channel whose master is absent.** A CD alone on the
  secondary slave yields `hc1: no devices detected` and then the `root device?` prompt.
  Measured under 86Box across three configurations. qemu does detect a lone slave, so the
  constraint never surfaces there.
- **The NeXT mini-monitor offers nothing to inspect with.** It has six commands
  (`?`/`help`, `reset`, `gdb`, `halt`, `reboot`, `continue`) and no memory, register or stack
  examination. `gdb` speaks Ethernet KDP only, and the boot floppy carries no Ethernet driver.

The full account is in
[`06_analysis/05_realhw_boot_failure.md`](06_analysis/05_realhw_boot_failure.md).
## The original problem

This repository begins from notes written in 2013. The procedure for building a
bootable ISO was already documented then, but **an attempt to replace the driver
inside the CD's UFS had failed and was left unresolved.**
Source: [the wiki section "Additional attempts that failed"](https://workspace.onionmixer.net/wiki/Creating_an_OPENSTEP_Boot_CD_onion)
(its certificate has expired, so `curl -k` is needed; a local copy is in
`04_docs/wiki/00_main_onion.txt`).

Two approaches were tried at that time, and both failed:

1. **Reformatting the UFS from inside OPENSTEP.** The UFS was mounted read-only under
   Linux and archived with tar; a raw vmdk was then attached to an OPENSTEP virtual
   machine, formatted there, and the archive was restored onto it with the EIDE driver
   replaced. The result could be mounted under Linux, but **OPENSTEP could not mount it
   as its root filesystem at boot.**
2. **Mounting the extracted UFS under FreeBSD in order to edit it.** The image was
   written to an SD card partition with dd, and mounting it under FreeBSD was then
   attempted. It did not work at all.

### How it was actually resolved

**Reformatting the UFS was never necessary.** The filesystem can be modified **byte by
byte, in place**, without altering its layout at all. Doing so removes any opportunity
for the root-mount failure that the reformatting approach caused. To make that
possible, purpose-built UFS read, write and consistency-check tools were written, none
of which require root privileges (`04_tools/ufsread.py`, `ufswrite.py`, `ufsfsck.py`).

Furthermore, what was actually preventing the disc from booting was not the driver
replacement but the following two things:

- `EIDE` was absent from the `Boot Drivers` list on the boot floppy, so **the driver was
  never loaded in the first place** (change ②).
- The kernel omitted the EOI when handling an 8259 spurious interrupt, which **left the
  PIC permanently wedged** (change ①).

Replacing the driver (change ④) was needed so that the installed system receives the
latest available driver, 4.03. On its own it does not fix the boot failure.

## Quick start

```bash
04_tools/mkopenstepiso.sh <original-ISO> <boot-floppy.img> <output-ISO>

# Actual example (takes about 20 seconds)
04_tools/mkopenstepiso.sh \
  /mnt/MAMEALL/OperatingSystems/NeXTSTEP/OPENSTEP/iso_image/japan/os42j.iso \
  02_work_result/Temp/F288C.img \
  02_work_result/os42j_boot.iso
```

To test it:
```bash
qemu-img create -f raw hdd.img 1G
qemu-system-i386 -nodefaults -M pc -cpu pentium3 -m 64 \
  -drive file=hdd.img,if=ide,index=0,media=disk,format=raw \
  -drive file=02_work_result/os42j_boot.iso,if=ide,index=3,media=cdrom,format=raw \
  -boot d -no-reboot
```
> `-nodefaults` is required. Without it, qemu attaches an empty DVD-ROM to the IDE
> secondary master. The kernel then selects that empty drive as its root device and
> panics with `vfs_mountroot: error=15`. This is reproducible with qemu's default device
> configuration; how real hardware behaves was not determined.

The target hardware layout is: **hard disk on IDE primary master (`index=0`),
CD-ROM on IDE secondary slave (`index=3`).**

---

## What must be changed to make it boot — six places

| # | Target | Size change | Symptom if left unchanged |
|---|---|---|---|
| ① | `/mach_kernel` inside the boot floppy — missing master-PIC EOI when handling a spurious 8259 IRQ15 (cascade) | none (12 bytes rewritten) | During installation: `interrupt timeout` → `IO error on pagein` |
| ② | `System.config/Instance0.table` inside the boot floppy — add `EIDE` to `Boot Drivers` | 505 → 510 bytes | Installation stops at `No SCSI controller or CD-ROM drive found` |
| ③ | `EIDE.config/Instance0.table` inside the boot floppy — `Version` 4.01 → 4.03 | none (1 byte) | After installation, booting from the hard disk asks for a driver floppy |
| ④ | `EIDE.config` in two places inside the CD's UFS — 4.01 → 4.03 | +53,276 bytes in total across the two locations | The installed system receives the older 4.01 driver |
| ⑤ | `/mach_kernel` inside the CD's UFS — the same PIC fix as ① | none (12 bytes rewritten) | **The installed system** repeats `interrupt timeout` endlessly on its first boot |
| ⑥ | `EIDE.config/Default.table` in two places inside the CD's UFS — make it dual-channel | 818 → 891 bytes per location (+146 bytes in total) | The installed system cannot see the CD on the secondary channel → `Can't open /dev/rsd0a` → single-user |

**①, ② and ③ change the boot floppy; ④, ⑤ and ⑥ change the CD's UFS.**

The kernel is patched twice because these are two different files. ① fixes the kernel the
installer runs (on the boot floppy); ⑤ fixes the kernel the installed system runs (copied
from the CD). Without ⑤ the installation completes, but the installed system wedges its PIC
on its first boot. Under a graphical boot that log is hidden behind the panel, so it looks
as though the boot stops at `Starting OPENSTEP`.

⑥ must be applied after ④. The 4.01 original of `Dual_EIDE.table` has no
`Master Secondary` / `Slave Secondary` entries.

**The complete recipe, down to individual addresses and bytes, is in
[`WORKNOTE.md`](WORKNOTE.md).**

---

## Documents

| Document | Contents |
|---|---|
| **[`HANDOFF.md`](HANDOFF.md)** | **Handover notes** — how to reproduce, pitfalls, what is and is not verified, working rules. Start here if you are new |
| **[`WORKNOTE.md`](WORKNOTE.md)** | **The recipe** — what to write, where, and with which bytes |
| [`06_analysis/01_pic_interrupt_bug.md`](06_analysis/01_pic_interrupt_bug.md) | The 8259 PIC lockup and the kernel bug — symptom, trace, disassembly, verification of the fix |
| [`06_analysis/02_cd_ufs_upgrade.md`](06_analysis/02_cd_ufs_upgrade.md) | Replacing the EIDE driver 4.01 → 4.03 inside the CD's UFS; measured UFS structure and safeguards |
| [`06_analysis/03_driverdisk_discriminator.md`](06_analysis/03_driverdisk_discriminator.md) | How the second installation phase decides whether a floppy is a valid driver disk (bootloader disassembly) |
| [`06_analysis/05_realhw_boot_failure.md`](06_analysis/05_realhw_boot_failure.md) | **Real-hardware boot failure — cause identified** — the IDE channel master requirement, the boot chain, how it was instrumented, the 86Box reproduction environment |
| [`06_analysis/04_beta_driver_disks.md`](06_analysis/04_beta_driver_disks.md) | Survey of the beta driver floppies |
| [`05_findings/VERIFICATION.md`](05_findings/VERIFICATION.md) | Cross-verification record — which conclusions were wrong and how that was established |
| `05_findings/*.png` | 38 qemu screen captures used as evidence |
| `04_docs/wiki/` | Local copies of the wiki pages that were used as references |

---

## Directory layout

```
README.md                Entry point (English)
README.ko.md             Entry point (Korean)
HANDOFF.md               Handover notes (reproduction, pitfalls, verified scope)
WORKNOTE.md              The recipe (addresses and bytes)

01_original/             Original distribution from peterwong.net
                         ★ CANNOT be regenerated — must be preserved
    F288.img.zip           Original 2.88 MB boot floppy, before any modification
    F288.vmdk.zip          A vmdk descriptor that exposes that image as an IDE disk
    OPENSTEP42CD.Block00*.lbl.zip   Three disklabels (plain / El Torito / m68k-compatible)
    NS_CKSUM.ZIP           Original C source for the disklabel checksum
    bootblock.h            NetBSD's disklabel structure definitions

02_work_result/          Outputs and inputs
    os42j_boot.iso         ★ Final bootable ISO (545,005,568 bytes)
    F288G_hintfix.img      ★ Final boot floppy — changes ①, ② and ③ applied
    F288E_picfix.img         Intermediate: ② and ① applied
    F288D_bootdrivers.img    Intermediate: ② only
    Temp/F288C.img         Input: the original boot floppy, which already contains
                           the 4.03 driver.
                           ★ CANNOT be regenerated — it was hand-built inside an
                           OPENSTEP virtual machine. Must be preserved
    OS42JCD.ufs            Input: UFS of the Japanese CD
                           (identical to extracting os42j.iso with skip=80)
    OS42ECD.ufs            UFS of the English CD
                           (identical to extracting os42e.iso with skip=80)
    OPENSTEP42JCD_makeafter.lbl   Reference: a hand-built, verified disklabel.
                           `04_tools/mkopenstepiso.sh` does not need it; it derives the
                           label from the original ISO instead
    mkopenstepiso.sh       ⚠ An **identical copy** of 04_tools/mkopenstepiso.sh
                           (see the caution below)
    writelabel.sh          Original 2013 script (a single dd call) — kept for reference
    checksum/ns_checksum.c   C source for the checksum calculation
    README_scripts.txt     The 2013 scripts' contents and how they relate to the new one

03_resource/             Source material — ★ CANNOT be regenerated, must be preserved
    Drivers/                 12 OPENSTEP driver packages (*.pkg.tar)
    Floppyimages/            4.2_Beta_Drivers_1.img / _2.img, 4.2_Driver_Disk.img,
                             4.2_Beta_Drivers_1_v401.img (an experiment in which only
                             the Version string was changed),
                             OPENSTEP_Boot_and_Driver_Disk_Images.rtf (original distribution notes)

04_docs/wiki/            Local copies of six wiki pages used as references
04_tools/                19 tools (listed below)

05_findings/             Evidence and records
    VERIFICATION.md          Cross-verification record — which conclusions were wrong
                             and how that was established
    baseline_md5.txt         Checksum baseline for the important files
    deleted_20260828.txt     Files removed during cleanup, and how to regenerate them
    01~38_*.png              38 qemu screen captures, in chronological order

06_analysis/             Detailed analyses and the binaries they examine
    01_pic_interrupt_bug.md        The 8259 PIC lockup and the kernel bug
    02_cd_ufs_upgrade.md           Replacing EIDE 4.01 → 4.03 inside the CD's UFS
    03_driverdisk_discriminator.md How a driver floppy is accepted or rejected
                                   (bootloader disassembly)
    04_beta_driver_disks.md        Survey of the beta driver floppies
    mach_kernel.bin / _patched.bin The kernel before and after the patch (1,113,724 bytes)
    EIDE_reloc_401.bin / _403.bin  The two generations of the driver binary
    standalone_boot.bin            The secondary bootloader (a flat binary; load base 0x3000)
    standalone_sarld.bin           The standalone linker
```

> IDA databases (`*.i64`) are deliberately not kept. Reopening the `.bin` files above
> regenerates them within seconds.
> `standalone_boot.bin` is a flat binary, not a Mach-O file. It must be loaded at
> **base address 0x3000, in 32-bit mode.** The derivation of that base address is in
> `06_analysis/03_driverdisk_discriminator.md`.

---

## Tools

| Tool | Purpose |
|---|---|
| **`04_tools/mkopenstepiso.sh`** | **Original ISO + boot floppy → bootable ISO in one command** (applies ①–⑥ and computes the disklabel) |
| `cd_kernel_pic.py` | Change ⑤ — patches the i386 slice of the CD's fat kernel (validates the fat and Mach-O structures) |
| `cd_eide_dual.py` | Change ⑥ — `Default.table` ← `Dual_EIDE.table`, in both locations |
| `ufsread.py` | Reads NeXT/OPENSTEP UFS without root privileges. Subcommands: `info`, `ls`, `tree`, `cat`, `stat` |
| `ufspatch.py` | Replaces a file in place, only when the new contents fit the existing allocation |
| `ufswrite.py` | Replaces and creates files; allocates blocks and inodes; inserts directory entries |
| `ufs_cg.py` | Recomputes 4.3BSD `ocg` cylinder-group accounting fields |
| `ufsfsck.py` | Whole-filesystem consistency check (duplicate block references, `di_blocks`, inode bitmap, accounting) |
| `cd_eide_upgrade.py` | Replaces the CD's EIDE driver 4.01 → 4.03 in both locations |
| `patch_kernel_pic.py` | Applies change ① and verifies the whole image afterwards |
| `inspect_lbl.py` | Dumps a disklabel and cross-checks its front porch and checksum (exits 1 on a mismatch) |
| `nexttar.py` | Reads the `*.tar.Z` archives inside OPENSTEP `.pkg` bundles (NeXT's extended tar with a 224-byte name field) |
| `ns_checksum` | Computes the disklabel v3 checksum |
| `pic8259_replay.py` | Reconstructs 8259 PIC state from a qemu trace |
| `qemu-boot.sh` | El Torito boot test (screenshots, key injection, selectable CD-ROM slot) |
| `qemu-fdd.sh` | Boots the floppy directly, so tests can be repeated without rebuilding the ISO |
| `qemu-session.sh` | Long-running session (stepping through installation, inserting a floppy at runtime) |
| `qemu-trace.sh` | Collects IDE and PIC traces (⚠ deletes `OUT` and the HDD file, then recreates them) |
| `check_repo.sh` | Checks copy synchronisation, the checksum baseline and document links |
| `make_boot1f_diag.py` | Builds a diagnostic `boot1f` that prints the BIOS-reported geometry |
| `run86.sh` | 86Box launcher — clears any running instance before starting, captures the screen |
| `make_eide_debug_iso.py` | Builds a diagnostic ISO by rewriting only the boot floppy's EIDE settings (`Debug` and friends) |

> ### ⚠ Caution — the qemu harness needs a short `OUT` path
>
> The `qemu-*.sh` scripts open the qemu monitor as a UNIX socket. That socket path must be
> **shorter than 108 bytes** (a kernel limit). If it is longer, qemu dies the moment it
> starts, which looks like a boot failure. `qemu-boot.sh` rejects an `OUT` of 90 bytes or
> more up front, exiting with code 2. Use a short path such as `OUT=/tmp/os42bt`.
>
> Also, **do not edit these scripts while a test is running.** bash reads a script
> incrementally as it executes, so editing the file mid-run kills the loop. Work on a
> copy if a change is needed during a test.

> ### ⚠ Caution — `mkopenstepiso.sh` exists as a copy in two places
>
> | Location | Role |
> |---|---|
> | `04_tools/mkopenstepiso.sh` | **The canonical file.** Make every edit here |
> | `02_work_result/mkopenstepiso.sh` | A **copy**, kept beside the build outputs for convenience |
>
> The two files **must have identical contents.** After editing the canonical file,
> copy it:
> ```bash
> cp 04_tools/mkopenstepiso.sh 02_work_result/mkopenstepiso.sh
> md5sum 04_tools/mkopenstepiso.sh 02_work_result/mkopenstepiso.sh   # the two values must match
> ```
> The script locates `04_tools/` from its own position (it identifies the directory by
> the presence of `ufsread.py`), so running it from either location behaves identically.
> If it cannot find that directory, it refuses to run.
>
> The 2013 script had the same name but entirely different contents. To remove that
> ambiguity, both locations now hold the current version; the 2013 contents are
> preserved in `02_work_result/README_scripts.txt`.

### Commonly used commands
```bash
# Inspect the contents of a UFS image
#   floppies: --base 0x28000     CD UFS: base 0 (omit the option)
python3 04_tools/ufsread.py tree 02_work_result/F288G_hintfix.img --base 0x28000 /private/Drivers/i386
python3 04_tools/ufsread.py cat  02_work_result/OS42JCD.ufs /private/Drivers/i386/EIDE.config/Default.table

# Cross-check an ISO's disklabel against the actual position of its UFS
python3 04_tools/inspect_lbl.py 02_work_result/os42j_boot.iso --ufs 02_work_result/OS42JCD.ufs

# Check UFS consistency
python3 04_tools/ufsfsck.py 02_work_result/F288G_hintfix.img --base 0x28000
```

---

## Environment on this machine

- Available: `mkisofs` (which is in fact **genisoimage 1.1.11**),
  `qemu-system-i386 6.2.0`, `gcc`, `python3` (with capstone), `7z`, `xxd`,
  IDA with Hex-Rays (through MCP)
- Not available: `xorriso`, the real `cdrtools`, `vbindiff`, sleuthkit,
  any FUSE-based UFS tool
- **UFS cannot be mounted through the kernel on this machine**, because `sudo` requires
  a password. Every UFS access in this work is therefore done with the purpose-built
  Python tools, which need no root privileges.
- **Disk space**: `/mnt/USERS`, where this project lives, is 100% full with only
  8.2 GB free. Write ISO rebuild output to `/` (56 GB free) or to a temporary
  directory instead.

---

## Known limitations

- **It fails on older machines.** Intel 430VX and ALi Aladdin V both failed; a Core 2 Duo
  era board booted successfully over IDE. A Pentium II or later is recommended.
  The observed facts are in the FAIL NOTICE above; the full account is in
  [`06_analysis/05_realhw_boot_failure.md`](06_analysis/05_realhw_boot_failure.md).
- Every success reported here was obtained under qemu 6.2.0.
- **The IDE channel the CD sits on must have a master device.** OPENSTEP's EIDE driver gives
  up on a channel whose master is absent instead of probing the slave, so a CD alone on the
  secondary slave produces `hc1: no devices detected` followed by the `root device?` prompt.
  Moving the CD to the master position, or attaching any drive as that channel's master,
  resolves it. qemu detects a lone slave, so the constraint is invisible there — this was
  measured under 86Box.
- How the dual-channel configuration introduced by ⑥ behaves on real hardware that has
  no secondary channel at all could not be determined. The boot floppy already runs with
  the same configuration, but that is evidence from qemu only.
- The English CD (`os42e.iso`) was not tested. `04_tools/mkopenstepiso.sh` derives the
  disklabel, the volume ID and the front porch from whichever ISO it is given. Neither
  building nor installing it was attempted.

An earlier revision listed "after `Starting OPENSTEP` appears, no further progress becomes
visible (whether it is stalled internally was not determined)". That entry has been removed
because the cause was found: the installed kernel did not carry change ①, and change ⑤ fixes
it. The full account is in [`05_findings/VERIFICATION.md`](05_findings/VERIFICATION.md).

OPENSTEP-BOOTCD-INTEL

오너의 다른 레포

파일 탐색기

# CDN으로 사용하기

Was this content helpful?

Recent Feedback

OPENSTEP-BOOTCD-INTEL

오너의 다른 레포

파일 탐색기

# CDN으로 사용하기

Was this content helpful?

Recent Feedback

Download README