| ... |
... |
@@ -18,7 +18,7 @@ I use WinImage to set up the DOS boot images from a modern Windows machine. You |
| 18 |
18 |
|
| 19 |
19 |
Included in `/extras` of the repo and the LiveCD is the BusyBox-1.01 source code used to build the busybox binaries used in the `initfs.gz` init environment. The `initfs` version is built to be as small as possible, building to under 100K. |
| 20 |
20 |
|
| 21 |
|
-Building is done using the `uClib` build system. A copy of the system is included in `/extras` on the LiveCD. You can use it on a modern Linux system to build a compatible BusyBox binary. |
|
21 |
+Building is done using the `uClib` build system. A copy of the system is included in `/contrib` in the git repo. You can use it on a modern Linux system to build a compatible BusyBox binary. |
| 22 |
22 |
|
| 23 |
23 |
1. Extract the root filesystem from the archive, mount it with something like `sudo mount -o loop,rw root_fs_i386.ext2 /path/to/mountpoint`. |
| 24 |
24 |
2. You can then copy the BusyBox source into the root filesystem with something like `cp -r busybox-1.01 /path/to/mountpoint/busybox-1.01`. |
| ... |
... |
@@ -28,14 +28,16 @@ Building is done using the `uClib` build system. A copy of the system is include |
| 28 |
28 |
1. `make allnoconfig` |
| 29 |
29 |
2. `make config` |
| 30 |
30 |
6. `make` |
| 31 |
|
-7. You may get errors at the end, but they're likely only for the docs step (not important) |
|
31 |
+7. You may get errors at the end, but they're likely only for the docs step (not important). Check that it spat out a `busybox-1.01/busybox` binary, and that it executes (it should, even on amd64) |
| 32 |
32 |
|
| 33 |
33 |
### `initfs.gz` |
| 34 |
34 |
|
| 35 |
|
-This is a `gzip`'d ext2 disk image. If you make a new image, you must use the `-r 0` argument with `mke2fs`. You want this to be as small as possible, as it loads into RAM entirely at boot. Any bigger than ~400K and you'll risk running out of RAM with 4MB. |
|
35 |
+This is a `gzip`'d ext2 disk image. If you make a new image, you must use the `-r 0` argument with `mke2fs`. You want this to be as small as possible, as it loads into RAM entirely at boot. Any bigger than ~500K and you'll risk running out of RAM with 4MB. |
| 36 |
36 |
|
| 37 |
37 |
You can place additional modules in `/lib/modules/2.2.26/misc` and load them via `linuxrc` using `insmod`. |
| 38 |
38 |
|
| 39 |
39 |
### `FS.IMG` |
| 40 |
40 |
|
| 41 |
41 |
This is a raw ext2 filesystem image, again using `-r 0` with `mke2fs` for compatibility. 320MB is the largest image that will fit on a 650MB CDROM while still including the full set of documentation and packages. |
|
42 |
+ |
|
43 |
+`fs.img` files for each tagged release are uploaded to the Github releases page. Unfortunately this is the easiest way to distribute them. `/rootfs` in the git repo represents the state of the filesystem at a given commit, but it lacks hard links and special device nodes, which would need to be recreated based on a tagged image. |
| 42 |
44 |
|