5152 2004-09-03 09:51:09 +0400 [FR][4.1] проверить консистентную работу с "левыми" дисклейблами 2011-07-19 23:42:41 +0400 1 1 4 Development Sisyphus alterator-vm unstable all Linux CLOSED NOTABUG http://www.google.ru/groups?hl=ru&lr=&ie=UTF-8&threadm=876073561%40p101.f57.n5030.z2.ftn&rnum=1&prev=/groups%3Fselm%3D876073561%2540p101.f57.n5030.z2.ftn P2 enhancement --- 3459 1 mike mcpain inger mcpain mouse rider voins vsu qa-sisyphus oldest_to_newest 18566 0 mike 2004-09-03 09:51:09 +0400 В Url указана вторая часть дискуссии ("сказка" -- в первой) по части неконсистентности восприятия BSD disklabel и разъезда разделов в случае разной нумерации разделов (с/без учета содержимого оного) в инсталяторе и рабочей системе. Дискуссия относится к 1997 году, однако может иметь смысл включить в план проверок для нового инсталятора взаимодействие с другими ОС и их разделами. 18621 1 mike 2004-09-06 16:53:10 +0400 кстати, http://groups.google.com/groups?ie=UTF-8&as_umsgid=chfve8%24931%241@ddt.demos.su&lr=&hl=ru 18623 2 mike 2004-09-06 17:14:13 +0400 ergo: видимо, стоит оторвать поддержку bsd disklabels в ядрах std-*: народ сообщает, что ufs современных бздей все равно ufs.o не поддерживается, а сдвиги разделов вроде описанного в Url баги могут быть опасны непоправимой потерей данных у несчастных с freebsd. починить (оторвать) не особо трудно, а вот если кого догонит -- проблема может быть существенной. 18627 3 mike 2004-09-07 00:27:35 +0400 -- from Valentin Nechaev Допиши, что для 2.6 в таком виде уже неактуально, потому что bsd partitions ставятся после логических разделов. Вот со стендовой машины: hda: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(33) hda: hda1 hda2 hda3 < hda5 hda6 hda7 hda8 hda9 > hda1: <bsd: > hda2: <bsd: hda10 hda11 hda12 hda13 hda14 hda15 hda16 > Это при /dev/hda1 * 1 64 514048+ a5 FreeBSD /dev/hda2 65 2674 20964825 a5 FreeBSD /dev/hda3 2675 4865 17599207+ 5 Extended /dev/hda5 2675 2707 265041 83 Linux /dev/hda6 2708 3099 3148708+ 83 Linux /dev/hda7 3100 3226 1020096 83 Linux /dev/hda8 3227 3353 1020096 82 Linux swap /dev/hda9 3354 4865 12145108+ a5 FreeBSD # uname -a Linux saiga.carrier.kiev.ua 2.6.5-1.358 #1 Sat May 8 09:04:50 EDT 2004 i686 i686 i386 GNU/Linux 18682 4 mike 2004-09-08 14:34:15 +0400 --- Victor Wagner Не надо ни с чем морочиться. Нужно честно спросить юзера. Если у юзера есть на диске какой-то странный раздел, то он, наверное, достаточно квалифицирован чтобы снять галочку с чекбокса. Поэтому решение в случае если на диске обнаружено более одного своп-раздела - вывести окошко с вопросом "а вот куда свопиться" с помеченными по умолчанию обоими разделами, устроило бы пожалуй всех. Молчаливый (или с руганью) пропуск раздела с некорректной сигнатурой и продолжение работы тоже бы устроил. Меня лично раздражало то, что не имея возможности свопиться в первый же найденный раздел с сигнатурой 82, инсталлятор отказывался работать дальша СОВСЕМ. Хотя вообще-то на современных машинах можно и совсем без свопа если не жить, то хотя бы поставиться. Та машина, с которой эти грабли происходили, была сильно несовременной (1999 года) но памяти в ней было 256 мегов. Так что хватило бы. Убивает "дружественность" интерфейса инсталлятора. Который не позволяет пользователю вмешаться, а делает всё за него (и в expert mode - тоже) --- <chi1a6$aga$3@wagner.wagner.home> PS: насколько помню, исторически этим знакомство Витуса с альтом и ограничилось, или около того. 18684 5 mike 2004-09-08 14:44:49 +0400 оттуда же (vsu, это по твоей части): http://groups.google.com/groups?ie=UTF-8&as_umsgid=chl00t%249mp%241@ddt.demos.su&lr=&hl=ru (у нас в 2.4/2.6 CONFIG_BSD_DISKLABEL тоже "y") +подписываю на багу тружеников нового инсталера 18879 6 sbolshakov 2004-09-20 16:59:14 +0400 в долгий ящик 26612 7 mike 2005-06-29 15:30:48 +0400 долгий ящик для подобного можно было бы уже завести на манер #3459 и #7079... rider, что скажешь? 57792 8 mike 2007-11-10 14:23:38 +0300 update (у меня где-то валяется мнение evms про соляровский disklabel, хотя с тех пор стало проще проверить живьём...) 123323 9 mike 2011-07-19 23:42:41 +0400 Собсно в такой формулировке багрепорт ни о чём.