Dear /mjt, I refer to your messages. Thank you very much for explaining and answering to this bug report!
I got the following questions: 1) What would you suggest as correct workaround for this problem? (as you only point out that serverfault solution is wrong. I mean workarounds that are applicable right now (also for DAUs...) 2) Did I understand you correctly? You said that nobody is going to fix this bug because of disliking on another. Can there nothing be done about that? Seems to harm debian project if you ask DAU users like me that switched to Debian because of greater stability, faster fixes for problems... sorry I'm not involved in development and therefore may be wrong.... kind regards, clueless newbie 31.05.2015 18:56, Marc Meledandri wrote: > Is any further info needed here? > > I've run into this bug with _both_ GPT and MBR partition tables. It is independent of the type of underlying devices. The problem is that with incremental array assembly, when not all devices are present, we need some timer, and have to run the array with whatever number of devices available as we currently have. This is something I overlooked when switching from one-time array assembly to incremental mode. Incremental mode is needed when the underlying devices are slow, there were multiple bugreports about debian mdadm which can't assemble raid arrays on devices such as mpt or usb. Current initramfs-tools infrastructure does not have necessary infrastructure for such a timeout. But more important, personally I can't work with any package which touches debian-installer, because apparently some of the more important d-i team members dislikes me. So I can't really fix anything in mdadm anymore, as it produces d-i component. Thanks, /mjt 31.05.2015 23:05, Info Geek wrote: > I'm not into scripting voodo but if this is of any help this is a reply I got when I asked about it, before the bug report: > > > http://serverfault.com/questions/688207/how-to-auto-start-degraded-software-raid1-under-debian-8-0-0-on-boot This is a wrong solution. I mentioned the right solution in my previous reply. The solution offered on serverfault moves us back to one-time raid array assembly which does not work for slow devices. /mjt
