Xbox Linux Issues

Here is a list of issues that are blocking general functionality on Xbox Linux.

XBPartitioner Table and MBR incompatibility

This issue is relevant to native Linux installs. In a native Linux install, the user formats empty regions of their hard drive and adds an MBR to the hard drive, which is used by Cromwell to access the Linux boot partition and load linuxboot.cfg, the kernel, and the initrd. As Cromwell is currently set up, it can't find Linux partitions without the MBR.

The MBR partitioning/boot scheme uses a 512 byte record at the beginning of the drive. Since an actual boot record isn't needed, the first 440 bytes are filled with zeroes when using fdisk. [layout information]

The FATX filesystem has a config area of 1024 bytes at the beginning of the drive. Only 48 bytes are officially used; the rest are zeroes. On a stock-formatted Xbox hard drive, the contents of this config area don't seem to matter much to ind-BIOS (tested), although Insignia may use it in the future. If a stock FATX config area has its first 512 bytes overwritten by an MBR, it is not known to cause problems with any other Xbox functionality. (based on the fact that native Linux installs have been run in this way for years)

The problem arises with the XBPartitioner table, a custom partitioning scheme for Xbox hard drives that was never officially supported by Xbox Linux. The XBPartitioner table provides 14 partition "slots" for FATX partitions. The partition table is written into unused space in the FATX config area. XBPartitioner wipes the entire config area when writing a partition table including any MBR contents, other tools are untested so far. And fdisk overwrites the first 512 bytes of the FATX config area with an MBR. Another issue arises in that the two partitioning schemes overlap, even if only the necessary data were written for both XBPartitioner table and MBR.

This struct shows the layout of the partition table:

From the unofficial XBPartitioner patches for the old Xbox kernel:

// Temporary struct used to load XBPartitioner data directly from disk.
typedef struct
{
	char name[16];
	u32  flags;
	u32  start;
	u32  size;
	u32  reserved;
} XBPartitionerTableEntry;

// Temporary struct used to load XBPartitioner data directly from disk.
typedef struct {
	char                 magic[16];
	char                 reserved[32];
	XBPartitionerTableEntry partitions[FATX_XBPARTITIONER_PARTITIONS_MAX];
} XBPartitionerTable;

The XBPartitioner table entries start at 48 bytes, and each partition's entry is 32 bytes in size. With 14 partitions, the XBPartitioner table ends at 496 bytes, and overwrites a good chunk of the relevant MBR content, which starts at 440 bytes. So tool modification alone can't make these schemes compatible.

The XBPartitioner table has no metadata, only partition entries, and has no known way of redefining the number of available partitions. However, if the XBPartitioner table only had 12 partitions, the partition table would end at 432 bytes and the two schemes could coexist.

Possible Solutions

F Takes All

This was the typical scheme used by historical Xbox Linux. The area after E would be used for Linux partitions. With larger hard drives available, there is a need for Xbox Linux to coexist with other content on the user's drive.

A 12 partition XBPartitioner Table

This would involve attempting to get general acceptance of changing the XBPartitioner spec to 12 partitions, so it doesn't overlap with MBR. Or providing a custom set of tools that support this. Xbox-based, Linux-based, and PC-based Xbox partition management tools would have to be updated to support this, and the BIOS patches would probably have to be updated. Pros

• Cromwell would not need to be modified
• The 512 byte boundary could be considered the starting point for future config area modifications
• Very few users have more than 7, much less 14 partitions on their Xbox which provide little practical use
• Any Linux PC can easily mount the Linux partitions

Cons

• Lots of software would need to be updated, including BIOSes, partitioning tools, and disk formatting tools in Xbox Linux. There might be a more elegant solution.

Using the XBPartitioner Table To Define Linux Partitions

Pros

• No partitioning scheme incompatiblity management
• No dual partitioning scheme; both Linux and Xbox tools would have awareness of the full drive partition table, to avoid accidentally creating overlapping partitions
• Unused per-partition flags in the XBPartitioner table could be used to mark partitions as Linux as a future standard
• Scripts utilizing dd to read the XBPartitioner table could be used as a stopgap for full kernel support

Cons

• The Cromwell Grub code would need to be modified to use the XBPartitioner table in place of MBR (this may not be overly complicated)
• Scripts, tools, or kernel support will be needed in order to mount these partitions in Linux, both on the Xbox and on other PCs
• Any tools used to mount Linux partitions and edit their characteristics would have to be updated to support it, primarily apps that mount non-FATX partitions. This could be simple
• FATX kernel support would need to be ported for a long term performant solution, but fatxfs performance still needs to be evaluated on Xbox.