All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: John Robinson <john.robinson@anonymous.org.uk>
Cc: Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: unknown partition table starting with 2.6.28
Date: Thu, 04 Feb 2010 19:33:37 -0500	[thread overview]
Message-ID: <4B6B6761.1020108@tmr.com> (raw)
In-Reply-To: <4B6B6579.40900@tmr.com>

Bill Davidsen wrote:
> John Robinson wrote:
>> On 01/02/2010 20:46, Bill Davidsen wrote:
>>> John Robinson wrote:
>>>> On 15/01/2010 23:58, Timothy D. Lenz wrote:
>>>>> I am trying to update my kernel from 2.6.26.8 to the current .32. 
>>>> [...]
>>>>> Starting with .28 I am getting an error about unknown partition 
>>>>> table for all 3 md's. md0 is boot and main programs, md1 is swap, 
>>>>> md2 is mostly recordings storage for vdr. All 3 are raid 1 and 
>>>>> raid is built in.
>>>>
>>>> Your md devices aren't partitioned so you can quite safely ignore 
>>>> the warning. See also 
>>>> http://marc.info/?l=linux-raid&m=125797242110594&w=2
>>>
>>> To clarify that a bit, the kernel can use several partition formats, 
>>> and something in the partitions looks like a partition table but not 
>>> a *valid* partition table. So the kernel warns that it doesn't 
>>> recognize the table.
>>>
>>> I suspect that using a different superblock type would change 
>>> (probably eliminate) this, putting the md information at the start 
>>> of the partition, of in a bit or whatever makes the kernel happy. 
>>> The kernel would make us happy if it checked for a valid md 
>>> superblock at the *end* of the partition, but there may be reasons 
>>> why that's undesirable.
>>>
>>> Finally, I'm less willing than John to say you can ignore it, any 
>>> time something comes close enough to working (in an undesired way) 
>>> to generate an error message, if there's a simple way to be sure the 
>>> kernel doesn't try to use random data as a partition table, you 
>>> might well want to take a step to prevent a problem now.
>>>
>>> I believe it arises out of all arrays being partitionable recently, 
>>> again the details don't come to mid, I've been pretty head down on 
>>> another project since November.
>>
>> I don't think this analysis is correct. Yes, the situation has arisen 
>> out of all arrays - in fact all block devices - being partitionable, 
>> but the warning's not because of something that looks like a dodgy 
>> partition table, it is precisely what it says, a statement that the 
>> device does not contain a valid partition table. I am essentially 
>> repeating the contents of Doug Ledford's earlier post to this list, 
>> to which I referred above.
>
> But the question is, *should* it contain a valid partition table, or 
> even anything which looks enough like a partition table to have the 
> kernel look at it hard enough to think it's invalid? I have several 
> devices on one system which contain essentially random data, and I 
> don't see this, so I assume that my data never looks enough like a 
> partition table to trigger this. At least to 2.6.33-rc6, which I did 
> boot.
>
On reflection I may not have said this clearly. I have block devices 
which do not have partition tables and which do not trigger this 
message. Therefore something is triggering this message, beyond the lack 
of a partition table. My thought is that it may be some logic called 
when the array is assembled, and some data on the array.

-- 
Bill Davidsen <davidsen@tmr.com>
  "We can't solve today's problems by using the same thinking we
   used in creating them." - Einstein


      reply	other threads:[~2010-02-05  0:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-15 23:58 unknown partition table starting with 2.6.28 Timothy D. Lenz
2010-01-16 12:43 ` John Robinson
2010-02-01 20:46   ` Bill Davidsen
2010-02-02 10:31     ` John Robinson
2010-02-05  0:25       ` Bill Davidsen
2010-02-05  0:33         ` Bill Davidsen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B6B6761.1020108@tmr.com \
    --to=davidsen@tmr.com \
    --cc=john.robinson@anonymous.org.uk \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.