Въпроса е към Linux гурутата, ако някой се припознае...

Опитвам се да скалъпя една сървърна конфигурция базирана на Debian 10.6.0. Имам два физически диска обхванати от MDADM (RAID1), върху който се търкаля LUKS, а отгоре му LVM. Вътре в логическата група имам логически партишъни за swap и root.

/boot е на самостоятелни партишъни под отделен RAID1 (не са криптирани засега). Имам и самостоятелни EFI партишъни на двата диска.

Дотук всичко е добре, системата си бутва, GRUB-а си пали, иска си паролата на LUKS и всичко тръгва нормално. Докато RAID-а не e деградирал, тогава почват проблемите....

За тест вадя втория диск и пробвам да бутна от първия. GRUB-a е ок, тръгва да бутва от деградиралия RAID, но после, когато трябва да запали cryptsetup за да изтъркаля LUKS-a, ме наплюва с това:

cryptsetup:waiting for encrypted source device UUID ...бла-бла.... Там седим известно време и после изпадам в промпта на груба.

След седмица борби с всевъзможни инсталации и последователности, винаги стигам до тук. Четох, четох... накрая се натъкнах на това:

https://bugs.launchpad.net/ubuntu/+sour ... ug/1879980

Прилича на моя проблем, само дето е Ubunto. Въпроса е, че тук материята вече се качва едно ниво над мойто текущо и почвам да се губя в превода. Явно initramfs скриптовете имат някакъв яд, mdadm се забавя, a cryptsetup тръгва преди да е сглобен RAID-a (макар и деградирал), нещата са праволинейни и път назад няма.

Някой борил ли е тоя проблем? Все си мислех, че конфигурацията, която се опитвам да сглобя е сравнително стандартна за доста системи - MDADM->LUKS, а в нета не намирам почти нищо по въпроса. Поне не и на смилаемо ниво, каквото е мойто към момента... с initramfs скриптовете не съм се сблъсквал досега.

Не, че съм гуру, но съм се борил с initram и линукс буут процеса за да го опитмизирам за бързо буутване преди време.
Най вероятно проблемът е същият както този от линка с Убунту. И съответно може да пробваш да ползваш техният фикс. Предплагам, че ще е достатъчно да инсталираш оправените пакети initramfs-tools и crypsetup - нямам идея дали са същите като в Дебиан или ще си повлекат всичките Убунтовски особенности т.е. ако не стане така ще трябва да направиш съответние модификации на ръка и при всеки ъпдейт да внимаваш да не се върнат обратно.
Общо взето initramfs не е кой знае каква сложнотия, компресирана файлова система която се изпълнява веднага след като ядрото се зареди и чак след това се mount-ва и изпълняват скриптовете в (евентуално криптираната) файлова система която е на този RAID1. Тъй като initramfs е относително малка понякога може да се вкара като binary направо в ядрото - но на дебиан мисля, че не е чак толкова оптимизирано. Т.е. намираш я къде е, разархивираш, преглеждаш какви са поправките направени в Убунту, прилагаш ги, архивираш, заместваш стария initramfs с този и пробваш да буутнеш. Така ще решиш проблема за момента, но не е ясно при следващ ъпдейт на ядрото какво ще се случи - много е вероятно да ти омаже корекциите и да се налага пак да ги правиш. Т.е. за стабилен във времето фикс трябват повече усилия.

Мдам, с доста ровене намерих и писано по въпроса за Debian. Ама беше завряно на кучето в .... Или поне на мен ми костваше доста усилия да го намеря:

https://salsa.debian.org/cryptsetup-tea ... equests/18

А и както изглежда от писаното - не си дават особен зор да оправят трайно проблема. Което ми е странно, защото това поне според мен е съвсем реална конфигурация на системата и съвсем реална ситуация, в която може да попадне. Като след това системата забива на boot процеса и трябват вече прилично количество действия/знания за да се оправи. И по-лошо, ако това е отдалечен сървър, положението си ебава майката.

Т.е. за мен това си е мейджър проблем. Поне за пореден път доказах на себе си, че имам талант да настъпвам даже и добре заровените мотики

Хубавото е, че вече се работи и най вероятно скоро ще е оправено в официалните релийзи. Как и защо се е стигнало до тази ситуация е ясно - ти си си патил и тестваш edge cases, нещо което не всички правят и съответно са 'пропуснали' такъв сериозен проблем. Решението ще е нещо дребно, може би местене на един ред от единия край на скрипта в другия и готово.

Мотики има навсякъде, от години повечето време ми минава в чудене кое как да подкарам вместо да пиша код. Ей сега приключвам един проект с Nordic BLE и там е същата простотия, демо проектите са ги закърпили да вървят и в момента в който опиташ нещо различно и познай, ресет на контролера. Започнеш да дебъгваш и влизаш в някакъв blob който отгоре на всичко е включил защита от дебъгване и всички инструкции се дизасемблират като nop т.е. виждаш само съдържанието на регистрите. Три дни по късно интуитивно успях да налучкам, че проверяват дали в паметта е записано 0xDEADC0DE и ако е така бичи грешка т.е. проверка да не се инициализира блутут стека два пъти - предполагам де. Само, че това е останало в паметта от предния ресет и така влизаме в безкраен цикъл докато не изхабим батерията. Оправията беше още в буутлоадера да нулирам паметта и всичко се оправи. Мотики.