Не монтируется 2й жесткий диск.[РЕШЕНО]

Здравствуйте. У меня в системнике (2.6.27-gentoo-r7) 2 жестких диска. sda и sdb. Gentoo установлен на sda. Проблема в том, что у меня не получается примантировать ни один раздел с sdb. Ниже приведу вывод нескольких команд (не знаю что дествительно нужно).
Оба винчестера IDE, висят на 1м шлейфе.

#fsck /dev/sdb3
fsck 1.41.3 (12-Oct-2008)
e2fsck 1.41.3 (12-Oct-2008)
fsck.ext3: Устройство или ресурс занято while trying to open /dev/sdb3
Filesystem mounted or opened exclusively by another program?
 # mount
/dev/sda8 on / type ext3 (rw,noatime)
/proc on /proc type proc (rw,nosuid,nodev,noexec)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)
udev on /dev type tmpfs (rw,nosuid,size=10240k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,gid=5,mode=620)
/dev/sda10 on /home type ext3 (rw,noatime)
shm on /dev/shm type tmpfs (rw,noexec,nosuid,nodev)
usbfs on /proc/bus/usb type usbfs (rw,noexec,nosuid,devmode=0664,devgid=85)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
securityfs on /sys/kernel/security type securityfs (rw,noexec,nosuid,nodev)
/dev/sda6 on /mnt/sda6 type ntfs (rw,noexec,nosuid,nodev,noatime,uid=1000,gid=1000,user=lup)

Здесь то, что пишет fdisk /dev/sdb:

Команда (m для справки): p

Диск /dev/sdb: 200.0 ГБ, 200049647616 байт
255 heads, 63 sectors/track, 24321 cylinders
Units = цилиндры of 16065 * 512 = 8225280 bytes
Disk identifier: 0x7b9d0860

Устр-во Загр     Начало       Конец       Блоки   Id  Система
/dev/sdb1               1        2550    20482843+   5  Расширенный
/dev/sdb2            2551        2741     1534207+  82  Linux своп / Solaris
/dev/sdb3            2742       24321   173341350   83  Linux
/dev/sdb5   *           1          18      144522   83  Linux
/dev/sdb6              19        2550    20338258+  83  Linux

Ну и собственно:

# mount -t ext3 /dev/sdb3 /mnt/sdb3
mount: /dev/sdb3 уже примонтирован или /mnt/sdb3 занят

Я Gentoo установил неделю назад первый раз :) До этого пользовался Ubuntu, так что я пока "наивный .. школьник". По-этому мне бы на пальцах, если можно :). Заранее спасибо.
...
Да, еще тут dmesg запустил. Он мне много такого написал: (не знаю, относится ли это к винчестеру, но малоли...)

...

[    7.985220] udev: renamed network interface eth0_rename to eth1
[    9.819914] device-mapper: table: 253:0: linear: dm-linear: Device lookup failed
[    9.819921] device-mapper: ioctl: error adding target to table
[    9.822145] device-mapper: table: 253:0: linear: dm-linear: Device lookup failed
[    9.822152] device-mapper: ioctl: error adding target to table

...

мб пересоздать раздел? о.О

мб пересоздать раздел? о.О
прям глюки какието

это уже в крайнем случае

Очень не хотелось бы все форматировать. Это будет крайним вариантом, если больше уже ничего не поможет. Кстати, запустился с liveCD Knoppix 5,1, там все разделы смонтировались, все хорошо.Только русские буквы не читались.

"Настоящему индейцу завсегда везде ништяк!"

.

lup написал(а):
Ну и собственно:
[code]
# mount -t ext3 /dev/sdb3 /mnt/sdb3
mount: /dev/sdb3 уже примонтирован или /mnt/sdb3 занят

Собственно, интересно, на каком основании ты сделал вывод относительно того, что файловая система Linux'овых разделов на sdb - ext3 (а не тот же reiser3 или... вариантов до фига)?

Попробуй что-нибудь типа mount -t auto или просто
# mount /dev/sdb3 /mnt/sdb3

ЗЫ: Почто поломали интерпретацию тэга 'code'???

:wq
--
Live free or die

Пробовал :(. Та же фигня.

Пробовал :(. Та же фигня. Удалил запись из /etc/fstab по поводу этого раздела (при установке вписал туда), но результат не изменился.

# mount /dev/sdb3 /mnt/sdb3
mount: /dev/sdb3 уже примонтирован или /mnt/sdb3 занят
Lup lup # mount /dev/sdb3 -t auto /mnt/sdb3
mount: /dev/sdb3 уже примонтирован или /mnt/sdb3 занят

Можеть быть мне в ядре надо что нибудь включить, чтобы 2 винчестера вместе работали? Или какой нибудь процесс его использует..

"Настоящему индейцу завсегда везде ништяк!"

Да, а для "школьника" ты крут! =)))

"Можеть быть мне в ядре надо что нибудь включить, чтобы 2 винчестера вместе работали?" -- однако, верная мысль! ;-) и лог хороший из dmesg...

