Arch Восстановление ядра. Кажеца стало хуже.

Машинописный обратный апостроф находится на клавише с Ё — нужно использовать его, а не одинарную верхнюю кавычку, как ты.

Ребутнул комп во время обновления

Отличная идея.

загрузился, примонтировал раздел. arch-chroot /mnt падало с ошибкой ‘mount point doesn’t exist’

А ты в /mnt примонтировал?

pacstrap /mnt base linux linux-firmware

команда pacstrap если я правильно понял, создало новую оболучку и теперь при вызову чрут это не имеет отношения к моей текущей системе

Почти верно. Ты поставил новый экземпляр в /mnt, который у тебя никуда не смонтирован. То есть в пустоту.

Советую:

• Подключить внешний диск, на него сбросить нужные тебе файлы
• Поставить Fedora: https://fedoraproject.org/ru/workstation/download
• Поставить на неё ASUS Linux: https://asus-linux.org/guides/fedora-guide/

Нет, восстановить твой Arch конечно можно, но сам ты явно не справишься, а информации чтобы дать тебе точный порядок команд ты не дал.

Да примонтировал я его конечно в mnt. Коммандой mount /dev/nvme0n1p2 /mnt.

За совет спасиб, но там у меня тайловый менеджер, виртуальная машина и много всего другого, к чему я привык, поэтому хотелось бы спасти это. Какую инфу нужно дать, все скажу.

Сори за ковычки, пишу с планшета. Они тут полюбому тоже есть, пока не нашел)

В Арче есть же 2 ядра в репозитории - kernel и kernel-lts.

Проблемы с одним - грузишься со вторым и чинишься.

Во всех нормальных дистрах (Red Hat, Debian) по умолчанию 2-3 ядра, как раз для подобных случаев.

Читай внимательнее. Он перезагрузил ОС во время обновления. Соответсвенно, тут нужно:

• Прочекать ФС
• Составить список установленных пакетов, если возможно
• Заново поставить их все, так как какие побились — непонятно

И это только известные проблемы, может ещё что-то вылезти, особенно если он не дай бог btrfs использовал — если она сломалась, придется вместо спасения ФС думать, как спасти хотя бы данные.

а зачем кастомное?

# монтируем корень
mount /dev/sdXN /mnt

# делаем chroot (change root)
arch-chroot /mnt

# внутри уже
mount -a

# переустанавливаем

Ну конечно я использовал btrfs) Да блин, с файлами у меня все впорядке. Я могу зайти в домашнюю дирикторию, все на месте. Я получаю ошибку что не найдено ядро во время загрузки grab. И проблема как мне кажется именно я ядром.

Ну можешь сделать фото экрана с выводом команд от root:

fdisk -l
lsblk
lsblk -f
blkid -c /dev/null
ls -ld /sys/firmware/efi
efibootmgr -v

Это только для начала, потом ещё дофига чего потребуется… выложить их на файлообменник, сюда ссылку.

И я не уверен, что у меня хватит мотивации тебя через это провести. И даже знаний тоже, так как именно с Arch я мало работал.

Ты устроил очень серьезную аварию: Arch Восстановление ядра. Кажеца стало хуже. (комментарий)

Ну конечно я использовал btrfs) Да блин, с файлами у меня все впорядке.

Структура btrfs могла пострадать после отключения по питанию. Есть риск, что при дальнейшей работе она выродится, даже если сейчас относительно исправна. А средства починки btrfs, которые не имеют риска её добить, не существуют в природе.

Сбрасывай пока не поздно данные на внешний диск и ставь Fedora (желательно для гибкости на LVM (нужен отдельный /boot в 2 гига и /boot/efi в пол-гига)) с ext4 или XFS, если нужны reflink (но XFS нельзя сжимать).

Структура btrfs могла пострадать после отключения по питанию.

Она не может пострадать. Там данные пишутся в новое место постоянно [↗] (btrfs.readthedocs.io). При аварийном отключении просто ошибка чексум может возникнуть (невсегда, она не ломается как правило просто при отключении). Для лечения достаточно вызвать scrub, и лишь в исключительных случаях чинить…

Для начала нужно, конечно, проверить есть ли оные:

btrfsck --check --force <mountpoint>

после arch-chroot надо сделать mkinitcpio -p <профиль-для-твоего-ядра>

ну или пакманом переставь ядро, он должен сам пересобрать initcpio

и систему надо дообновить

https://btrfs.readthedocs.io/en/latest/btrfs-check.html

https://btrfs.readthedocs.io/en/latest/Scrub.html

Хм, Btrfs стала лучше в плане восстановления. Ранее была вообще жопа.

Фух, спецоперация завершилась успехом, через заднее место навреное, но сам результат)

Я не знаю как и почему, но на моем загрузочном разделе почему то пропали образы ядра, а именно файлы initramfs-linux-g14.img, vmlinuz-linux-g14

Как я понял, коммандой pacstrap /mnt base linux linux-firmware я поставил новый образ системы в раздел /mnt.

Потом я командой mount /dev/... /mnt примонтировал уже мою файловую систему. Командой arch-chroot я попал в систему, только не в свою, а во вновь поставленный образ. Потом в этот образ я поставил нужное ядро, и скопировал недостающие файлы с папки boot в папку boot своей системы.

На сколько я понял, командой arch-chroot /mnt я должен был попасть в свою систему, которую нужно восстановить и там запустив пересборку ядра, проблема бы решилась, но у меня появлялась ошибка mount point doesn't exist и командой pacstrap /mnt base linux linux-firmware я накатил паралельный образ системы из которого потом и работал через arch-chroot /mnt.

Единственное что мне не понятно, почему изначально этот порядок
mount /dev/... /mnt
arch-chroot /mnt

Падал с ошибкой
mount point doesn't exist

Всем причастным, огроменное спасибо!)

Перед arch-chroot /mnt, ты должен смонтировать корень в /mnt, а после (чрута) выполнить mount -a, чтобы смонитровать все остальное

Так у меня и была такая последовательность.
mount /dev/nvm /mnt

А потому уже делал чрут на /mnt

Что не так?

нужно было чрут сделать (если смонтировал, как утверждаешь), а потом mount -a, а затем, например, переустановить ядро (внутри чрута)

btrfsck --check

Эта та команда которая ломает бтрфс? Или ломает --repair?

с --repair у кого-то что-то тут сломало году так в 2018 (на моей памяти)… это еще когда бутерброд место сжирал, и отдавать обратно не хотел

А да, --repair, помню что-то подлое было.

зачрутиться и восстановиться это как два пальца обоссать, но тут какое то btrfs по этому даже не знаю