Почему при наличии на диске primary раздела FAT32 следующий за ним раздел по умолчанию создается также primary? И сюда же: почему кнопка "Дополнительно" (где указывается первичность и активность создаваемого раздела) доступна только при создании раздела, но недоступна при редактировании (даже если результаты не были записаны на ЖД)?
(In reply to comment #0) > Почему при наличии на диске primary раздела FAT32 следующий за ним раздел по > умолчанию создается также primary? А баг-то в чем? > И сюда же: почему кнопка "Дополнительно" (где указывается первичность и > активность создаваемого раздела) доступна только при создании раздела, но > недоступна при редактировании (даже если результаты не были записаны на ЖД)? Потому, что это не реализовано в evms
(In reply to comment #1) > (In reply to comment #0) > > Почему при наличии на диске primary раздела FAT32 следующий за ним раздел по > > умолчанию создается также primary? > А баг-то в чем? Я читал, что принято создавать в системе один primary раздел. > > И сюда же: почему кнопка "Дополнительно" (где указывается первичность и > > активность создаваемого раздела) доступна только при создании раздела, но > > недоступна при редактировании (даже если результаты не были записаны на ЖД)? > Потому, что это не реализовано в evms А можно хранить изменения "в уме" и отдавать их этому самому evms'у только при действительном внесении изменений (т.е. при переходе на следующий шаг и после подтверждения от пользователя)?
> > > Почему при наличии на диске primary раздела FAT32 следующий за ним раздел по > > > умолчанию создается также primary? > > А баг-то в чем? > Я читал, что принято создавать в системе один primary раздел. Это принято только для MSDOS и Win9x > > > > И сюда же: почему кнопка "Дополнительно" (где указывается первичность и > > > активность создаваемого раздела) доступна только при создании раздела, но > > > недоступна при редактировании (даже если результаты не были записаны на ЖД)? > > Потому, что это не реализовано в evms > А можно хранить изменения "в уме" и отдавать их этому самому evms'у только при > действительном внесении изменений (т.е. при переходе на следующий шаг и после > подтверждения от пользователя)?
(In reply to comment #1) > А баг-то в чем? Наверное, подразумевалось, что винды могут ошизеть от нескольких primary... деталей не помню, коллеги вот подсказывают, что с NT порядок, а с win98 могут быть проблемы, если не пометить второй+ primary раздел как hidden (опять же подсказывают, что элементарно делается средствами lilo/grub). В общем, проще лепить тогда extended. Кажется, diskdrake так и делает. PS re #2: это ерунда на самом деле, их может быть четыре штуки. Но на практике досообразные могут при этом глючить и/или тормозить... (как тут ещё уточнили про win98 в таком раскладе) > Потому, что это не реализовано в evms Объехать можно, но для 3.0 действительно не вижу никакого смысла. PS re #2: бессмысленно в install2-x11-qt, да и вообще evms сам буферит состояние -- тогда или его допиливать, или удалять/создавать проще.
(In reply to comment #4) [...] > > Потому, что это не реализовано в evms > Объехать можно, но для 3.0 действительно не вижу никакого смысла. Вот я и езжу. При смене файловой системы удаляю раздел с диска, чтоб его id сменить.
(In reply to comment #2) > А можно хранить изменения "в уме" и отдавать их этому самому evms'у нет
reopen
reassign
и, кажется, FIXED
