ignore partition table on disks with AIX label

The on-disk data structures from AIX are not known, also the filesystem layout is not known. There is a msdos partition signature at the end of the first block, and the kernel recognizes 3 small (and overlapping) partitions. But they are not usable. Maybe the firmware uses it to find the bootloader for AIX, but AIX boots also if the first block is cleared.

Handle the whole disk as empty disk.
This fixes also YaST who compares the output from parted (and formerly fdisk) with /proc/partitions. fdisk recognizes the AIX label since a long time, SuSE has a patch for parted to handle the disk label as unknown.

dmesg will look like this:
sda: [AIX] unknown partition table

---
 fs/partitions/msdos.c |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

Index: linux-2.6.16/fs/partitions/msdos.c
===================================================================
@@ -59,6 +59,19 @@ msdos_magic_present(unsigned char *p)
 	return (p[0] == MSDOS_LABEL_MAGIC1 && p[1] == MSDOS_LABEL_MAGIC2);
 }
 
+/* Value is EBCIDIC 'IBMA' */
+#define AIX_LABEL_MAGIC1	0xC9
+#define AIX_LABEL_MAGIC2	0xC2
+#define AIX_LABEL_MAGIC3	0xD4
+#define AIX_LABEL_MAGIC4	0xC1
+static int aix_magic_present(unsigned char *p)
+{
+	return (p[0] == AIX_LABEL_MAGIC1 &&
+		p[1] == AIX_LABEL_MAGIC2 &&
+		p[2] == AIX_LABEL_MAGIC3 &&
+		p[3] == AIX_LABEL_MAGIC4);
+}
+
 /*
  * Create devices for each logical partition in an extended partition.
  * The logical partitions form a linked list, with each entry being

@@ -394,6 +407,12 @@ int msdos_partition(struct parsed_partit
 		return 0;
 	}
 
+	if (aix_magic_present(data)) {
+		put_dev_sector(sect);
+		printk( " [AIX]");
+		return 0;
+	}
+
 	/*
 	 * Now that the 55aa signature is present, this is probably
 	 * either the boot sector of a FAT filesystem or a DOS-type

Hi,

Google "EBCIDIC EBCDIC"
--> http://burks.bton.ac.uk/burks/foldoc/18/36.htm

99.999% of all people have never ever heard of this important encoding anyway, so better don't confuse them additionally ;)

Andreas Mohr

One has to wonder if it might not be better to treat this case as "one partition covering the entire disk", or even better, decode the AIX LVM info and see if there's any LVM segments present on the disk, so as to limit the chances of accidentally splatting live data.

The first 64K of the disk (a 'Physical Volume' in AIX LVM jargon) is a Volume Group Descriptor Area (VGDA) described in <sys/bootrecord.h>

"The VGDA consists of

* BOOTRECORD: - first 512 bytes. Allows the Read Only System (ROS) to boot system
* BAD BLK DIRECTORY - found in <sys/bddir.h>
* LVM RECORD - found in <lvmrec.h>"

(from http://www.ahinc.com/aix/logicalvol.htm)

I'd attach the .h files in question (we have AIX boxes here still), but they have IBM copyrights on them. Best either play "Chinese Wall" or have somebody in IBM OK the use of the .h files...

The check can go once someone has implemented proper support to read the drives. Up to now the bogus partitions cause only confusion and practical doesnt help anyone. So let it go.

Is there any interest in being able to deal with AIX's LVM and/or JFS/JFS2 (probably only read-only)? If so, what level of support would be needed to make it useful?

(Personally, being able to deal with it on a read-only basis for forensics work would be useful - currently there's no really good way to deal with an AIX system in a forensically sound manner, because 'importvg' and friends have a tendency to scribble on the disks....)

Sanest way to approach it would probably be a mostly-userspace that grovels out the LVM data and creates a device-mapper target. ISTR there was such a beast for the EVMS code, but I haven't gone digging for it yet.

A big company who is all hot about Linux expressed no interrest so far to make AIX volumes readable in Linux.

All we want to know initially is how to correctly spot AIX volumes. As I understand it the fs on them isn't from IBM anyway so they probably can't tell us how it works.

Alan

I dont have any more info about the layout.
The code for AIX in fdisk was added around 1999-03-20. So if anyone had any trouble with matching the 4 byte at the beginning of the disks, fdisk would do more or different checks before rejecting such a disk. I'm not sure if fdisk was always the tool of choice, but its a good measure.

I'm looking at the IBM header files on our AIX box. Incidentally, whoever "corrected" the spelling of EBCDIC should note that the same exact typo is in the AIX /usr/include/sys/bootrecord.h I'm looking at. :)

As far as I can tell, the boot ROM snarfs up the first 512 byte block, and then looks for the 'IBMA' magic cookie, then looks at offset 0x1BE for a bog-standard 4-entry partition table, and a 0x55AA at offset 0x1FE.

Additionally, there will be an *ASCII* '_LVM' in the first 4 bytes of physical 512-byte block 7, denoting the start of the LVM control record.

I'd say if you find both the IBMA *and* _LVM cookies intact, you declare it an AIX volume.

Oh, one other check - the partition type(s) are set to 0x08 or 0x09 (AIX boot and data partition flags). Other things use those 2 values as well, but they won't have the _LVM cookie.

You should check for the overlapping partitions as well. The label itself may be left over if someone repartitions an ex-AIX disk. Simply adding this test is going to give one or two people a nasty "where has my data gone" kind of shock.

Having said that perhaps the IBM people can provide proper information on how to detect/parse the AIX partition data ?

Alan

Maybe, but since that code is in fdisk since ages, and its also in parted since ages and noone complained about the early bail there, it surely cant be a problem.
Also, there is likely the mbr code usually in the first few bytes.

How would that help if you have no filesystem driver?

The on-disk data structures from AIX are not known, also the filesystem layout is not known. There is a msdos partition signature at the end of the first block, and the kernel recognizes 3 small (and overlapping) partitions. But they are not usable. Maybe the firmware uses it to find the bootloader for AIX, but AIX boots also if the first block is cleared.

This is the content of the partition table:

 # dd if=/dev/sdb count=$(( 4 * 16 )) bs=1 skip=$(( 0x1be )) | xxd
0000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000010: 80ff ffff 41ff ffff 1b11 0000 381b 0000  ....A.......8...
0000020: 00ff ffff 41ff ffff 0211 0000 1900 0000  ....A...........
0000030: 80ff ffff 41ff ffff 1b11 0000 381b 0000  ....A.......8...

Handle the whole disk as empty disk.
This fixes also YaST who compares the output from parted (and formerly fdisk) with /proc/partitions. fdisk recognizes the AIX label since a long time, SuSE has a patch for parted to handle the disk label as unknown.

dmesg will look like this:
sda: [AIX] unknown partition table

Tested on an IBM B50 with AIX V4.3.3.

---
 fs/partitions/msdos.c |   31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

Index: linux-2.6.18-rc3/fs/partitions/msdos.c
===================================================================
@@ -58,6 +58,31 @@ msdos_magic_present(unsigned char *p)
 	return (p[0] == MSDOS_LABEL_MAGIC1 && p[1] == MSDOS_LABEL_MAGIC2);
 }
 
+/* Value is EBCDIC 'IBMA' */
+#define AIX_LABEL_MAGIC1	0xC9
+#define AIX_LABEL_MAGIC2	0xC2
+#define AIX_LABEL_MAGIC3	0xD4
+#define AIX_LABEL_MAGIC4	0xC1
+static int aix_magic_present(unsigned char *p, struct block_device *bdev)
+{
+	Sector sect;
+	unsigned char *d;
+	int ret = 0;
+
+	if (p[0] != AIX_LABEL_MAGIC1 &&
+		p[1] != AIX_LABEL_MAGIC2 &&
+		p[2] != AIX_LABEL_MAGIC3 &&
+		p[3] != AIX_LABEL_MAGIC4)
+		return 0;
+	d = read_dev_sector(bdev, 7, &sect);
+	if (d) {
+		if (d[0] == '_' && d[1] == 'L' && d[2] == 'V' && d[3] == 'M')
+			ret = 1;
+		put_dev_sector(sect);
+	};
+	return ret;
+}
+
 /*
  * Create devices for each logical partition in an extended partition.
  * The logical partitions form a linked list, with each entry being

@@ -393,6 +418,12 @@ int msdos_partition(struct parsed_partit
 		return 0;
 	}
 
+	if (aix_magic_present(data, bdev)) {
+		put_dev_sector(sect);
+		printk( " [AIX]");
+		return 0;
+	}
+
 	/*
 	 * Now that the 55aa signature is present, this is probably
 	 * either the boot sector of a FAT filesystem or a DOS-type