Помогите с dmcrypt.
Было ядро 2.6.32-r6, и, насколько я помню, опция LBDAF в ядре была отключена. Был зашифрованный с помощью dmcrypt раздел размером 90 гигабайт и все работало, но угораздило меня обновить систему в том числе udev и ядро. Новое ядро 2.6.33 без опции LBDAF не захотело монтировать раздел с dmcrypt, ладно подключаю эту опцию (хотя в ней нет необходимости, так как раздел всего 90 гигабайт, а это меньше 2 терабайт) и все равно не хочет, говорит вот что
EXT3-fs error (device dm-1): ext3_check_descriptors: Block bitmap for group 0 not in group (block 1342387852)!
EXT3-fs (dm-1): error: group descriptors corrupted.
Пароль я точно помню верно, так как при вводе неверного пароля получаем вот что:
EXT3-fs (dm-1): error: can't find ext3 filesystem on dev dm-1.
Ну ладно решил загрузить старое ядро и оно начало насколько я помню говорить что без LBDAF не может загрузиться. Ладно пересобрал старое ядро с LBDAF та же ошибка, пришел к выводу что видимо обновился пакет udev и ещё какой-то, откатил udev на версию 150-r1 с 151. Все равно не помогло.
Решил использовать testdisk тот нашел раздел с linux но сказал что что он очень большой 17 терабайт при подстановке найденного им блока для суперблока fsck ничего не нашла.
Из всего этого можно заключить, что при обновлениии, какие то программы начали видеть, то ли геометрию диска как то иначе (что он 17 тераббайт хотя он всего 90гигабайт), то ли ещё что-то сломалось. Полететь физически ничего не могло, smart сообщает что все в порядке, никаких ребутов не было (все на ноуте). Помогите, куда копать, чтоб исправить геометрию или что-то ещё.
- Для комментирования войдите или зарегистрируйтесь
Мужики внимание. Бага
Мужики внимание. Бага найдена. После того как отписался на форуме подумал вот над чем, почему даже старое ядро не хотело работать без LDBAF, да потому что изменилась геометрия диска и вуаля откатился на стабильный udev-149, и на всякий случай стабильный cryptsetup 1.0.6 и вуаля все заработало. Новый udev почему то меняет геометрию диска!
dm-crypt и прозрачное сжатие
Раз уж зашел разговор про dm-crypt, хочу поинтересоваться у общественности, может у кого получилось с помощью этого тулкита организовать не прозрачное шифрование (например вот так:
losetup /dev/loop0 $cryptofile
cryptsetup -c aes -h sha512 -s 256 -y create sec /dev/loop0
а сабж, что то вроде:
losetup /dev/loop0 $cryptofile
cryptsetup -c lzo create sec /dev/loop0
или вместе сжатие и шифрование, в ядре, там где алгоритмы шифрования lzo присутствует, но применить его у меня не получилось, и нагуглить ничего не вышло, может кто подскажет чего или посылочкой поделится?
недавно на opennet.ru статья
недавно на opennet.ru статья была про шифрованные разделы, ключах на флэшке и монтирование/размонтирование с конкретной флэшкой с конкретным ключем.
P.S.: Linux - это красная таблетка :-) Windows - синяя...
на опеннете
Если вы про это:
http://www.opennet.ru/base/sec/truecrypt_intro.txt.html
то трукрипт программа не плохая, но все это может и dmcrypt и он есть в ядре. А под виндой пользовать не планируется (имхо нет смысла :)
Хочется завести именно прозрачное сжатие в dmcrypt, остальное и так работает.
Есть вариант создать в шифрованном файле фс со сжатием, но btrfs еще бета, reiser4 не в ядре и непонятно когда будет и будет ли а, возиться с патчами все время не хочется, еще есть squashfs, но на нее нельзя писать - хороший вариант для статичных данных, а пересоздавать ее при необходимости изменения/добавления - не вариант.
Еще есть:
http://www.opennet.ru/base/sec/ubuntu_disk_crypt.txt.html
познавательно, но ничего по теме
/
Браво-бис!
Так, чтобы наверняка, чтобы после (в случае) смерти флешки п..ц (в смысле: приехали).
Для обеспечения надёжности необходим:
а) сейф:
б) дубликат.
:wq
--
Live free or die
то же на английском
Вот http://www.mail-archive.com/gentoo-user@lists.gentoo.org/msg34428.html
нагуглил интересные мысли на тему прозрачного сжатия. В моем вольном переводе:
Первый хотел бы получить что то вроде плугина к райзер4 только на уровне VFS в ядре чтобы получить прозрачное сжатие, на любой фс.
второй, не думает что такое возможно так как ФС в таком случае не будет знать сколько останется (и останется ли) свободных блоков после помещения файла в ФС. Допустим есть ФС размером 10G вы хотите поместить туда достаточно "рыхлый " файл размером 20G, полагая что он сожмется по дороге и влезет. но ФС не способная предсказать рейтио сжатия файла обломает вас с этим предприятием. По этому второй собеседник считает, что сжатие должно происходить на уровне ФС.
В общем понятно, но не понятно только нафига ФС вообще тратить время на подсчет пустых блоков?! По моему в данном случае гораздо логичнее было бы писать пока не кончатся все свободные блоки и только после исчерпания свободного места давать отлуп? В таком случае dm-crypt вполне себе справлялся бы со сжатием на лету.
В cryptsetup версии 1.1.0
В cryptsetup версии 1.1.0 поменяли значение цифера по умолчанию.
Подставил старый через -c aes-cbc-plain. Помогло.