setup-storage for raid5 + lvm

[Michael Tautschnig]

> Hi,
> 
> Nicolas Courtel wrote on 2009-04-30 11:11:46 +0200 [Re: setup-storage for raid5 + lvm]:
> > 
> > >># mdadm --zero-superblock /dev/sda2
> > >># /lib/udev/vol_id -u /dev/sda2
> > >>6428a2d1-c30d-4916-ab6b-625117989651
> > >>[...]
> > >
> > >Ok, good to know, thanks for testing this. I wonder whether we should do
> > >something about this in setup-storage, but I believe that doing mdadm
> > >--zero-superblock on each and every non-RAID device is pure overkill.
> >
> > I agree.  You may want to add a few words in the error message, 
> > something like "Failed to obtain UUID [...], check that $device_name is 
> > not or has not been a RAID partition".
> 

Finally done (and included in 3.2.21+experimental6): The code in question now
reads

   99   # every device must have a uuid, otherwise this is an error (unless we
  100   # are testing only)
  101   ($FAI::no_dry_run == 0 || scalar (@uuid) == 1)
  102     or die "Failed to obtain UUID for $device_name.\n
  103       This may happen if the device was part of a RAID array in the past;\n
  104       in this case run mdadm --zero-superblock $device_name and retry\n";

> sorry, I'm not familiar with the code in question, so I don't know if it's
> actually possible, but ideally, detecting this failure would trigger possible
> remedies to the problem (eg. zeroing the RAID superblock - unless this is
> potentially harmful for reasons not obvious to me right now) and then re-try.
> I can imagine that this might not be as simple to implement as it sounds.
> 
> As an alternative, there could be a "pedantic mode" (triggered by some flag)
> which actually does zero each potential superblock (again, unless there is
> some reason this might be undesirable). Then, if you hit trouble with a
> particular installation, you could simply turn on this flag and see if it
> solves your problem without needing to go into any extensive debugging. Having
> something that "just works" even in awkward circumstances without manual
> intervention does not seem like a bad idea, does it? Thinking about the
> complexity of a modern Linux system, though, I tend to agree that something
> like that should be turned off by default ;-).
> 

I do love to do as much automagically as possible, but in that case I'd rather
not go for it: Exit code 4 of vol_id -u may occur in several cases, so better
let the user do it themselves. I hope the error message provides enough
information such that the user knows what do to and the mdadm stuff is probably
as easy as restarting setup-storage in pedantic mode (if there were such a
thing).

Best,
Michael




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
Url : http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20090613/c6645131/attachment.bin