Device Drivers -->
  SCSI device support -->
    [*] Probe all LUN on each SCSI device

Короче, проверь/попробуй включить опцию CONFIG_SCSI_MULTI_LUN и отпишись...

На всякий случай:

modprobe configs # если нужно
zgrep CONFIG_SCSI_MULTI_LUN /proc/config.gz

ЗЫ: а вот так сразу securityfs && TPM -- эта ваще! :)

P.S.: Вспомнил! Если это уже включено, значит проблема несоответствия железа спецификациям.
В ядрах где-то с 2.6.24/25 появился временный (отладочный) workaround этой БАГИ ПРОИЗВОДИТЕЛЯ.
Нужно просто использовать в параметрах загрузки ядра опции libata.dma=... / libata.force=...
See details in: /usr/src/linux/Documentation/kernel-parameters.txt

мдя....

Пока не хочет работать.
Что я пытался сделать:
Включил CONFIG_SCSI_MULTI_LUN в ядро, не помогло.
также добавлял в /boot/grub/grub.conf опции для libata (сначала те параметры, что закоментированы, потом попробовал с libata.pata_dma, но тоже безрезультатно).

В целом grub.conf выглядит так:(у меня шлейф к винту 80и-жильный)

default 0
timeout 30
#splashimage=(hd0,0)/boot/grub/splash.xpm.gz

title Gentoo Linux 2.6.24-r5
root (hd0,6)
kernel /boot/gentoo root=/dev/sda8 libata.pata_dma=1 
#kernel /boot/gentoo root=/dev/sda8 libata.dma=0 libata.force=ata2.00:80c

title=Must die
rootnoverify (hd0,0)
makeactive
chainloader +1

Напрягает тот факт, что диски у меня сейчас обзываются sda, sdb. Я тут погуглил, и подумал, может быть мне выключить libata из ядра (если он включен), но не нашел где оно выключается. Не подскажите? )
К тому же - странность, ведь fdisk нормально работает с этим жестким диском. И вобще, SATA надо полностью убрать из ядра..

Цитата:
На всякий случай:

modprobe configs # если нужно
zgrep CONFIG_SCSI_MULTI_LUN /proc/config.gz

Вот это я не понял..

 # modprobe configs 
FATAL: Module configs not found.

еще кое что: (извиняюсь за длину)

 # hdparm -I /dev/sdb

/dev/sdb:

ATA device, with non-removable media
	Model Number:       ST3200820A                              
	Serial Number:      5QE2QT5H
	Firmware Revision:  3.AAE   
Standards:
	Supported: 7 6 5 4 
	Likely used: 7
Configuration:
	Logical		max	current
	cylinders	16383	16383
	heads		16	16
	sectors/track	63	63
	--
	CHS current addressable sectors:   16514064
	LBA    user addressable sectors:  268435455
	LBA48  user addressable sectors:  390721968
	device size with M = 1024*1024:      190782 MBytes
	device size with M = 1000*1000:      200049 MBytes (200 GB)
	cache/buffer size  = 8192 KBytes
Capabilities:
	LBA, IORDY(can be disabled)
	Standby timer values: spec'd by Standard, no device specific minimum
	R/W multiple sector transfer: Max = 16	Current = 16
	Recommended acoustic management value: 208, current value: 0
	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4 
	     Cycle time: no flow control=240ns  IORDY flow control=120ns
Commands/features:
	Enabled	Supported:
	    	SMART feature set
	    	Security Mode feature set
	   *	Power Management feature set
	   *	Write cache
	   *	Look-ahead
	   *	Host Protected Area feature set
	   *	WRITE_BUFFER command
	   *	READ_BUFFER command
	   *	DOWNLOAD_MICROCODE
	    	SET_MAX security extension
	   *	48-bit Address feature set
	   *	Device Configuration Overlay feature set
	   *	Mandatory FLUSH_CACHE
	   *	FLUSH_CACHE_EXT
	   *	SMART error logging
	   *	SMART self-test
	   *	General Purpose Logging feature set
Security: 
	Master password revision code = 65534
		supported
	not	enabled
	not	locked
	not	frozen
	not	expired: security count
	not	supported: enhanced erase
HW reset results:
	CBLID- above Vih
	Device num = 1 determined by the jumper
Checksum: correct

То же самое посмотрел для 1го работающего нормально винчестера. Выводы программы hdparm для обоих веников абсолютно идентичны, за исключением номера модели, сериного номера и объемов(в том числе кэша(у рабочего кэш в 2 раза больше)).

"Настоящему индейцу завсегда везде ништяк!"

Поддержка libata в ядре

Поддержка libata в ядре находится здесь:
Device Drivers --->
< > Serial ATA (prod) and Parallel ATA (experimental) drivers --->
При включении данной опции все диски, независимо от интерфейса (IDE или SATA) обозначаются как sd*.

сори, не угадал! :-(

Чем напрягать и без того подыхающий моск, мне стоило заставить поработать гугль! =)))
Вот эта ошибка весьма распространена:

device-mapper: table: 253:0: linear: dm-linear: Device lookup failed
device-mapper: ioctl: error adding target to table

