LINUX.ORG.RU

Убунта ест жесткие диски!

 ,


0

1

Предыстория.

Установил Ubuntu 13.10 в VMWare 10 на реальный/физический жесткий диск (GPT, LVM, 600G целиком весь, EFI mode, ВМТварь в режиме firmware=«efi»). Поработал в ней немножко, установил TeamFortress в Steam и проверил, что он не запукается из-за неполного OpenGL (just as planned). Перезагрузил реальный компьютер и попытался загрузиться с него - Grub сказал «не вижу!». «Ну ладно», подумал я, перезагрузился в хост-систему и снова запустил VMWare в слабой надежде, что смогу разобраться с конфигом Grub'а и прописать ему автоопределение по лейблам жестких дисков. НО ВМТварь отказалась грузиться, выдавая ошибки.

Ошибки в разных местах, но преимущественно вот после этой (похожей) строчки в загрузки шубунты: [18.716606] siix4_smbus 0000:00:07.3: SMBus base address uninitialized - upgrade BIOS or use force_addr=0xaddr

Ошибка ВМТвари гласит: The operation on the file «\\.\PhysicalDrive3» failed. If the file resides on a remote file system, make sure that the network connection and the server where this disk resides are functioning properly. If the file resides on removable media, reattach the media. Retry/Continue/Cancel.

Если попробовать Continue, то Шубунта грозится в логе: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: BMDMA stat 0x24
ata1.00: failed command WRITE DMA
ata1.00: cmd ... (лень копипастить длинную строчку с адресом) tag 0 dma 4096 out
ata1.00: res ... (лень копипастить длинную строчку с адресом) Уьфыл 0x81 (invalid argument)
ata1.00: status {DRDY ERR}
ata1.00: error: {IDNF}

И не грузится вообще.

Это если жесткий подключить в режиме IDE.

А если в режиме SCSI, то вываливает те же ошибки, но после нескольких Continue убунта таки грузится, но время от времени виртуалка начинает сыпать такими же ошибками в рандомных местах, причем при выключении виртуалки они возникают сто пудов.

Сам реальный диск - целый, почти новый, бэдов нет, проверено проверялкой.

Что происходит?

★★★★☆

Произошёл конфликт доступа т.к. вы пробрасывали в виртуальную систему целиком жёсткий диск (или это не так) и он у вас один. Вообще почитайте документацию по VmWare, есть возможность пробрасывать в виртуальное окружение не целиком диск, а некоторые его разделы. К тому же смысл ставить было на реальный диск, ведь можно было использовать виртуальны диск.

kostik87 ★★★★★
()

это еще фигня, у меня на убунте при выключении головка жд щелкала так что я думал конец ему.

fallout4all ★★★★★
()
Ответ на: комментарий от kostik87

нет, у меня куча жестких дисков, а тот куда устанавливается убунта вообще offline. А смысл в том, чтобы сделать убунту, в которую можно будет загрузиться и из vmware, и с реального железа.

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

тот куда устанавливается убунта вообще offline

Как же вы тогда на него Ubuntu ставите, если он offline ?

нет, у меня куча жестких дисков,

Тогда объясните вот эту строку фразу:

Перезагрузил реальный компьютер и попытался загрузиться с него - Grub сказал «не вижу!». «Ну ладно», подумал я, перезагрузился в хост-систему и снова запустил VMWare в слабой надежде, что смогу разобраться с конфигом Grub'а и прописать ему автоопределение по лейблам жестких дисков. НО ВМТварь отказалась грузиться, выдавая ошибки.

С какого диска и как вы пытались грузиться ? Вызывая загрузочное меню ? Какая очерёдность опроса дисков и с какого грузится система ? В каком режиме работает SATA контроллера sata или ahci ? В каком режиме работал контроллер в виртуальной системе ?

в которую можно будет загрузиться и из vmware, и с реального железа.

Это не должно вызывать проблем, без разницы как вы ставите Linux, в виртуальном окружении или на реальное железо, единственно нужно, что бы в initramfs присутствовали драйверы эмулируемого и реального sata контроллера, проще, если и там и там контроллер работает в режиме ahci. Единственно, могут быть проблемы с запуском загрузчика.

