[IAEP] Arch Linux XO image and Sugar packages

[James Cameron]

On Wed, Oct 09, 2013 at 02:56:55PM +0200, Daniel Narvaez wrote:
> On Wednesday, 9 October 2013, James Cameron wrote:
> > On Tue, Oct 08, 2013 at 09:32:34PM -0500, Sebastian Silva wrote:
> > > dir u:\
> > >
> > > clears the screen and shows some garbled text.
> > > On my laptop the usb drive mounts fine.
> > > Strange, no ?
> 
> > Looking into it further, it may relate to how Daniel advises you
> > to effectively destroy the device partition table by making the
> > filesystem on /dev/sdb rather than the usual methods.  The result
> > may depend on what is already on the USB drive, and so is less
> > predictable
> 
> Can you explain why the result depends on what is already on the
> drive?

Sure.

Summary: initially it was because I thought mkfs.ext4 does not erase
GPT, but as it turns out, it kindly does so.  The situation has
changed since I last looked into this.  It remains less predictable,
but only if older versions of mke2fs are used.

The firmware of an XO, and other firmware, and various operating
systems, read blocks on the device to assess the partition table type.

There are several different types of partition table, the most common
is the MBR [1], less common is the GPT [2].  Open Firmware supports
both types of partition table, as well as devices without any table.

(It is difficult to code for every eventuality, and it isn't clear what
should be trusted first when there is multiple evidence of data; an
MBR, a GPT, or an ext2 filesystem signature.)

In the following tests, a 128MB flash drive was used, the drive was
erased between each test.  Blocks are 512 bytes long.

Using gparted to create a new MBR partition table writes to the
first block [3].

Using gparted to create a new GPT partition table writes to the first
block a protective MBR, followed by a primary GPT header and entries,
and a secondary GPT header near the end of the disk [4].

Using mkfs.ext4 to create a filesystem overwrites the first block with
zeroes, and metadata begins at the second block [5].

If the device contains a GPT at the time, mkfs.ext4 also overwrites
the secondary GPT header [6].

There is no obvious requirement for mkfs.ext4 to do this.  The code
can be found in mke2fs.c in the function main [7], with the comment:

	/*
	 * Wipe out any old MD RAID (or other) metadata at the end
	 * of the device.  This will also verify that the device is
	 * as large as we think.  Be careful with very small devices.
	 */

The code erases 64kB at the end of the device.

1.  http://en.wikipedia.org/wiki/Master_Boot_Record
2.  http://en.wikipedia.org/wiki/GUID_Partition_Table
3.  http://dev.laptop.org/~quozl/2013-10-10-mkfs.ext4-vs-gpt/dd.mbr.txt
4.  http://dev.laptop.org/~quozl/2013-10-10-mkfs.ext4-vs-gpt/dd.gpt.txt
5.  http://dev.laptop.org/~quozl/2013-10-10-mkfs.ext4-vs-gpt/dd.ext4.txt
6.  http://dev.laptop.org/~quozl/2013-10-10-mkfs.ext4-vs-gpt/dd.gpt.ext4.txt
7.  http://dev.laptop.org/~quozl/2013-10-10-mkfs.ext4-vs-gpt/mke2fs.c.html.gz#splat

-- 
James Cameron
http://quozl.linux.org.au/