ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | Выбор первичных разделов | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | wiee <egor> |
| Component: | alterator-vm | Assignee: | Олег Соловьев <mcpain> |
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
| Severity: | minor | ||
| Priority: | P2 | CC: | mcpain, mike, ptrnine |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
| Bug Depends on: | |||
| Bug Blocks: | 7371 | ||
|
Description
wiee
2005-07-21 16:12:19 MSD
(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 |