Связана она либо с LVM либо с EVMS. Ничем из этого не пользуюсь.
Либо что-то намудрил genkernel при создании initrd-образа,
либо в ядре есть нечто лишнее, либо установлено что-то конфликтующее,
типа sys-fs/evms, sys-fs/{lvm-user,clvm,lvm2}. Короче не знаю.
Предлагаю для начала скинуть конфиг ядра на pastebin...

> Вот это я не понял..
modprobe configs # значит тебе оно и не нужно! мало кто делает так...
Главное вот это я имел ввиду:
zgrep CONFIG_SCSI_MULTI_LUN /proc/config.gz
Но теперь это уже и не важно...

> Выводы программы hdparm для обоих веников...
...можно отправить лесом. Потому как для libata нужно юзать sdparm...

конфиг ядра

Ядро я сам собирал, так что могут быть и косяки ).
Собирал по хенд буку, а потом уже мог и ченить лишнего добавить.
воть: :-)
http://pastebin.com/m430a7dd7

"Настоящему индейцу завсегда везде ништяк!"

В этот раз индейцу поистине свезло! =)))

В моём загашничке сохранился один из древних конфигов для
i686: 2.6.27-gentoo-r6 (а у тебя -r7, т.е. чуток новее).
За правильность тоже не ручаюсь, тем паче, оно для конкретного ноута.
Вот Diff: http://pastebin.com/d51daca7 разберёшься?
Тоже руками делалось, не генкернелом...

Возможно вот это поможет:

CONFIG_MD=n
CONFIG_BLK_DEV_MD=n
CONFIG_BLK_DEV_DM=n
CONFIG_DM_MIRROR=n
CONFIG_DM_ZERO=n

Потом не знаю, нужен ли тебе аудит и SELinux?
Вот - выложил ещё относительно свежий конфиг для 2.6.28.1 (amd64/vanilla-sources).

А из вышеперечисленных пакетов случайно ничего не устанавливалось?
Может лучше emerge -Ca их?

Открываем шампанское и выпиваем ящик пива!!!

Наконецто mount сработал! Помогла пересборка ядра.

Цитата:
CONFIG_MD=n
CONFIG_BLK_DEV_MD=n
CONFIG_BLK_DEV_DM=n
CONFIG_DM_MIRROR=n
CONFIG_DM_ZERO=n

Выключил в ядре параметры, которые вы предложили и все поехало ).
Всем кто помогал - большое спасибо? в особенности Леониду ).
----
Теперь попробую удалить из ядра libata. Когда диски называются /dev/hd* както приятнее ), да и SATA не нужен мне.

"Настоящему индейцу завсегда везде ништяк!"

libata - это новая жизнь!

> Теперь попробую удалить из ядра libata.
А вот этого делать не надо! ;-)

После удаления libata ядро

После удаления libata ядро начало паниковать... отрубился инет (долбаный VPN, руки вырвать тому, кто его придумал!).. Вернул libata на место )))

"Настоящему индейцу завсегда везде ништяк!"

Рано тему закрывать, ИМХО.

Мы лишь максимально быстро приблизились к тому месту, рядом с котрым связан твой баг. :(
Убрать DM/MD из ядра - это не решение проблемы.
В большинстве ядер, даже дефолтных, это всё включено.
У меня тоже это всё включено во всех последних ядрах, ИМХО, не должно оно влиять!!!
Если на самом деле это то, что я думаю, то впереди у тебя еще граблей будет немало...
Впрочем, дело твоё - рыть дальше или нет.

Я склоняюсь к тому, что это всё же кривой udev либо его правило.
Как вариант, в твоём init-е не прописан нужный boot-скрипт.
В частности интересует вот чего...

Чего говорят emerge -vp udev baselayout; rc-update show?
Есть ли при запуске надпись "Setting up dm-crypt mapping... [ ok ]"?

убираем грабли )

Воть. Насчет baselayout.Когда только устанавливал gentoo, помоему пытался ati-drivers установить(безрезультатно). Мне вылазила какаято ошибка по поводу baselayout, кажись. Я не знал что это и удалил его :-)(не без сомнений конечно же). После последующей перезагрузки система перестала грузится ). Тогда я подгрузился с live CD Gentoo и, применив chroot, установил его обрато (просто "emerge baselayout").....Не к добру это видать ))
emerge -vp udev baselayout:

 emerge -vp udev baselayout

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] sys-apps/baselayout-1.12.11.1  USE="unicode -bootstrap -build -static" 0 kB
[ebuild   R   ] sys-fs/udev-124-r1  USE="(-selinux)" 0 kB

rc-update show:

# rc-update show
           alsasound | boot                          
            bootmisc | boot                          
             checkfs | boot                          
           checkroot | boot                          
               clock | boot                          
         consolefont | boot                          
            hostname | boot                          
             keymaps | boot                          
               local |      default nonetwork        
          localmount | boot                          
             modules | boot                          
            net.eth1 |      default                  
              net.lo | boot                          
            netmount |      default                  
           rmnologin | boot                          
           syslog-ng |      default                  
             urandom | boot                          
          vixie-cron |      default                  
                 xdm |      default     

