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
Signed-off-by: Olaf Hering <[email protected]>
---
fs/partitions/msdos.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
Index: linux-2.6.16/fs/partitions/msdos.c
===================================================================
--- linux-2.6.16.orig/fs/partitions/msdos.c
+++ 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,
On Wed, May 17, 2006 at 10:13:14AM +0200, Olaf Hering wrote:
> +/* Value is EBCIDIC 'IBMA' */
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
On Wed, 17 May 2006 10:13:14 +0200, Olaf Hering said:
>
> 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.
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...
On Wed, May 17, [email protected] wrote:
> 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 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.
On Wed, 17 May 2006 11:10:56 +0200, Olaf Hering said:
> On Wed, May 17, [email protected] wrote:
> > 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 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.
On Mer, 2006-05-17 at 10:13 +0200, Olaf Hering wrote:
> dmesg will look like this:
> sda: [AIX] unknown partition table
>
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
On Wed, May 17, Alan Cox wrote:
> On Mer, 2006-05-17 at 10:13 +0200, Olaf Hering wrote:
> > dmesg will look like this:
> > sda: [AIX] unknown partition table
> >
>
> 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.
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.
> Having said that perhaps the IBM people can provide proper information
> on how to detect/parse the AIX partition data ?
How would that help if you have no filesystem driver?
On Wed, May 17, [email protected] wrote:
> 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?
A big company who is all hot about Linux expressed no interrest so far
to make AIX volumes readable in Linux.
On Mer, 2006-05-17 at 20:37 +0200, Olaf Hering wrote:
> 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
On Wed, May 17, Alan Cox wrote:
> On Mer, 2006-05-17 at 20:37 +0200, Olaf Hering wrote:
> > 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
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.
On Wed, 17 May 2006 21:03:26 +0200, Olaf Hering said:
> On Wed, May 17, Alan Cox wrote:
> > All we want to know initially is how to correctly spot AIX volumes. As I
> I dont have any more info about the layout.
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.
On Wed, 17 May 2006 15:44:13 EDT, [email protected] said:
> 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.