bug-parted
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GPT problem, EFI and file system block seem to move after reboot


From: Carsten Aulbert
Subject: GPT problem, EFI and file system block seem to move after reboot
Date: Sun, 30 Dec 2007 15:32:12 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8pre) Gecko/20071022 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666

Hi,

sorry for the vague subject line. I experience a very weird behavior
here and I am not even sure this is a parted problem or a Linux problem.
Please help me to understand this problem (sorry for the length):

I have a box running kernel 2.6.23 (self compiled, config available upon
request). The box has 16 Hitachi 750 GB drives connected to an Areca
1261ML controller. Right now I have created a system disk (stand-alone)
and a RAID6 raid set with two volumes on it: 1 TB and around 4 TB
(/dev/sdc).

Since this exceeds 2 TB, I prepare this device as follows (tested with
parted 1.7.1 and 1.8.8)

# parted /dev/sdc
(parted) mklabel gpt
(parted) mkpart Data xfs 0 -1
(parted) print

Disk /dev/sdc: 4251GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      17,4kB  4251GB  4251GB  xfs          Data

(parted) quit

Then I create a xfs file system:

# mkfs.xfs -f /dev/sdc1
meta-data=/dev/sdc1              isize=256    agcount=32,
agsize=32433253 blks
         =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=1037864096, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096
log      =internal log           bsize=4096   blocks=32768, version=1
         =                       sectsz=512   sunit=0 blks
realtime =none                   extsz=65536  blocks=0, rtextents=0

For checks I prepare two hexdumps:

# hexdump -C -n 131072 -v /dev/sdc > hexdump.gen.sdc
# hexdump -C -n 131072 -v /dev/sdc1 > hexdump.gen.sdc1

Checking if this looks alright:
# grep EFI hexdump.gen.sdc*
hexdump.gen.sdc:00000200  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00
00  |EFI PART....\...|
# grep XFSB hexdump.gen.sdc*
hexdump.gen.sdc:00004400  58 46 53 42 00 00 10 00  00 00 00 00 3d dc 8c
a0  |XFSB........=...|
hexdump.gen.sdc1:00000000  58 46 53 42 00 00 10 00  00 00 00 00 3d dc 8c
a0  |XFSB........=...|

Looks fine by me, mounting also works nicely:
# mount /dev/sdc1 /data
# df -m /data
Filesystem           1M-blocks      Used Available Use% Mounted on
/dev/sdc1              4054029         6   4054024   1% /data

Now I reboot the box.

*WAIT*

starting parted again to check if everything is still there:
# parted /dev/sdc print

Disk /dev/sdc: 4251GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      17,4kB  4251GB  4251GB  xfs          Data

Looks fine. But now I want to mount the partition again:

# mount /dev/sdc1 /data
mount: you must specify the filesystem type

Opps. OK, I know it's xfs:
#  mount -t xfs /dev/sdc1 /data
mount: wrong fs type, bad option, bad superblock on /dev/sdc1,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

You might have guessed it already. Now creating the same hexdumps as
before, now I get this:
# hexdump -C -n 131072 -v /dev/sdc > hexdump.reboot.sdc
# hexdump -C -n 131072 -v /dev/sdc1 > hexdump.reboot.sdc1

# grep EFI hexdump.reboot.*
hexdump.reboot.sdc:00000200  45 46 49 20 50 41 52 54  00 00 01 00 5c 00
00 00  |EFI PART....\...|
hexdump.reboot.sdc1:00000000  45 46 49 20 50 41 52 54  00 00 01 00 5c 00
00 00  |EFI PART....\...|

Opps, Why is the EFI part showing up in /dev/sdc1 now?

# grep XFSB hexdump.reboot.*
grep XFSB hexdump.reboot.*
hexdump.reboot.sdc:00004400  58 46 53 42 00 00 10 00  00 00 00 00 3d dc
8c a0  |XFSB........=...|
hexdump.reboot.sdc1:00004200  58 46 53 42 00 00 10 00  00 00 00 00 3d dc
8c a0  |XFSB........=...|


Just to enhance the readability slightly, I'll rerun the greps on all
hexdumps:

# grep EFI hexdump.*
hexdump.gen.sdc:00000200  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00
00  |EFI PART....\...|
hexdump.reboot.sdc:00000200  45 46 49 20 50 41 52 54  00 00 01 00 5c 00
00 00  |EFI PART....\...|
hexdump.reboot.sdc1:00000000  45 46 49 20 50 41 52 54  00 00 01 00 5c 00
00 00  |EFI PART....\...|

# grep XFSB hexdump.*
hexdump.gen.sdc:00004400  58 46 53 42 00 00 10 00  00 00 00 00 3d dc 8c
a0  |XFSB........=...|
hexdump.gen.sdc1:00000000  58 46 53 42 00 00 10 00  00 00 00 00 3d dc 8c
a0  |XFSB........=...|
hexdump.reboot.sdc:00004400  58 46 53 42 00 00 10 00  00 00 00 00 3d dc
8c a0  |XFSB........=...|
hexdump.reboot.sdc1:00004200  58 46 53 42 00 00 10 00  00 00 00 00 3d dc
8c a0  |XFSB........=...|

My conclusion here is: "Something" moves the boundary if /dev/sdc1
around, but I don't know what it is. /dev/sdc seems to be very constant.
Anyone?

Thanks for reading this far.

Carsten




reply via email to

[Prev in Thread] Current Thread [Next in Thread]