"Настоящему индейцу завсегда везде ништяк!"

Ого. Где alexxy? Пусть

Ого.
Где alexxy? Пусть пополнит свою коллекцию системных пакетов, которые удалили (-%Е

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

Ну-с, приступим...

Поскольку удалялся baselayout и были подозрения на init-скрипты, а на один вопрос так и не ответил, предлагаю для начала проверить консистентность системы: запостить туда же вывод `emerge --info`, `lspci -vvnn`, `emerge -vpuDN world` и `revdep-rebuild -p`. Примерно по ТАКОЙ ВОТ СХЕМЕ бум приводить систему в порядок для начала. Теперь более детально изучил содержимое твоего конфига. Я бы категорически не стал отталкиваться от него для нормальной системы! ;) Уж лучше заюзать gengernel. Но для выяснения конкретной проблемы и чистоты эксперимента оставим его с небольшими поправками...

Вот это точно нужно изменить:

CONFIG_DLM=y
CONFIG_IDE=n
CONFIG_SCSI_TGT=y
CONFIG_BLK_DEV_MD=n
CONFIG_DM_CRYPT=y
CONFIG_DM_SNAPSHOT=y
CONFIG_DM_MULTIPATH=y
CONFIG_DM_UEVENT=y

И CONFIG_UEVENT_HELPER_PATH, скорее всего, тоже! Там есть два варианта. Сейчас стоит "/sbin/hotplug", который относится к пакету sys-apps/hotplug-base (у меня в системе 20040401). Но в новых удавах его ф-ю похоже выполняет "/sbin/udevadm", который относится к пакету sys-fs/udev (у меня в системе 124-r1 и именно это значение прописываю очень давно). На самом деле это зависит от версии удава. В новых sys-fs/udev "старый помощник ядра" /sbin/hotplug отсутствует, поэтому я ставлю здесь "/sbin/udevadm". Ничего толкового не нашёл, но знаю, что народ периодически огребает проблемы с удавом именно из-за того, что опция тянется со старыми конфигами ядра, а версии удавов обновляются!.. ;-)

Я бы и это изменил приоритетно, хотя непосредственно к делу относится не всё:

CONFIG_X86_PAT=n
CONFIG_PCIEASPM=y
CONFIG_PCI_LEGACY=y
CONFIG_HOTPLUG_PCI=n
CONFIG_BLK_DEV_IO_TRACE=n
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=n
CONFIG_AUDIT=n
CONFIG_CGROUPS=n
CONFIG_GROUP_SCHED=n
CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_USER_NS=n
CONFIG_PID_NS=n
CONFIG_PROFILING=n

В секции "Serial ATA (prod) and Parallel ATA (experimental) drivers", скорее всего, тоже необходимы изменения. Но пока не знаю, что за железо (dmesg, lspci), лезть туда бесполезно...

Здесь emerge

Здесь emerge --info:
http://pastebin.com/m4179f2e9

Здесь lspci -vvnn:
http://pastebin.com/m68cb6a4c

Здесь emerge -vpuDN world
http://pastebin.com/m51321c24

revdep-rebuild -p не запускается, наверно нет соответствующего пакета.

Здесь dmesg: (это тот вопрос, на который я не ответил? )
http://pastebin.com/m61cacba3

Воть, сейчас буду вносить изменения в ядро.. ))
Насчет ядра.. Я хотел, всетаки, его сам сделать )). Жаль, что криво получилось, со временем разберусь, надеюсь! Не хочу genkernel.

Вот эти строки в конфиге вобще не нашел:

CONFIG_BLK_DEV_MD
CONFIG_DM_CRYPT
CONFIG_DM_SNAPSHOT
CONFIG_DM_MULTIPATH
CONFIG_DM_UEVENT
их в конец конфига добавить?

"Настоящему индейцу завсегда везде ништяк!"

Да, можно и в конец

Вообще-то имелось ввиду вернуть сначала конфиг в предыдущее состояние, а то не будет понятно, что именно новое решение оказало влияние, а не старое. Т.е. за основу берётся конфиг ядра, выложенный в самом начале. И уже от него отталкиваться. Есть пара хороших новостей...

Во-первых, я почти не сомневаюсь, что приведение в порядок ядра сработает. Там это связано всего с несколькими опциями (затрагивающими и udev и libata). Было включено одновременно два режима (с и без libata, CONFIG_IDE=y) - потому и глючило ATA. Кроме того, тот самый udev helper. В этот раз смотрел через make menuconfig, а не делал diff-ы. :)

Во-вторых, выложенный emerge -vauDN world говорит о том, что систему привести в порядок труда не составит. Это всё равно нужно сделать, но я думаю пока можно заняться ядром. На данную проблему оно скорее всего не влияет.

Знать бы точно, что за железо. Название ноута или материнской платы. Найти более правильную настройку и глянуть в сети, особенно по тем ус-вам, для котрых сейчас не стоит соответствие модуля в ядре:

