Bug#398310: don't assemble all arrays on install
severity 398310 important retitle 398310 let user choose when to start which array tags 398310 confirmed help thanks also sprach dean gaudet [EMAIL PROTECTED] [2006.11.13.0230 +0100]: i had 4 disks which i had experimented with sw raid10 on a few months back... i never zeroed the superblocks. i ended up putting them into production in a 3ware hw raid10. today the 3ware freaked out... and i put the disks into another box to attempt forensics and to try constructing *read-only* software arrays to see if i could recover the data. when i did apt-get install mdadm it found the old superblocks from my experiments a few months ago... and tried to start the array! You can set AUTOSTART=false in /etc/default/mdadm or via debconf, and no arrays will be started. it's *bad* to autostart all discovered arrays. it's unfortunate enough that you've decided to make initrds start all arrays by default... but at least this install-time autodiscover and start everything should be optional. at a minimum i think there should be a dialog attempt to autodiscover all arrays and start them?. even better would be a second step i found the following arrays, which ones should i start? If you aren't happy with the current solution, please provide patches for consideration. I do like the idea of selecting which arrays to start when. Ideally, for each array, you'd select whether to start it from initramfs, from init.d at boot, from init.d at install time, or from init.d run manually. You can distinguish between the latter three using the runlevel and a custom variable passed from postinst. In any case, I don't consider the bug you filed to be grave because you forgot to zero the superblocks. However, I agree with you that it would be nice to have more granular control. This won't happen in time for etch though, nor do I know when I'll have time to implement this. Thus, please help out if you want to see this feature. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems signature.asc Description: Digital signature (GPG/PGP)
Bug#398310: Re: Bug#398310: don't assemble all arrays on install
also sprach dean gaudet [EMAIL PROTECTED] [2006.11.13.1116 +0100]: right, now i know that i should create an /etc/default/mdadm *before* i install mdadm... because unlike other packages, mdadm does potentially dangerous things just by installing it. i'll keep that in mind :) You could also just reconfigure your debconf to show questions of low priority; since you're juggling disks, it seems like that's the more appropriate level. I have raised the question for INITRDSTART to high priority. i think the only solution is to go entirely event based... start meshing into udev or something. you'd have to be able to express the dependencies of a device/filesystem somehow though. ugh. we have plans into this direction. actually, after playing with the disks with md, and then moving them into 3ware hardware raid, i did zero the disks... through the 3ware hw raid. the problem is that the 3ware hw raid superblock is even larger than the md raid superblock (100MB vs. a few MB in my limited experiments)... so even though i zeroed the hw raid device it went nowhere near the stale md superblock (even the 3ware hw raid superblock never touched it). they are likely at opposite ends of the disk. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems signature.asc Description: Digital signature (GPG/PGP)
Bug#398310: Re: Bug#398310: don't assemble all arrays on install
On Mon, 13 Nov 2006, martin f krafft wrote: also sprach dean gaudet [EMAIL PROTECTED] [2006.11.13.1116 +0100]: right, now i know that i should create an /etc/default/mdadm *before* i install mdadm... because unlike other packages, mdadm does potentially dangerous things just by installing it. i'll keep that in mind :) You could also just reconfigure your debconf to show questions of low priority; since you're juggling disks, it seems like that's the more appropriate level. I have raised the question for INITRDSTART to high priority. thanks! i think the only solution is to go entirely event based... start meshing into udev or something. you'd have to be able to express the dependencies of a device/filesystem somehow though. ugh. we have plans into this direction. yeah... i've been meaning to ramp up on them. actually, after playing with the disks with md, and then moving them into 3ware hardware raid, i did zero the disks... through the 3ware hw raid. the problem is that the 3ware hw raid superblock is even larger than the md raid superblock (100MB vs. a few MB in my limited experiments)... so even though i zeroed the hw raid device it went nowhere near the stale md superblock (even the 3ware hw raid superblock never touched it). they are likely at opposite ends of the disk. the 3ware superblock is at the end of the disk similar to mdadm... i actually successfully pulled the disks from a 3ware raid10 and constructed a md raid0 with two of the disks with mdadm --build (and recovered the data which the 3ware had decided to lose)... and i didn't have to do anything complex other than figure out which two disks to use. i've done a similar experiment with a 3ware raid1 disk... i could mount it just found on a non-3ware device. -dean -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398310: don't assemble all arrays on install
On Mon, 13 Nov 2006, martin f krafft wrote: severity 398310 important retitle 398310 let user choose when to start which array tags 398310 confirmed help thanks also sprach dean gaudet [EMAIL PROTECTED] [2006.11.13.0230 +0100]: i had 4 disks which i had experimented with sw raid10 on a few months back... i never zeroed the superblocks. i ended up putting them into production in a 3ware hw raid10. today the 3ware freaked out... and i put the disks into another box to attempt forensics and to try constructing *read-only* software arrays to see if i could recover the data. when i did apt-get install mdadm it found the old superblocks from my experiments a few months ago... and tried to start the array! You can set AUTOSTART=false in /etc/default/mdadm or via debconf, and no arrays will be started. right, now i know that i should create an /etc/default/mdadm *before* i install mdadm... because unlike other packages, mdadm does potentially dangerous things just by installing it. i'll keep that in mind :) I do like the idea of selecting which arrays to start when. Ideally, for each array, you'd select whether to start it from initramfs, from init.d at boot, from init.d at install time, or from init.d run manually. You can distinguish between the latter three using the runlevel and a custom variable passed from postinst. it gets worse when you start considering external bitmaps... i posted to linux-raid about the dependency problems here. you can't autostart an array with external bitmap until the bitmap is available... and if the bitmap is on a filesystem which is on another md device (think many disk raid5 external bitmap on raid1 root disks) then you need some md devices to start, some filesystems to be mounted, and then some more md devices to start and more filesystems to be mounted. i think the only solution is to go entirely event based... start meshing into udev or something. you'd have to be able to express the dependencies of a device/filesystem somehow though. ugh. In any case, I don't consider the bug you filed to be grave because you forgot to zero the superblocks. actually, after playing with the disks with md, and then moving them into 3ware hardware raid, i did zero the disks... through the 3ware hw raid. the problem is that the 3ware hw raid superblock is even larger than the md raid superblock (100MB vs. a few MB in my limited experiments)... so even though i zeroed the hw raid device it went nowhere near the stale md superblock (even the 3ware hw raid superblock never touched it). it took me a while to figure out that this was what happenned -- at first i thought mdadm had somehow read 3ware superblocks... there had been talk of an industry standard but i was skeptical it ever went anywhere. -dean -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398310: don't assemble all arrays on install
Package: mdadm Version: 2.5.5-1 Severity: grave it's dangerous to generate an mdadm.conf and start running arrays automatically at install time! i nearly got bit by this. i marked this grave because there's a potential for data loss with the current install scripts. i had 4 disks which i had experimented with sw raid10 on a few months back... i never zeroed the superblocks. i ended up putting them into production in a 3ware hw raid10. today the 3ware freaked out... and i put the disks into another box to attempt forensics and to try constructing *read-only* software arrays to see if i could recover the data. when i did apt-get install mdadm it found the old superblocks from my experiments a few months ago... and tried to start the array! fortunately i had issued blockdev --setro /dev/sd[defg] prior to doing any of this, so the block layer saved my ass. otherwise mdadm would have happily screwed around with the data at the end of the disks... and *even worse* might have decided recovery was necessary and really screwed things up! it's *bad* to autostart all discovered arrays. it's unfortunate enough that you've decided to make initrds start all arrays by default... but at least this install-time autodiscover and start everything should be optional. at a minimum i think there should be a dialog attempt to autodiscover all arrays and start them?. even better would be a second step i found the following arrays, which ones should i start? -dean p.s. regardless of this complaint, i'm totally happy with the newer initramfs which handles renames more gracefully... and with the monthly checkarray default. thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
