On Sat, Mar 03, 2012 at 01:17:27AM +0000, Robin H. Johnson wrote:
> (Please stop replying to me directly, I keep setting Reply-To on
> purpose. Reply to the list only).
(Sorry, my mutt isn't set to show the Reply-To header by default, so I used
reply all to be sure of resonding to the list at all.)
> On Fri, Mar 02, 2012 at 05:13:16PM -0500, Whit Blauvelt wrote:
> > > This is nornal behavior because kernel tries to recognize partition
> > > table type.
> > Normal perhaps, but not optimal. In my case the kernel:
> >
> > 1. knows there's an msdos partition table
> The probe order is explicitly (acorn, EFI, SGI, LDM, MSDOS, pile of
> others). Except in special cases (that require you to pass the argument
> of 'gpt' to the kernel), all EFI systems will always have a classical
> MSDOS table as well.
I take that as, "Yes, it knows the msdos table is there before probing for
GPT.
> > 2. knows there's no primary GPT
> 1. What kernel version and patchset are you using?
2.6.34.6 vanilla, with most config options inherited from an Ubuntu kernel.
> 2. What partition types are compiled into your kernel?
> They will match the regex /CONFIG_.*(PARTITION|DISKLABEL)/
CONFIG_PM_STD_PARTITION=""
CONFIG_MTD_PARTITIONS=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_ACORN_PARTITION=y
# CONFIG_ACORN_PARTITION_CUMANA is not set
# CONFIG_ACORN_PARTITION_EESOX is not set
CONFIG_ACORN_PARTITION_ICS=y
# CONFIG_ACORN_PARTITION_ADFS is not set
# CONFIG_ACORN_PARTITION_POWERTEC is not set
CONFIG_ACORN_PARTITION_RISCIX=y
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
CONFIG_ATARI_PARTITION=y
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_LDM_PARTITION=y
CONFIG_SGI_PARTITION=y
CONFIG_ULTRIX_PARTITION=y
CONFIG_SUN_PARTITION=y
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y
CONFIG_SYSV68_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_UNIXWARE_DISKLABEL=y
> I'm trying to trace in the block/partitions/ code in 3.3-rc3, and I
> don't see why it should be triggering on your disk.
> While you do have a partition entry with type 0xEF, the protective mbr
> detection looks for 0xEE, not your 0xEF. The 'EFI' output in your
> original disk data is what lead me to think about GPT in the first
> place.
Much appreciate your time and attention.
> But you can see here, that it's not used.
> #define EFI_PMBR_OSTYPE_EFI 0xEF
> #define EFI_PMBR_OSTYPE_EFI_GPT 0xEE
> http://lxr.free-electrons.com/source/fs/partitions/efi.c#L617
> http://lxr.free-electrons.com/source/fs/partitions/efi.c#L543
> http://lxr.free-electrons.com/source/fs/partitions/efi.c#L152
>
> Did your kernel get passed the 'gpt' argument maybe?
No.
> If not none of the above is true, something else is trying to read that
> part of the disk. There are other reasons this could be the case, so
> we'd need to trace it down more.
Is it right to say that with CONFIG_PARTITION_ADVANCED compiled in the
kernel, that the EFI/GPT partition will be scanned for, and so the system
will be vulnerable to flaws on those disk sectors even if the file system in
question contains no EFI/GPT partition at all? There was a day when I didn't
compile anything into a kernel I didn't specifically know the use of, but as
the options have become more complex I've gone lax about that.
>From Googling on the error messages logged, it looks like I'm not the only
one falling prey to this obscure hazard - or one that looks a lot like it.
Part of the obscurity may be that putting support for something in the
kernel does not normally make one think about being open to a new failure
mode, even on systems which don't use the supported feature. Whatever the
cause of the attempt to read from that high sector, after delaying boot for
several minutes it would keep trying for well over an hour, slowing down the
system all the while. So if it's a boot-related function to read the GPT,
well, the system's already booted at that point, but still it keeps
straining to read that sector. The persistence seems misplaced.
Whit
|