Ubuntu/Mint/Kali загружается в initramfs BusyBox (РЕШЕНО)
В этой статье мы покажем, как решить проблемы, которые возникают, когда компьютер под управлением Ubuntu, Mint Linux или Kali Linux не загружается и во время инициализации initramfs появляется только приглашение busybox. В этой ситуации возможно получить доступ и использовать только командную строку initramfs.
initramfs — это исходная файловая система на основе tmpfs в ОЗУ, которая не использует отдельное блочное устройство. Как и initrd, она содержит инструменты и сценарии для монтирования файловых систем до вызова init, расположенного в корневой файловой системе.
Восстановление неработающего суперблока Ext4 в Linux
Если Ubuntu вылетает в busybox во время инициализации initramfs, возможно, на диске повреждён суперблок.
Несколько копий суперблока хранятся в Linux. Чтобы восстановить систему в случае возникновения этой проблемы, вам необходимо загрузиться с аварийного образа/диска Live CD и запустить терминал. После загрузки введите в терминал следующую команду:
Команда возвращает информацию о вашем томе:
Запомните имя тома и укажите его в следующей команде:
Команда покажет список резервных суперблоков:
Мы воспользуемся вторым резервным суперблоком для замены повреждённого (можно использовать любой суперблок, кроме первичного). Проверьте диск с помощью резервного суперблока:
Если вы получите такой результат:
После успешной замены суперблока вы получите такое сообщение:
Затем отключите загрузочный носитель и перезагрузите компьютер. Все должно работать исправно.
Fsck Boot Error: Unexpected Inconsistency
Второй вариант проблемы initramfs (BusyBox) включает следующее сообщение в окне терминала:
Если вы его не видите, попробуйте ввести в (initramfs)
в окне терминала. Ошибка может появиться после того, как вы это сделаете.
В сообщении будет показан том, на котором требуется выполнить ручную проверку диска. Выполните следующую команду в приглашении initramfs:
После завершения проверки диска перезагрузите компьютер и убедитесь, что Linux загружается правильно.
Alert! /dev/ТОМ Does Not Exist
Проблема с Fstab
При загрузке хоста Linux вы можете увидеть следующую ошибку:
Возможно, вы только что установили Linux или у вашего хоста возникли проблемы с fstab. Чаще всего проблема возникает при установке системы с USB-накопителя. Система может показывать ошибку любого тома. Как и в первом случае, мы должны загрузиться с загрузочного / аварийного носителя Linux и выполнить некоторые действия. Проверьте UUID диска с помощью этой команды:
Система вернёт примерно следующее:
Здесь мы видим, что система должна загружаться с sda2, но на самом деле она пытается загрузиться с sda1.
Смонтируйте том в любой каталог, например:
Когда вы увидите /dev/sda2 в каталоге /mnt, найдите там файл /etc/fstab и измените строку, содержащую /dev/sda1, следующим образом:
Сохраните файл. Отмонтируйте том от /mnt и перезагрузитесь. Если проблема связана с неправильным именем тома, сервер загрузится.
Также вы можете решить эту проблему, загрузившись в аварийном режиме. Перемонтируйте корневой каталог как чтение / запись:
Затем измените fstab и перезапустите сервер.
Аппаратная проблема
На некоторых материнских платах порты SATA могут иметь случайные числа. Это также может вызвать ошибку, описанную в предыдущем разделе. Чтобы исправить это, вы должны отредактировать загрузчик grub.
Загрузитесь в аварийном режиме или с Live CD и отредактируйте файл /boot/grub/grub.cfg.
В строке, определяющей загрузочный раздел, например:
Восстанавливаем свалившийся в busybox из-за ошибки initramfs Linux
Недавно при включении компьютера, Ubuntu меня «порадовала» тем, что решила не загружаться и «свалилась» в busybox в момент инициализации пользовательского пространства (userspace) оно же initramfs. Немного ошарашенный начал разбираться. Оказалось, что мой старенький жёсткий диск дал небольшой сбой, и подпортил суперблок файловой системы. Впрочем, оказалось что это не смертельно, и проблема эта, довольно просто и быстро решается.
Перед тем, как продолжить, я должен предупредить, что не обязательна причина в суперблоке. Такая проблема может возникать и по другим причинам, установить которые можно только имея определенный опыт, либо опытным путем. В любом случае, вся суть проводимых ниже действия, лишь в проверке диска на ошибки, поэтому как минимум ничем не повредит.
Для восстановления нам понадобится загрузочный диск или флэшка с Linux. Загружаемся, и запускаем терминал. В терминале пишем:
В результате выполнения команды, будет выведен список всех разделов:
В моем случае это был один раздел. В этом списке нужно найти нужный раздел, и запомнить его. Он понадобится нам дальше. Далее посмотрим список доступных запасных суперблоков:
В команде выше, /dev/sda2 необходимо заменить на полученный ранее, нужный раздел. В результате выполнения команды, будет выведен список всех суперблоков:
Из списка запасных суперблоков, выбираем любой кроме Primary и запускаем проверку диска с указанием запасного суперблока:
После этого перезагружаемся, отключаем флэшку/вынимаем диск из привода, и всё должно работать. 🙂
Восстановление файловой системы. Help plz. 0
GNU/Linux, UNIX, Open Source → *BSD и другие системы
Помогите плз! короче что я сделал:
но фигня в том что /home находится на /dev/hda4, когда он начал резервное копирование я прервал процесс, потом папка home оказалась пуста, а при следующей загрузке linux выдает и надо чето вводить
[repair filesystem #1]
Можно ли как нить восстановить все?
Только не спрашивайте зачем я это наделал…
что означает и можно ли это както исправить?
mount: wrong fs type, bad option, bad superblock on /dev/hda4,
or too many mounted file systems
# This file is edited by fstab-sync — see ‘man fstab-sync’ for details
LABEL=/ / ext3 defaults 1 1
none /dev/pts devpts gid=5,mode=620 0 0
none /dev/shm tmpfs defaults 0 0
LABEL=/home /home ext3 defaults 1 2
none /proc proc defaults 0 0
none /sys sysfs defaults 0 0
/dev/hda1 /mnt/disk_c vfat codepage=866,iocharset=utf8,umask=000 0 0
/dev/hda2 /mnt/disk_e vfat codepage=866,iocharset=utf8,umask=000 0 0
/dev/hdb1 /mnt/disk_d vfat codepage=866,iocharset=utf8,umask=000 0 0
/dev/hdb2 /mnt/disk_f vfat codepage=866,iocharset=utf8,umask=022 0 0
/dev/hdc /media/cdrecorder auto pamconsole,fscontext=system_u:object_r:removable_t,exec,noauto,managed 0 0
/dev/fd0 /media/floppy1 auto pamconsole,fscontext=system_u:object_r:removable_t,exec,noauto,managed 0 0
Ну запорчен суперблок, чего паниковать то.
Возьми да восстанови.
Копия суперблока находится в начале каждого 8-килобайтного блока на диске (Для файловых систем с размером блока в 1 килобайт, а твоя как раз такова)
Поэтому для воостановления:
Если не получается то тогда
и так далее, пока наконец не найдешь неповрежденную копию суперблока.
P.S. Только сперва, конечно, отмонтируй диск, если он прионтирован.
вот что получилось, но всеравно чтото не работает…
e2fsck 1.35 (28-Feb-2004)
Superblock has a bad ext3 journal (inode 8).
* ext3 journal has been deleted — filesystem is now ext2 only *
Superblock doesn’t have has_journal flag, but has ext3 journal inode.
/home was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (0, counted=32071).
Free blocks count wrong for group #1 (0, counted=32074).
Free blocks count wrong for group #2 (0, counted=32259).
Free blocks count wrong for group #3 (0, counted=32076).
Free blocks count wrong for group #4 (25832, counted=31915).
Free blocks count wrong for group #6 (3131, counted=3123).
Free blocks count wrong for group #7 (11865, counted=19418).
Free blocks count wrong for group #8 (34, counted=32213).
Free blocks count wrong for group #9 (26995, counted=21990).
Free blocks count wrong for group #16 (24329, counted=24330).
Free blocks count wrong for group #17 (0, counted=10).
Free blocks count wrong for group #18 (0, counted=3).
Free blocks count wrong for group #19 (0, counted=10).
Free blocks count wrong for group #20 (0, counted=59).
Free blocks count wrong for group #21 (0, counted=16727).
Free blocks count wrong for group #22 (0, counted=23591).
Free blocks count wrong (173553, counted=383236).
Free inodes count wrong for group #5 (15284, counted=15278).
Directories count wrong for group #5 (128, counted=132).
Free inodes count wrong for group #6 (15886, counted=15881).
Free inodes count wrong for group #9 (15917, counted=15503).
Directories count wrong for group #9 (32, counted=65).
Free inodes count wrong for group #16 (16219, counted=16220).
Free inodes count wrong (371373, counted=370949).
/home: *** FILE SYSTEM WAS MODIFIED ***
/home: 2203/373152 files (2.2% non-contiguous), 361778/745014 blocks
mount: wrong fs type, bad option, bad superblock on /dev/hda4,
or too many mounted file systems
я чтото не понял как узнавать числа для суперблоков и как много их так подставлять, потомучто 8193 и 16385 не подходят, пишет:
e2fsck 1.35 (28-Feb-2004)
e2fsck: Bad magic number in super-block while trying to open /dev/hda4
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
dis123
я чтото не понял как узнавать числа для суперблоков и как много их так подставлять, потомучто 8193 и 16385 не подходят
значит так, небольшой ликбез, ext2 может иметь мноого резервных копий суперблока. Но чтобы зря не тратить драгоценное место на hd, этих копий создаётся несколько штук, ну, например 10. Эти копии создаются программкой mke2fs в момент создания фс, и они разбросаны по диску.
а теперь man e2fsck про опцию `-b’
Additional backup superblocks can be determined by using the
ifies blocksize of the filesystem must be specified in order for
the superblock locations that are printed out to be accurate.
If an alternative superblock is specified and the filesystem is
not opened read-only, e2fsck will make sure that the primary
superblock is updated appropriately upon completion of the
как видишь в последней строке написано где mke2fs создала бы суперблоки, если бы ей пришлось создавать фс, на данном разделе (можешь подробнее почитать об этом в man mke2fs).
Теперь твоя задача взять, последний (в данном примере 2654208) и дать e2fsck в качестве копии суперблока. Последний потому что, тк ты затирал с начала, то у него меньше всего шансов быть убитым.
Исправление загрузки в initramfs при запуске Ubuntu
initramfs — файловая система оперативной памяти, которая используется для начального запуска операционных систем на базе ядра Linux. При установке ОС все библиотеки, утилиты и конфигурационные файлы сжимаются в архив, после чего передаются указанной файловой системой в загрузчик, где и продолжается старт системы. Иногда пользователи дистрибутива Ubuntu сталкиваются с тем, что при включении компьютера они попадают в консоль управления именно этой ФС без возможности дальнейшей загрузки системы. Связано это с повреждением потока запуска и восстанавливается достаточно простым методом.
Исправляем ошибку с загрузкой в initramfs при запуске Ubuntu
В большинстве случаев рассматриваемая проблема связана со сбоем в одном из суперблоков, и при попытке выхода из initramfs через команду exit появляется надпись следующего содержания:
При возникновении подобной ситуации лучшим методом исправления проблему будет восстановление работы суперблока, а сделать это можно следующим образом:
Благодаря опции -y все изменения будут автоматически приниматься, и при успешном завершении процесса на экране отобразится следующее уведомление:
Иногда даже после успешного исправления рассмотренной проблемы юзеры сталкиваются с ошибками при запуске операционной системы. Чаще всего они связаны с поломкой стандартного загрузчика GRUB. Поэтому придется дополнительно восстановить и этот стандартный компонент. Развернутое руководство о том, как выполняется поставленная задача через Boot-Repair, ищите в материале далее.
По завершении всех процедур флешка с LiveCD Ubuntu вам больше не понадобится. Если возникло желание ее отформатировать и использовать далее для своих целей, советуем ознакомиться с отдельной нашей статьей по проведению этой операции.
Сегодня мы рассказали о самом популярном решении неполадки с загрузкой в initramfs, однако это не означает, что приведенный способ является универсальным. В случае возникновения ошибки другого характера опишите ее в комментариях, а мы постараемся предоставить правильное решение этой ситуации.
Помимо этой статьи, на сайте еще 12482 инструкций.
Добавьте сайт Lumpics.ru в закладки (CTRL+D) и мы точно еще пригодимся вам.
Отблагодарите автора, поделитесь статьей в социальных сетях.
Ext3, вырубили свет, и хотя записи в этот момент небыло, результат:
После первого фикса оно «исправило» файл, что debugfs (14910443: File not found by ext2_lookup) его не видит, до кучи хочет исправить битмап (какой из?), а числом чего сказать хотело? Это хоть в каких величинах?
Никогда на такую ошибку не попадал, но помня о приоритете консистентности FS не обнулит ли оно сотню-другую файлов?
Это fsck на монтированную или нет fs?
Конечно демонтированную (точнее, немонтированную после сбоя питания)
сделай бэкап, прогони fsck, сделай diff.
Я так понимаю он построил битмап занятости блоков обойдя все файлы и сравнил с тем что записано в суперблоке(или где там битмап хранится). После этого он предлагает исправить суперблок. Если я прав то эта ошибка влияет только на summary information а не на контент. И если не исправишь ОС может записать в те блоки которые помечены как свободные, но на самом деле какой-то файл их занимает.
> Словил я когда-то и такую, и множество аналогичных, и вообще неведомых науке ошибок за один проход. После чего перешёл на ext3.
fxd.
от себя добавлю, что рейзер я пробовал многократно, и каждый раз он у меня херил раздел. больше всего убивало, что при загрузке ждешь пару часов пока оно там что-то пилит, и потом узнаешь что половину файлов с раздела как ##ем сдуло.
а с ext3 на том винте вообще проблем не было.
в который раз узнаю, что ФС, работающая нормально на определенном компе определяется задолго до рождения^Wпокупки компа. у меня за несколько лет использования сыпалась ехт3 и ни разу не сбойнула reiser3.6 даже после зверских испытаний джамшутами^Wэлектриками, которые включали-выключали свет.
Емнип, там еще битмап инод есть, если предположить, что после обхода по всему дереву ФС он исправил элемент дерева, то потом получим кучу инод, которые якобы не заняты, а это уже не только саммари-информейшен.
Я конечно уже исправил, но просто хотелось узнать что за зверюка такая
/dev/sdb4: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb4: 93390/31047680 files (21.2% non-contiguous), 58794796/62077168 blocks
Скоро будет дефрагментацию форматированием делать, а то уже заметно тормозит.
Уважаемый, юзайте reiserfs и не парьте себе мозг.
тут уже много про рейзер сказали, а каким образом он лучше? У него fsck вопросов не задаёт? 🙂
узнаем только если разрабов спросим, я сырцы fsck.ext3 не распарсил.
В плане топика, ниаким. Как обычно, советуют своё сексуальное пристрастие под видом объективности.
Если я раньше правильно понял исходник e2fsck и правильно помню, то, что понял, то «-37032557» означает, что блок номер 37032557 не принадлежит какому-либо файлу (свободный), но в bitmap’е свободных блоков он не значится.
не обнулит ли оно сотню-другую файлов?
Вроде только один блок. Кучи файлов быть не должно, в смысле не должно быть удалено.
debugfs (14910443: File not found by ext2_lookup) его не видит
Это номер инода, вы делали «stat » или «ncheck 14910443»?
Кстати, как с точки зрения системного администратора лучше анализировать исходники?
apt-get source и далее ack-grep по коду ошибки или как? Интересуюсь именно на что стоит обращать внимание? И для чего, собственно, зативается весь source diving? Как последняя стадия нахождения бага/ошибки или для лучшего понимания работы программы?
тут уже много про рейзер сказали, а каким образом он лучше? У него fsck вопросов не задаёт? 🙂
пугает меня минус перед номером инода. Может там signed с unsigned перепуталось в выводе?
> Вроде только один блок. Кучи файлов быть не должно, в смысле не должно быть удалено.
Когда-то я игрался с системными записями NTFS (виртуалка, раздел на 200 метров и perl-скрипт для патчинга), то при ошибках в _битмапе_ оно часто любило гробить data-extents у файлов при первой же проверке, после чего все файлы на месте и имеют размер в 0 байт. Но это было давно и в венде, однако страх перед битмапами остался. Особенно страшно то, что тут каким-то образом появилось signed int, сразу вспомнился LBA48 и много других приколов.
Это номер инода, вы делали «stat » или «ncheck 14910443»?
Особенно неприятно, если эта инода отвечала за директорию, у меня много директорий с 100000 файлов внутри, но вроде больше ошибок небыло
Оно не могло не найти иноду. Количество инодов заданно при создании ФС, и не меняется. Инод всегда есть, просто он может быть свободным. Ошибка «File not found by ext2_lookup» должна возникнуть когда вы делали «dump 14910443 FileName». То есть просили сдампить файл с именем 14910443, а не инод.
Спасибо, буду иметь в виду, я думал под filespec подразумевается инода, как и у других команд
Там не номер инода, а номер блока. Знак «плюс/минус» обозначает характер ошибки: «блок занят, но в битмапе числится свободым» / «блок свободен, но в битмапе числится занятым».
P.S. Пишу всё по памяти, если есть кто-то, знающий e2fsck, пусть поправит.
filespec это или имя файла или номер инода, заключённый в <>.