00:1f.1 IDE interface [0101]: Intel Corporation 82801DB (ICH4) IDE Controller [8086:24cb] (rev 02)
Kernel driver in use: ata_piix

00:01.0 PCI bridge [0604]: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE Host-to-AGP Bridge [8086:2561] (rev 03)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev 82)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge [8086:24c0] (rev 02)
...
02:0c.1 Input device controller [0980]: Creative Labs SB Live! Game Port [1102:7002] (rev 08)
а с этими нужно разбираться...

Теперь по поводу ядра. Несколько лет назад я сгенерил генкернелом. Отличия в том, что он включает много всего ненужного и модулями. Поэтому я отключил, что мне ненужно и включил всё что нужно мне в ядро (без модулей). Потом я таскал конфиг с машины на машину внося некотрые изменения. Разумеется, над каждой опцией приходилось не только думать, но и много читать, искать инфу в сети. И тот конфиг ядра пережил несколько поколений ядер с 2.6.18 до 2.6.28...

Недавно я озадачился тем, что это всё таки стрёмно и решил снова воспользоваться genkernel-ом, чтобы свериться. Мне не требуется образ initrd, который он генерит, но хотелось понять относительно опций, не связанных с имеющимся у меня железом. Разница оказалась настолько незначительной, что поймал я у себя считанные "ошибки", т.е. в genkernel это стояло по уму. Так что аккуратненько отталкиваясь от него - не ошибёшься! ;-)

Железо

Железо такое:
Это не ноут )), стационарная машина. Pentium 4, мамка ASUS P4PE 845PE.
Тута немного описалова мамки:
http://pc.km.ru/magazin/view.asp?id=16A8A9561FF143F18561CDA15F92DA55
А игровой порт звуковой карты нафиг не нужен )
Остальное..:1Gb оператива, DDR1 кажись,видео ati Radeon 9000Pro, Criative Sound Blaster Live 5.1 (кажись так пишется), 2 веника barakuda, к ним шлейф 80жил. 2 сетевухи (с ними еще геморой). Встоеную сетевуху (на сколько я понимаю сгорела, но видимо не до конца раз определяется) никак не отключить. Если в биосе отключаю, gentoo все равно ее находит )) Надо новерно ее модуль убить в ядре ), сорь, это уже оффтоп ))
Вернул старый конфиг ядра, ща буду его модифицировать и пробовать.
Да, ядро я собираю так: (ну на всякий случай)

make menuconfig #ну там опции вкл/выкл
make && make modules_install #сама сборка
cp arch/i386/boot/bzImage /boot/gentoo-test
reboot

...
Начал компилировать вылезла вот такая штука:

 # make && make modules_install
scripts/kconfig/conf -s arch/x86/Kconfig
*
* Restart config...
*
*
* Bus options (PCI etc.)
*
PCI support (PCI) [Y/n/?] y
  PCI access mode
    1. BIOS (PCI_GOBIOS)
    2. MMConfig (PCI_GOMMCONFIG)
    3. Direct (PCI_GODIRECT)
  > 4. Any (PCI_GOANY)
  choice[1-4?]: 4
PCI Express support (PCIEPORTBUS) [Y/n/?] y
  Root Port Advanced Error Reporting support (PCIEAER) [Y/n/?] y
  PCI Express ASPM support(Experimental) (PCIEASPM) [Y/n/?] y
    Debug PCI Express ASPM (PCIEASPM_DEBUG) [N/y/?] (NEW) 


нажал <ctrl-c> и набрал make menuconfig? потом при выходе он спросил, сохранить ли конфиг. я согласился. Собралось ядро, теперь ребут.
Ядро загрузилось, работает. Но /dev/sdb монтироваться перестал с той же ошибкой(

"Настоящему индейцу завсегда везде ништяк!"

Я понял, не то... :-(

Идёшь в /usr/src/linux. Делаешь там make mrproper.
Берёшь с pastebin свой старый конфиг, сохраняешь его в /usr/src/linux/.config
Запускаешь make menuconfig и включаешь/выключаешь ХОТЯ БЫ это:

-*- Enable the block layer  --->
  [ ]   Support for tracing block io actions
Bus options (PCI etc.)  --->
  [*] Enable deprecated pci_find_* API
  < > Support for PCI Hotplug  --->
Device Drivers  --->
  Generic Driver Options  --->
    (/sbin/udevadm) path to uevent helper
  < > ATA/ATAPI/MFM/RLL support  --->
  <*> Serial ATA (prod) and Parallel ATA (experimental) drivers  --->
    < >   AHCI SATA support
    [*]   ATA SFF support
    <*>     Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support
    < >     AMD/NVidia PATA support
    < >     Generic ATA support
    < >     Intel PATA MPIIX support
    < >     Intel PATA old PIIX support
    < >     Intel SCH PATA support
  SCSI device support  --->
    <*> SCSI target support
  [*] Multiple devices driver support (RAID and LVM)  --->
    < >   RAID support
    <*>   Device mapper support
    <*>     Crypt target support
    <*>     Snapshot target
    <*>     Multipath target
    [*]     DM uevents (EXPERIMENTAL)
File systems  --->
  <*> Distributed Lock Manager (DLM)  --->

выходишь/сохраняешь, а дальше всё, как ты выше написал - правильно.
Просто передать конфиг не смогу ибо у меня amd64, а не x86, так что могут быть различия...

P.S.: Обрати вниание, в libata мы включили единственный девайс:
'Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support' -- см. ЗДЕСЬ:
# vendor: 8086 ("Intel Corporation"), device: 24cb ("82801DB (ICH4) IDE Controller")
# vendor: 8086 ("Intel Corporation"), device: 24d1 ("82801EB (ICH5) SATA Controller")
# vendor: 8086 ("Intel Corporation"), device: 24db ("82801EB/ER (ICH5/ICH5R) IDE Controller")
и см. `lspci -vvnn | grep 82801 | egrep '24cb|24d1|24db'` ! ;-)

а зачем make mrproper? Что

а зачем make mrproper?
Что это?

"Настоящему индейцу завсегда везде ништяк!"

make help | less

`make help` есть для таких вопросов! =)))

