Автоматическое определение новых дисков в ASP11

Аватар пользователя Dragon

Весьма интересует следующий вопрос. При подключении к машине с 11 АСП-ом дополнительного HDD система не производит никаких действий (по крайней мере у меня). Это нормально? Я так понимаю, что по идее такие вещи должны отслеживаться (HAL???), вплоть до предложения внести соотвествующие изменения в fstab... Есть ли решение задачи? Где-то что-то можно подкрутить?

Аватар пользователя rjaan

Re: Автоматическое определение новых дисков в ASP11

Dragon писал(а):
вплоть до предложения внести соотвествующие изменения в fstab...

Во-первых я бы посмотрел результат инциализации ядра, а не лез в fstab и не крутил HAL.

Цитата:
Весьма интересует следующий вопрос. При подключении к машине с 11 АСП-ом дополнительного HDD система не производит никаких действий

И не будет, но она должна его обнаруживать во-время инициализации драйверов IDE или SCSI
Пример обнаружения диска IDE HDD Primary Master, /dev/hda.

[root@home ~]#demsg | grep hda
ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio
hda: ST3802110A, ATA DISK drive
hda: max request size: 1024KiB
hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
hda: cache flushes supported
   hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 >
EXT3 FS on hda5, internal journal
EXT3 FS on hda3, internal journal
EXT3 FS on hda6, internal journal
EXT3 FS on hda7, internal journal

Dragon писал(а):
Где-то что-то можно подкрутить?

Да нужно всего лишь прописать его в /etc/fstab, где указаываете точку монтирования, тип FS и дополнительные опции к ней.

Да, если диск новый, свежачек Улыбка Незабудте его разбить FDISK'ом и отформатировать разделы MKE2FS.

Dragon писал(а):
Я так понимаю, что по идее такие вещи должны отслеживаться (HAL???)

А HAL тут не причем... Не виноват он! Улыбка

Аватар пользователя DRVTiny

Re: Автоматическое определение новых дисков в ASP11

rjaan, я так сильно подозреваю, что товарищ Dragon несколько иное имел в виду.
Вот, например, в SuSE 10 и Knoppix система при старте сканирует все жёсткие диски в поисках разделов, определяет тип разделов и вносит соотв. записи в fstab. ASP этого не делает. Отсюда и вопрос человека, по всей видимости не обвыкшегося ещё в консоли и привыкшего монтировать носители кликом по иконке: как сделать так, чтобы записи о разделах вносились в fstab автоматически? Ведь для сменных носителей типа флэшек или cd сейчас даже без fstab-sync'а прозрачное монтирование прекрасно работает, так почему же пользователи ASP'а до сих пор должны тратить своё драгоценное время на то, чтобы вручную mount'ом подключать разделы жёстких дисков (кстати, судя по всему, ASPLinux даже не умеет подключать разделы по метке тома) и/или опять же вручную прописывать их в fstab? Если SuSE и Knoppix умеют делать это, то почему бы разработчикам ASPLinux не перенять позитивный опыт своих немецких коллег?

Аватар пользователя rjaan

Re: Автоматическое определение новых дисков в ASP11

DRVTiny писал(а):
ASPLinux даже не умеет подключать разделы по метке тома) и/или опять же вручную прописывать их в fstab? Если SuSE и Knoppix умеют делать это, то почему бы разработчикам ASPLinux не перенять позитивный опыт своих немецких коллег?

Вообще-то, если речь идет о HAL, то он предназначен для применения на сменных носителях. А жесткие диски вешь считается не съемная их всегда прописывают явно: партиция, точка монтирования, тип ФС.

DRVTiny писал(а):
(кстати, судя по всему, ASPLinux даже не умеет подключать разделы по метке тома)

Делать монтирование по метки диска -- это опасно в случае, если последнюю потрут или изменят.

Аватар пользователя DRVTiny

Re: Автоматическое определение новых дисков в ASP11

Цитата:
Вообще-то, если речь идет о HAL, то он предназначен для применения на сменных носителях.

Да? Ну надо же! Кстати, интересно, что жёсткие диски тоже могут быть и сменными, и переносными и какими угодно. Вот мне как раз сейчас из аудитории подсказывают, что стандарт Serial ATA, оказывается, поддерживает горячее подключение. Я Вам больше скажу: если не HAL, то по крайней мере небезызвестный UDev прекрасно знает, какие в системе есть жёсткие диски и какие на них есть разделы. Мало того, есть такая чудесная программка относительно скромных (в особенности если сравнивать с каким-нибудь очередным sendmail'ом) размеров, - parted называется, - которая, пользуясь совершенно стандартными библиотеками для работы с различными файловыми системами и вполне общедоступными API ядра, умудряется узнавать всё, что нужно для абсолютного прозрачного монтирования разделов (кстати, опции "правильного" монтирования, в том числе nls,iocharset,cp1251, вполне способна подобрать даже очень несложная программа). Так не можем или не хотим? А если не хотим, то почему? У меня создаётся впечатление, что обделённые достаточно развитым головным мозгом представители хакерской общественности элементарно боятся утратить свой "элитный" статус страшно крутых понтокидателей, разбирающихся в "UNIX страшном и ужасном" и поэтому всей своей серой массой "электората" препятствуют становлению Linux в качестве высокотехнологичной и по-настоящему интеллектуальной системы (а некоторые даже мигрируют на BSD, поскольку работать в Linux становится уже "как-то не круто"). В этом проблема, а не в пользователях, которые почему-то не желают тратить своё драгоценное (т.е. несколько более ценное, нежели у "скучающих системных администраторов") время на совершение вопиюще алогичных (я думаю, этому можно научить и обезьяну) механических действий по внесению в конфигитой самой информации, которой по логике вещей сама система должна располагать в полной мере.

Цитата:
Делать монтирование по метки диска -- это опасно в случае, если последнюю потрут или изменят.

Не вижу в этом ничего опасного - в условиях "необратимости перемен", застигших врасплох структуру управления энергетикой, потенциальную опасность представляют любые смонтированные в режиме rw разделы, но уж никак не наоборот. В крайнем случае дописать строчку init=/bin/bash в параметры ядра, я думаю, будет не обременительнее правки /etc/fstab'а
На мой взгляд структура разделов по идее должна бы меняться несколько чаще, нежели метки томов, являющиеся уникальными идентификаторами соответствующих разделов. В идеале метки должны теряться только при форматировании (хотя и это совсем не очевидно, поскольку метка тома не зависит от состояния файловой системы на томе). Например, у меня вчера при /dev/hdb7 стал /dev/hdb6, а /dev/hdb6 - /dev/hdb7. Метки при этом остались прежними.

RSS-материал