Been working out how I'd like to configure our replacement server's disks.

Given the pain of the last server I'd like to use LVM, and not use the fakeraid controllers built into the servers.

Test server had flat BIOS battery, which means it forgot it was configured to use RAID. The BIOS of the DELL SC1425 writes metadata to disks when configured as RAID, which it doesn't then read when it boots in other modes to check if it should be in RAID mode - hmm - maybe I'm missing something here but it looks like a BIOS battery going flat puts your data at unnecessary risk to me.

Whilst the "dmraid" tools can be used to manipulate some of this metadata, typically the system won't let you erase it once booted. Can anyone explain why to me? Eventually I enabled RAID in the BIOS and deleted the RAID array it then found. Then I reinstalled.

The box also had a prior LVM config. The Debian installer is good at finding and reading any old LVM config on a box, and then not wiping/reseting this information. This got me an "Incorrect metadata area header checksum", which I eventually reverted to the slow but effective "dd if=/dev/zero of=/dev/sdX" to make sure any state information on the disks was truly dead.

Trying to set up LVM on software RAID requires a separate /boot for the installers health at least (I'm not fighting it any harder). Once you configure RAID the installer says it needs (and does need) a reboot so that the installer can take this on board and then configure LVM. There are some related bug reports already, but this seems to be as designed.

Aside from the above it "just worked" ;) This isn't the first time that the Debian installer has tripped me by preserving existing state on disk drives, I'm thinking I should write zero's over all disks before use, tedious as it is.