the initial partitioning is still done by the firmware (?) prior to the /sbin/init script being run
This is /linuxrc in the initrd.
Code:
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 320 blocks [1 disk] into ram disk... done.
VFS: Mounted root (ext2 filesystem).
empeg-pump v0.03 (19980601)
Press Ctrl-A to enter pump...VFS: Mounted root (ext2 filesystem) readonly.
change_root: old root has d_count=1
Trying to unmount old root ... okay
By "pressing Ctrl-A" (i.e. sending \x01 down the serial port) the upgrader stops /linuxrc from mounting the disk-based root partition on / and exiting to {/dev/hda5}/sbin/init -- and, instead, causes it to enter "upgrader mode", where the commands available include partitioning a drive, and filling a partition from a gzipped filesystem image down the serial port.
Yeah, I see the ext2 initrd (aka. "ramdisk") image in flash (/proc/flash_b0000), but it's mostly just one big closed-source executable.
What I don't know (for sure), is exactly what it does when the .upgrader encounters a "DRIVE" chunk, which seems to mean "create a partition table", sometimes.
Where is the decision made as to whether or not to overwrite the on-disk partition table with a new one? Does the Windows-based upgrader decide, or does linuxrc on the initrd decide?
I'm just wondering if an altered swap/spare/dyndata partition is reverted when a v2.01 or v3a11 software .upgrade file is applied over top of the built disk.
Because all of the .upgrade files seem to include the "DRIVE" chunk for hda, not just the builder .upgrade.
EDIT: What I call a "DRIVE hda" chunk, is a type 0x20 chunk inside the .upgrade file.
Previous Topic
Index
