Я новичок в Linux, и единственная причина, по которой я его установил, - это избавиться от проблем несовместимости Windows с Ruby on Rails. Сказав это, это определенно было приятно и намного быстрее, и я не думаю, что в ближайшее время буду делать что-нибудь с Winrails.
Итак, я создал виртуальную машину с помощью virtualbox, и последние 3 недели я использовал Ubuntu. Недавно ubuntu спросил, можно ли обновить кое-что, я нажал «ОК».
Теперь он не загружается, и я получаю эту ошибку: * mount: монтирование / dev в / root / dev failed: Нет такого файла или каталога mount: mount / sys on / root / sys failed: Нет такого файла или каталога ... В целевой файловой системе нет / sbin / init. Не найдено ни одной инициализации. Попробуйте передать init = bootarg
BusyBox v1.13.3 ...
(initramfs) _ *
Итак, я прошелся по форумам и нашел множество решений, но все они связаны с загрузкой с живого компакт-диска. (который, как я предполагаю, является ISO-образом, который я использовал в первую очередь для установки ubuntu). Но когда я загружаюсь с этого компакт-диска, он просто зависает на экране ubuntu, и маленькие точки продолжают меняться с белого на красный, но он висел там в течение часа, поэтому я думаю, что он застрял. Не уверен, что я могу сделать; могу ли я сделать что-нибудь из оболочки busybox (или чего-то еще), чтобы исправить ситуацию?
Дело в том, что мне потребовалось около 10 часов, чтобы получить все необходимое, со всеми драгоценностями и прочим. И я действительно не записывал, что я настраивал, а я средний возраст, поэтому вся эта информация просочилась, и я не хочу делать это снова. Я действительно хотел бы исправить существующую установку.
У вас может возникнуть вопрос: что-то не так с ISO? Я так не думаю, потому что я создал новую виртуальную машину и использовал тот же самый iso-файл для установки нового Ubuntu.
Любая помощь очень ценится.
Фил
У меня было что-то подобное - хост Ubuntu 10.10 с гостевым Ubuntu 10.10.
Гостевая FS была повреждена и привела к той же ошибке, что и выше.
Это было решено путем монтирования разделов из файла vdi и запуска их проверки.
sudo vdfuse -g -f /media/ssdext4/UbuntuGuest.vdi / mnt /
Теперь вы должны иметь возможность вывести список разделов из файла vdi с помощью "sudo ls -l / mnt /"
Теперь запустите проверку FS - с полным путем. sudo fsck.ext4 / mnt / Partition1
Я думаю, что vdfuse должен быть частью установки по умолчанию. Я не вижу, как исправить эти проблемы, если у вас нет vdfuse.
В приглашении загрузчика все выглядит нормально. Поэтому я опасаюсь, что файловая система повреждена.
Я предлагаю следующий процесс:
etckeeper пакет и запустить etckeeper init. Это поставит /etc под контролем версий. Если у вас есть любимый инструмент контроля версий среди Bazaar, Darcs, Git и Mercury, выберите его в /etc/etckeeper/etckeeper.conf перед запуском etckeeper commit./etc будет автоматически фиксироваться до и после задач управления пакетами, а также один раз в день. Вы можете выполнить фиксацию вручную, запустив etckeeper commit или вызывая непосредственно базовый инструмент контроля версий./dev/sdb2. Если вам будет предложено запустить fsck, Сделай так./etc, а также все, что вы могли бы сделать в /usr/local и /home на виртуальной машине в настройках резервного копирования.Не самый сложный, но, возможно, самый быстрый подход: добавьте образ диска со сломанной виртуальной машины на недавно установленную, смонтируйте его оттуда, скопируйте свой $ HOME, / etc и, возможно, что-нибудь из / var / {lib, db, .. .} (или, по крайней мере, сохраните копию), и вы должны вернуться к работе менее чем за час.
Я предполагаю, что настоящая проблема вызвана тем, что начальный RAM-диск не может правильно обнаружить и смонтировать виртуальное дисковое устройство. Итак, что вы также можете попробовать, если вам каким-то образом удастся получить доступ к файловой системе сломанной виртуальной машины, это что-то вроде:
mount /dev/sdbroken1 /mnt/brokendisk
for i in dev dev/pts proc sys; do
mount --bind /$i /mnt/brokendisk/$i
done
chroot /mnt/brokendisk
update-initramfs -u -k all # regenerate initial ramdisk - look for errors
^D
reboot
Может что-то не так с обновленным ядром. Попробуйте загрузить предыдущее ядро (оно все еще должно быть). Когда вы увидите экран загрузки виртуального бокса на синем фоне, нажмите и удерживайте сдвиг. Через несколько секунд должно появиться меню загрузчика.
linux линию, сотрите ту часть, которая выглядит как -2.6.32-24-generic и нажмите Вкладка чтобы увидеть, какие еще ядра существуют (/boot/vmlinuz-*). Также выберите соответствие initrd ниже.root= установка на linux линия. При установке по умолчанию (без другой ОС внутри виртуальной машины), root=/dev/sda1 должно сработать.Если ничего из этого не работает, но вы видите интересные сообщения об ошибках по пути или по мере необходимости, разместите их здесь. В зависимости от того, в чем проблема, может помочь увидеть вывод команды ls /boot при вводе в командной строке Grub.
У меня точно такая же проблема; включая странное поведение с живым iso.
Оказывается, проблема в том, что grub каким-то образом испортил - возможно, из-за того, что хост-система засыпает [я говорю это, потому что Кристис Бергелес описывает ту же проблему, что и я, с тем же хостом (Mac OSX) в http://christos.bergeles.net/blog/files/tag-grub.html]
Прикрепите проблемный виртуальный HD к другой работающей виртуальной машине ubuntu.
Загрузитесь в эту виртуальную машину
(в следующих двух строках предполагается, что у этой виртуальной машины есть проблемный диск в / dev / sdb)
sudo mount / dev / sdb1 / mnt
sudo grub-install --root-directory = / mnt / / dev / sda
у меня работал - на двух отдельных экземплярах этой проблемы.
Тим.