Or, to prevent any chance of the BIOS swapping the disk order, you could refer to your device by id instead. I know my friends motherboard does that, it randomly sometimes swaps the disk order for no reason when booting, just some bug in the bios. So, to refer to disks in a way that are guaranteed to always point the the exact physical disk you want, regardless of what order they are, check in the /dev/disk/by-id directory. In here the kernel creates files that point to your disks just like /dev/sda, /dev/sdb, etc, do, except that instead of some arbetrary name like /dev/sda, the name is based upon the interface, the make of the drive, and its serial number. Regards, Sam > I was too hasty, this should have gone to the list... > > On Mon, Aug 24, 2009 at 08:08:57PM +0200, Arno Wagner wrote: > > On Mon, Aug 24, 2009 at 05:55:37PM +0200, Milan Broz wrote: > > > spamzad@xxxxxxxxxxxxxx wrote: > > > > Something must have overwritten the header (posted it at the bottom) > > > > - and I have no clue what. > > > > That's exactly my question now: might it be a bug in cryptsetup or > > > > can i rule that out? > > > > > > Cryptsetup never write empty first sectors except explicit LUKS format. > > > (Of course this can very rarely happen if hw/driver problem appears...) > > > > > > But see crypttab here - you have tmp device created as regular > > > encrypted device > > > with random key - are you sure that kernel _cannot_ swap sda & sdb and > > > your system just formats temp device here? > > > > I had that happen to me. Nasty. The BIOS seemd to modify disk order > > when booting from a different drive via the bootup boot device > > selection. > > > > One simple way to get around this is to create one-drive RAID1 > > devices and then use them. No moving by the kernel on these. > > > > Arno > > > > > > # <target name> <source device> <key file> <options> > > > > home /dev/sdb2 none luks > > > > ctmp /dev/sda2 /dev/urandom > > > > tmp,cipher=aes-cbc-essiv:sha256 > > > > cswap /dev/sda5 /dev/urandom > > > > swap,cipher=aes-cbc-essiv:sha256 > > > > > > Milan > > > -- > > > mbroz@xxxxxxxxxx > > > > > > _______________________________________________ > > > dm-crypt mailing list > > > dm-crypt@xxxxxxxx > > > http://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