Вот в чём фишка...

< > ATA/ATAPI/MFM/RLL support ---> CONFIG_IDE
<*> Serial ATA (prod) and Parallel ATA (experimental) drivers ---> CONFIG_ATA

Т.е. оба варианта были включены - и без libata, и с libata.
IDE (в т.ч. эта железка на ICH4) поддерживается обеими подсистемами.
Возможно потому и глючило...

Скомпилировал все по порядку.

Скомпилировал все по порядку. Скомпилировалось нормально. /dev/sdb не монтируется (( Ошибка все та же.

"Настоящему индейцу завсегда везде ништяк!"

Это на самом деле нормально.

Возможно дело не в ядре. Не будем пока на него грешить. Инит-скрипты вроде в норме.
Я бы сначала проверил уставновки в BIOS-е (их там два может оказаться).
Может эти диски действительно подцеплены, как RAID...
Главное, чтобы оба диска увиделись сейчас в dmesg через libata.

Потом стоит убрать пакет evms, поставить portage-utils, gentoolkit
и обновить систему до актуального состояния:
emerge -Ca evms
emerge -va portage-utils gentoolkit
emerge -vauDN world

# Если обновлялись питон/пёрл, после обновления прогнать python-updater; perl-cleaner all
emerge -a --depclean
revdep-rebuild
dispatch-conf (или etc-update)
reboot
(или source /etc/profile && env-update)

Возможно это неполадки с удавом. Пересборка покажет.
Её всё равно необходимо периодически делать независимо от решения данной проблемы.
Если не получится, смотрим в dmesg и /var/log/{kernel.log,messages}
на предмет ругани во время монтирования...

Обновление не удалось (

Сабж вылетел с ошибкой при сборке GCC. Ранее обновился питон.

make[1]: Leaving directory `/home/Portage_Temp/portage/sys-devel/gcc-4.1.2/work/build'
make: *** [install] Ошибка 2
 * 
 * ERROR: sys-devel/gcc-4.1.2 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_install
 *             environment, line 4688:  Called toolchain_src_install
 *             environment, line 5206:  Called gcc-compiler_src_install
 *             environment, line 2418:  Called die
 * The specific snippet of code:
 *       S=${WORKDIR}/build emake DESTDIR="${D}" install || die;
 *  The die message:
 *   (no error message)
 * 
 * If you need support, post the topmost build error, and the call stack if relevant.
 * A complete build log is located at '/home/Portage_Temp/portage/sys-devel/gcc-4.1.2/temp/build.log'.
 * The ebuild environment file is located at '/home/Portage_Temp/portage/sys-devel/gcc-4.1.2/temp/environment'.
 * 

>>> Failed to emerge sys-devel/gcc-4.1.2, Log file:

>>>  '/home/Portage_Temp/portage/sys-devel/gcc-4.1.2/temp/build.log'

"Настоящему индейцу завсегда везде ништяк!"

Причина возникновения ошибки

Причина возникновения ошибки находится где-то выше в этом лог-файле: /home/Portage_Temp/portage/sys-devel/gcc-4.1.2/temp/build.log. А вообще, так много предложено пересобрать в основном потому, что в make.conf/USE был включен флаг "doc". Когда смотрел, чего он там будет пересобирать, никаких существенных обновлений тулчейна не предлагалось. Сейчас нужно смотреть лог и пробовать пока пересобирать gcc.

В логе кроме этого места

В логе кроме этого места ошибок я не нашел. Может мне убрать флаг doc?
убрал флаг, запустил обновление. Вот cписок обновления:

http://pastebin.com/m307a7eeb

"Настоящему индейцу завсегда везде ништяк!"

> Может мне убрать флаг

> Может мне убрать флаг doc?

Сначала сделал, потом спрашиваешь! :)
Это на самом деле твоя gentoo: хочешь - ставишь или наоборот! ;-)
Сейчас вот убрал и теперь снова нужно пересобирать кучу уже собранных ранее пакетов.

> В логе кроме этого места ошибок я не нашел.

Лучше бы запостил тогда весь лог целиком. Это возможно как-то связано с твоим набором USE-флагов. Но я не допёр только исходя из вывода `emerge -vpuDN world`. :( Проблема в том, что у меня нет под рукой подобной системы. Но разница например с моими установками существенная. В особенности здесь я не могу понять причину пересборки glibc и gcc. Ну gcc ещё можно догадаться - был включен USE-флаг gtk. Но что не так с glibc совсем не могу понять - флаги вроде неизменны. А вот это:

CROSSCOMPILE_OPTS="-headers-only%"

видел тут на форуме разок, но не разобрался до конца, что оно значит. У меня подобного никогда не вылазило, и раньше на обычных профилях, и теперь на hardened, а в ебилдах glibc есть такие строчки:

# Here's how the cross-compile logic breaks down ...
#  CTARGET - machine that will target the binaries
#  CHOST   - machine that will host the binaries
#  CBUILD  - machine that will build the binaries
# If CTARGET != CHOST, it means you want a libc for cross-compiling.
# If CHOST != CBUILD, it means you want to cross-compile the libc.
#  CBUILD = CHOST = CTARGET    - native build/install
#  CBUILD != (CHOST = CTARGET) - cross-compile a native build
#  (CBUILD = CHOST) != CTARGET - libc for cross-compiler
#  CBUILD != CHOST != CTARGET  - cross-compile a libc for a cross-compiler
# For install paths:
#  CHOST = CTARGET  - install into /
#  CHOST != CTARGET - install into /usr/CTARGET/

#...

is_crosscompile() {
        [[ ${CHOST} != ${CTARGET} ]]
}
just_headers() {
        is_crosscompile && use crosscompile_opts_headers-only
}

#...

Причём just_headers() есть только в 2.6, в 2.6.1 уже нет (там эта опция используется жёстко, но фишка в том, что я всё равно её не вижу в выводе!). Короче я не могу объяснить причину желания пересобрать тулчейн. У меня такого никогда не было. Возможно использована распределённая или кросс-компиляция. Нужно спросить у кого-то ещё, с таким же стейджем и arch.

glibc по дефолту собран с -gd, я это обычно меняю. Но вместо gtk включаю qt. Также на компилятор влияют fortran и mudflap, которые я обычно выключаю. Ну первый мне просто ненужен. А второй - это тормознутная защита стека. В hardened его с успехом защищает SSP - это более эффективный, а главное более шустрый механизм.

Я не могу сказать, связано ли как-то выключение gd в glibc и включение gtk в gcc. Скорее всего нет. Но чтобы понять, почему не собирается компилятор, нужно увидеть лог целиком. Спрашиваю повторно! ;) Сейчас задача корректно пересобрать тулчейн, не сломав систему. Для этого нужно сначала пересобрать glibc, затем gcc-config, потом gcc. Всё отдельными emerge. Если застопорится, выкладывай build.log.

И мне кажется, ветка превращаяется в банальный флейм по типовой инсталляции gentoo, так-что лучше стучись в жаббер... ;-)

Думаю вы правы ) ) В общем, у

Думаю вы правы )
) В общем, у меня на компутере стало совсем жарко )) emerge стал часто материться и я решил все сделать заново, аккуратно и внимтельно. Все встало и работает пока нормально, в том числе сабж. Но все не зря, в процессе обсуждения (выше) я для себя узнал много нового )) Пасиба за ответы. Думаю вопрос можно закрывать.
Извините, что долго не отвечал, устанавливал систему, только сейчас XKB настроил )

"Настоящему индейцу завсегда везде ништяк!"

Вот наверное в чём собака порылась....

У тебя контроллер IDE детектится, как RAID (ну или в биосе так прописано). Очевидно, что дрова с железом работают не 100% нативно. Фактически, система работает не с двумя раздельными IDE-дисками, а с массивом через low-level, об который и спотыкается. Это можно легко проверить, не перекомпилируя ядро - глянь, есть ли /sys/block/md0. Если есть, попробуй отключить RAID в BIOS-е либо пересобери ядро с измененими, котрые предложил выше.

Колеги по цеху подкинули ещё идей, выкладываю...

1. Шалит udev с device-mapper-ом (неудачная версия удава или правил).

2. В single-mode тоже проблемы с монтированием?
(тогда в init-level-3 проверить инит-скрипты: rc-update show)

3. Вместо lsof проверить fuser -m /dev/sdb3 -- он понастырней.

4. Поставить один из этих двух пакетов (не знаю точно какой):
sys-apps/smartmontools или app-admin/ide-smart (скорее первый),
и прокрутить, что скажет вот это: smartctl -A /dev/sdb

Но мне кажется, сначала стоит опробовать выше сказанное... ;-)

NTFS rw :o

Alexandre ниже верно заметил, что /dev/sda6 монтируется как ntfs.
Эту каку из ядра лучше убрать (тем более в режиме rw)!
Оно дожило до 4-го поколения и теперь нужно ставить поддержку
ntfs-3g, FUSE (просто включить в ядре) и можно ещё ntfsprogs.

попробуй - монтировать без

попробуй
- монтировать без опции -t (он сам определит ФС)
- убрать загрузочный кыржик с 5-го раздела (почему-то думаю он лишний тут)
- посмотреть dmesg | grep sdb может там ошибки какие-то пишет
- попробуй другой каталог создать и туда примонтировать (может этот и правда чем-то занят)
- отключить все автомонтирования. в /etc/fstab он прописан монтироваться?
- попробуй размонтировать, потом снова примонтировать
- посмотреть lsof-ом чем может быть занят каталог /mnt/sdb3
Больше не знаю чего предложить...

PS не по теме:
/dev/sda6 on /mnt/sda6 type ntfs (rw...)
за сохранность данных то не страшно? о_О

:wq

По прежнему не работает (

Цитата:
- монтировать без опции -t (он сам определит ФС)

Результат тот же (

Цитата:
- убрать загрузочный кыржик с 5-го раздела (почему-то думаю он лишний тут)

Убрал.
- dmesg | grep sdb

# dmesg | grep sdb
[    1.231978] sd 0:0:1:0: [sdb] 390721968 512-byte hardware sectors (200050 MB)
[    1.232097] sd 0:0:1:0: [sdb] Write Protect is off
[    1.232177] sd 0:0:1:0: [sdb] Mode Sense: 00 3a 00 00
[    1.232218] sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    1.232439] sd 0:0:1:0: [sdb] 390721968 512-byte hardware sectors (200050 MB)
[    1.232542] sd 0:0:1:0: [sdb] Write Protect is off
[    1.232622] sd 0:0:1:0: [sdb] Mode Sense: 00 3a 00 00
[    1.232663] sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    1.232781]  sdb: sdb1 < sdb5 sdb6 > sdb2 sdb3
[    1.274271] sd 0:0:1:0: [sdb] Attached SCSI disk
[80280.339639] sd 0:0:1:0: [sdb] 390721968 512-byte hardware sectors (200050 MB)
[80280.361764] sd 0:0:1:0: [sdb] Write Protect is off
[80280.361777] sd 0:0:1:0: [sdb] Mode Sense: 00 3a 00 00
[80280.363282] sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[80280.363302]  sdb: sdb1 < sdb5 sdb6 > sdb2 sdb3

- Попытался смонтировать в другую папку (новую создал). Опять та же ошибка ((
- /etc/fstab теперь такой:

/dev/sda7		/boot		ext2		noauto,noatime	1 2
/dev/sda8		/		ext3		noatime		0 1
/dev/sda9		none		swap		sw		0 0
/dev/sda10		/home		ext3		noatime		0 2
/dev/sda6		/mnt/sda6	ntfs		uid=1000,gid=1000,user,noatime	0 0

lsof /dev/sdb не дает вобще ничего. (я так понял - это нормальное состояние для не подключеного раздела)

....Здается мне тут в ядре что-то, но вот что, вот в чем вопрос )

Да, еще. Если загрузится с Live CD Gentoo, там жесткие диски называются /dev/hda и hdb.. Здесть же /dev/sda и sdb.

Не по теме: Я забыл логин на форум, захожу с восстановлением пароля каждый раз )) Никак не догоню как узнать свой логин. )))

"Настоящему индейцу завсегда везде ништяк!"

К.О. приходит на помощь

lup написал(а):
Не по теме: Я забыл логин на форум, захожу с восстановлением пароля каждый раз )) Никак не догоню как узнать свой логин. )))

Ваш логин — lup
Всегда Ваш, Капитан Очевидность.

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

Пасиба, я похоже тут с

Пасиба, я похоже тут с паролем намудрил ))

"Настоящему индейцу завсегда везде ништяк!"

Мои 5 копеек - скачать новое

Мои 5 копеек - скачать новое ведро, удалив все старые. Собрать ведро через маке, заного. Без поддержки всех устройств, по минимуму, убрать поддержку хда, оставить только либату.
Сделать емерж -е ворлд - опционально [-:

lsof /dev/sdb? выводит что-нить?

ничего

неа, ничего не выводит.

"Настоящему индейцу завсегда везде ништяк!"

"Оба винчестера IDE, висят на

"Оба винчестера IDE, висят на 1м шлейфе."

Объясните мне неразумному, почему устройства называются sd*, а не hd*?

-= Concordia victoriam gignit =-

Потому что через libata они все как SCSI (и SATA, и PATA)

Хех, век живи, - век учись, а

Хех, век живи, - век учись, а завтра всё равно дураком станешь ))))
Ох уж этот прогресс и стандарты ))

-= Concordia victoriam gignit =-

Проблему пока не решил. Но

Проблему пока не решил. Но нашёл как её обойти без пересборки ядра. Нужно подключать SATA-шлейф уже после того как система загрузилась. Говорят, это возможно только с включенным в BIOS AHCI, но у меня работает в любом случае.

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".