linux-kernel - Re: Linux mdadm superblock question.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 16 Feb 2010 12:05:05 -0500
From:	Bill Davidsen <davidsen@....com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Neil Brown <neilb@...e.de>, Michael Evans <mjevans1983@...il.com>,
	Justin Piszcz <jpiszcz@...idpixels.com>,
	linux-raid@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Linux mdadm superblock question.

H. Peter Anvin wrote:
> On 02/15/2010 04:27 PM, Neil Brown wrote:
>   
>> When mdadm defaults to 1.0 for a RAID1 it prints a warning to the effect that
>> the array might not be suitable to store '/boot', and requests confirmation.
>>
>> So I assume that the people who are having this problem either do not read,
>> or are using some partitioning tool that runs mdadm under the hood using
>> "--run" to avoid the need for confirmation.  It would be nice to confirm if
>> that was the case, and find out what tool is being used.
>>     
>
> My guess is that they are using the latter.  However, some of it is
> probably also a matter of not planning ahead, or not understanding the
> error message.  I'll forward one email privately (don't want to forward
> a private email to a list.)
>
>   
>> If an array is not being used for /boot (or /) then I still think that 1.1 is
>> the better choice as it removes the possibility for confusion over partition
>> tables.
>>
>> I guess I could try defaulting to 1.2 in a partition, and 1.1 on a
>> whole-device.  That might be a suitable compromise.
>>     
>
> In some ways, 1.1 is even more toxic on a whole-device, since that means
> that it is physically impossible to boot off of it -- the hardware will
> only ever read the first sector (MBR).
>
>   
That is either a problem or a solution, depending which bad behavior you 
are trying hardest to avoid.
>> How do people cope with XFS??
>>     
>
> There are three options:
>
> a) either don't boot from it (separate /boot);
>   
And certainly there are other reasons to do that...
> b) use a bootloader which installs in the MBR and
> hopefully-unpartitioned disk areas (e.g. Grub);
> c) use a nonstandard custom MBR.
>
> Neither (b) or (c), of course, allow for chainloading from another OS
> install and thus are bad for interoperability.
>   

I'm not really sure what you're getting at here, I use grub in MBR and 
then add chain loader stanzas to grub.conf for many things, usually an 
alternate Linux release, or to have 32/64 of the same release handy for 
testing, and always memtest from the boot menu. Even Win98SP2 on one 
machine, since that works very poorly under KVM. (ask Avi if you care 
why, something about what it does in real mode). In any case, I don't 
see the chain loader issue, unless you mean to reboot out of some other 
OS into Linux.

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/