kostik87 ★★★★★
()
Ответ на: комментарий от kostik87

Как же вы тогда на него Ubuntu ставите, если он offline ?

хостовая система - windows. offline (в терминах утилиты diskpart и панели управления дисками) означает недоступность монтирования, но прямой доступ остается.

С какого диска и как вы пытались грузиться ?

я установил убунту в vmware на единственный физический диск, доступный виртуалке. Потом выключил vmware, и загрузился с того же самого физического диска, но уже реальным железом.

Виртуалка сразу грузится со своего единственного диска, в конфиге/vmx прописано firmware=«efi». Загрузка с реального железа была запущена из меню биоса/efi кликом по жесткому диску, с которого нужно грузиться, потом управление как и положено перешло Grub'у (который начал грузиться нормальным образом, но потом отрапортовал что не видит ведра).

Какая очерёдность опроса дисков и с какого грузится система ?

Виртуалке доступен только один, и он же первый, диск. На реальном железе этот диск идет третьим на SATA-контроллере (и в windows определяется как \\.\PhysicalDrive3, что весьма удобно). Физически диск сейчас размечен как efi-кусок в несколько сотен мегабайт, и потом LVM на все оставшиеся 600 гигабайт, из которых первые несколько сотен гигабайт - своп, остальное - корневой раздел убунты.

В каком режиме работал контроллер в виртуальной системе ?

вначале пробовал в режиме SCSI (рекомендованный), потом в режиме IDE. В режиме SATA физический диск не создается, это известный неисправленный баг. На реальном железе контроллер работает в SATA3 AHCI.

это что-то вам напоминает?

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от reprimand

они временами отличаются, но все про то, что не работает этот конкретный интерфейс до физического диска. Если его убрать, то всё ОК. Поверхностный мемтест проходит, кстати.

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

...
Загрузка с реального железа была запущена из меню биоса/efi кликом по жесткому диску, с которого нужно грузиться, потом управление как и положено перешло Grub'у (который начал грузиться нормальным образом, но потом отрапортовал что не видит ведра).

Это нормально, потому, что:

Виртуалке доступен только один, и он же первый, диск. На реальном железе этот диск идет третьим на SATA-контроллере

в конфиге grub2 перед чтением файлов с ядром и initramfs указано что-то вроде:

set root=(hd0,1)
Но при загрузке с реального железа этот диск уже третий (hd2), а не первый (hd0), читайте документацию по grub2, там была какая-то директива, что-то вроде search, которая позволяла выставлять корень (set root=(hd0,1)), раздел, откуда будут считываться загрузчиком образ ядра и initramfs, если на этом разделе найден определённый файл. Подсказать более точно не могу, т.к. сам использую grub-0.97.

С другой стороны вы можете подключить диск с Ubuntu на первый канал sata контроллера, что бы он был hd0.

Ну и даже после того как вы разберётесь как заставить grub2 определять раздел думаю у вас, возможно, будут некоторые проблемы с монтированием корневой файловой системы, вот из-за этого:

вначале пробовал в режиме SCSI (рекомендованный), потом в режиме IDE. В режиме SATA физический диск не создается, это известный неисправленный баг. На реальном железе контроллер работает в SATA3 AHCI.

Но это решается добавлением в initramfs соответствующих модулей (драйверов), а возможно и не будет проблем.

UPD:
Либо можете попробовать вообще убрать (закомментировать) директиву 'set root=(hd0,1)' из конфига grub2 и попробовать загрузиться.

kostik87 ★★★★★
()
Последнее исправление: kostik87 (всего исправлений: 1)
Ответ на: комментарий от kostik87

так проблема пока даже не в гробе! Как настроить его - разберемся, это дело десятое!

Проблема в том, что после той памятной перезагрузки в реальное железо, в vmware вылезают internal errors при обращении к диску!

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

А вот это не знаю, выложите тогда весь лог dmesg на pastebin сервис, а сюда ссылку. А то так говорить не о чем.

kostik87 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.