Error unknown filesystem grub rescue proxmox - Исправление ошибок и поиск оптимальных решений проблем

Hello,

I have a proxmox (v5.4 I think) machine installed on ZFS, including the root filesystem. Then, quoting proxmox wiki, it should have been installed with systemd-boot instead of grub2.

Proxmox VE currently uses one of two bootloaders depending on the disk setup selected in the installer. For EFI Systems installed with ZFS as the root filesystem systemd-boot is used. All other deployments use the standard grub bootloader.

The thing is that the machine has grub2 (don’t know why, I have inherited it like that) and after change to dondesize = auto, on the next reboot grub has been unable to read the disks.

Code:

error: no such device: 40d7d14f38cc...
error: unknown filesystem
Entering rescue mode...
grub rescue>

As you can see here it’s a known issue.

How I can delete grub2 and install and configure systemd-boot to boot from the already existant rpool?

Thanks for your time, best regards,

H25E

H4R0

Well-Known Member

Grub gets installed as fallback.

systemd-boot is used in efi mode, grub for legacy boot.

It’s a bios setting, select uefi/efi boot mode instead of legacy.

Didn’t know that grub was installed as fallback, but on the bios Storage Boot Option Control = UEFI and Other PCI devices = UEFI.

What more I can do? For me seems that systemd-boot isn’t installed. How can I check if it is?

H4R0

Well-Known Member

That’s odd.

Proxmox dosn’t keep /boot/efi mounted after boot.

But «efibootmgr -v» should list the efi entries if they exist.

Should print the disk gpt partition id like:

Code:

Boot0000* Linux Boot Manager    HD(2,GPT,XXXXXX-XXXX-XXXX-XXXX-XXXXXXXX,0x800,0x100000)/File(EFIsystemdsystemd-bootx64.efi)

You can rewrite the efi bootloader with «pve-efiboot-tool refresh»

Yes, it’s strange.

If I disable CMS on the bios the system doesn’t boot. Instead, it opens BIOS again. If I order to exit without saving it restarts and opens BIOS again. And that’s it.

With CMS enabled and Storage Boot Option Control = UEFI on BIOS settings I have the GRUB error. So I can’t boot into the system to run efibootmgr.

I ran into the dondesize=auto problem some time ago and know how it feels. At the time, there was no systemd boot support at all…

Does your UEFI support selecting the boot device when starting? Do you see two options for each disk (one UEFI and one Legacy or Linux Boot Manager or something)?
If there are UEFI entries, try them and run pve-efiboot-tool refresh after booting from UEFI. I don’t think it can set the boot entry when booting with GRUB.
Does the drive have a GPT or only an MBR? To be able to boot using systemd you need an ESP partition and use GPT.

Thanks for thje empathy hehe…

In the UEFI settings it’s selecected CSM Support = ENABLED. Is like it has been all the time. (CSM suppor means BIOS/Legacy support mode). Like that the system was booting before the dnode problem and now brings to the GRUB error.

Now, if I change to CSM Support = DISABLE the system reboots continously and access UEFI automatically without booting into anything. What does this mean?

So I suspect that this isn’t an UEFI installation… (Wasn’t installed by me). But if I don’t remember bad, I think there were EFI partitions… I also believe that disks are GPT, but don’t know how to check right now from UEFI.

Anyway, I have installed same proxmox version into a pendrive and I’m going to boot from it and rewrite the rpool partition. I think it’s risky but don’t know what other thing to do.

What would you do?

Now, if I change to CSM Support = DISABLE the system reboots continously and access UEFI automatically without booting into anything. What does this mean?

It would appear that booting from UEFI is not setup correctly on your disks.
Does your UEFI have a hotkey to boot from another device (CD or pendrive or such)? Does it give you any options?

So I suspect that this isn’t an UEFI installation… (Wasn’t installed by me). But if I don’t remember bad, I think there were EFI partitions… I also believe that disks are GPT, but don’t know how to check right now from UEFI.

You could try booting a Linux Live CD/USB to check. Ubuntu Desktop 20.04 installation ISO can boot you into a desktop and has ZFS support.

Anyway, I have installed same proxmox version into a pendrive and I’m going to boot from it and rewrite the rpool partition. I think it’s risky but don’t know what other thing to do.

What would you do?

I installed a fresh Proxmox on a pendrive and used that to boot. During the start Proxmox would get confused about the two rpools. I think I manually chose the rpool on hard disks and later renamed the rpool on the pendrive (which could still boot). Then I used to keep the pendrive in sync with my rpool (with was less than 15GB) and make the system boot from that. I think I only needed to sync the /boot directory, as that was all that GRUB needed to read before switching to the hard disk rpool.

In theory you could boot from the pendrive, update that rpool with the data from your hard disk rpool and then overwrite the hard disk partition with the pendrive. I decided that, once Proxmox supported booting off ZFS with UEFI, it was easier to reinstall (to use systemd-boot) and recover the VMs (from a different ZFS pool or from backup).

Given that you seem to have inherited an older Proxmox (without documentation), I would suggest try booting from pendrive once and see if it gets the original installation working (by choosing the hard disk rpool by number). That should give you an opportunity to backup and document everything safely.
And then do a new Proxmox 6.3 installation (on other hardware or disks, if possible, to prevent accidental erasure) and restore the VMs there.

I have booted with USB flash proxmox and confirmed that ins’t a UEFI installation. sda1 is a 1MB «bios boot» (literally fdisk type) partition, instead a 500MB UEFI one.

So, no option to bypass grub limitation booting from systemd-boot…

I think I’m going to copy all the rpool content to a second bigger pool that the server has, and then bring it back.

I know it would be cleaner to start with another server-disks and proxmox 6.3 but it’s not a good moment for do it now.

I have booted with USB flash proxmox and confirmed that ins’t a UEFI installation. sda1 is a 1MB «bios boot» (literally fdisk type) partition, instead a 500MB UEFI one.

If you install a new Proxmox withj UEFI and ZFS , it will also create a 1MB bios boot partition but also second a 512MB FAT32 ESP partition (sda2). I think fdisk does not detect GPT. Use gdisk instead of fdisk will show you if GPT is used.
If you have spare disk space, you could create a ZFS pool (with some name), copy/rsync rpool, remove the old rpool and rename the new pool to rpool. You do need to boot a LiveCD with ZFS support in order to remove or rename rpool.

I have done the same with gdisk and the outputs are the same. There is the bios partition but not the ESP.

I have enough spare disk space. But instead of rsync I have done the following (after changing dnodesize to legacy of course):

Code:

zfs snapshot rpool/ROOT/pve-1@grub-error
zfs send -Rv rpool/ROOT/pve-1@grub-error | zfs receive -F rpool/ROOT/pve-backup
zfs unmount rpool/ROOT/pve-1
zfs unmount rpool/ROOT/pve-backup
zfs destroy rpool/ROOT/pve-1@grub-error
zfs destroy rpool/ROOT/pve-backup@grub-error
zfs destroy rpool/ROOT/pve-1
zfs rename rpool/ROOT/pve-backup rpool/ROOT/pve-1
zfs set mountpoint =/ rpool/ROOT/pve-1

And nothing changed… Maybe the send/receive snapshot method hasn’t done a real rewrite of the files? And copied them with with the big dnodes?

EDIT: Did it with rsync with same results!!! … dissapointing.

The only other things that waste space on the pool are the few kb of the empties rpool, rpool/ROOT, rpool/data and some zvols. They where set to dnodesize auto also, but they are not real files! They can’t be the source of the problem, isn´t?.

Right now I have 0 idea of what to do next.

Last edited: Jan 2, 2021

ZFS send-receive duplicates the rpool including the dnodes that GRUB cannot handle (sorry for not warning you about this). I believe any other filesystem and zvol can cause dnodes of a different size to occur in the metadata of the rpool, and cause GRUB to fail to read. The irony is that there has been a fix for years but it is waiting on review and testing.

I think you need to create a fresh new pool on a new vdev and create a new ROOT, ROOT/pve-1 and data filesystem with the same settings as the old ones (except dnodesize). Copy the data from / to newpool/ROOT/pve-1 using cp -aR or rsync and then rename the old pool (to keep access to the zvols there) and rename the new pool to rpool. Boot Proxmox, add the old pool (with the new name) as a Storage, and then move the virtual disks over to the new rpool using the web GUI.
I hope this will help fix it, but I cannot guarantee that I did not forget any details.

You don’t have to say sorry. Thanks for your help and time.

I can’t add more disks to the system. (A modest server on consumer hardware with all sata ports used). But I have a bigger and secondary pool on the system, I can use it to copy everything from rpool to secondary-pool. Then completely delete all contents of rpool, (or maybe delete the pool itself and create it new) and finally bring back all the contents from secondary-pool to the new rpool and adjust names and mountpoints.

The problem is, how I copy the zvols from rpool to secondary-pool? The only methods I have found are send/receive and dd, and both would propagate the dnode problem. Import them from the webgui wouldn’t propagate the dnode properties? Why it’s different? Could I do a send/receive to secondary-pool and then import them with the GUI and dnode size will be changed to legacy¿

On the other hand, where it is stored the zvol metadata? Maybe we could rewrite only it like rpool/ROOT/pve-1?

There is also something strange. From the grub rescue console I can’t read neither the mirrored parition neither the BIOS parition.

The rpool is composed from two disks that they are printed like that with grub rescue> ls:
(hd0) (hd0,gpt9) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,gpt9) (hd1,gpt2) (hd1,gpt1) ...

gpt 9 is the solaris reserved, gpt2 the data partition and gpt1 the bios partition. Shouldn’t be gpt1 readable by grub? Or can it also be affected by dnodesize problem?

The first partition (1MB bios boot) contains the binary executable code of GRUB and is not readable as a filesystem, this is normal.

You need to rewrite all ZFS disk blocks without dnodesize=auto, which I believe is impossible. Therefore you need to create a fresh new rpool and copy everything there.
Maybe you can use the web GUI to move the virtual disks (zvols) stored on rpool to another pool on the machine (by booting from the pendrive as describe earlier)? If the rpool is all the storage you have on the machine, you cannot easily do that.

How about removing half of the raid1/mirror (let’s say hd1-gpt2), create a new ZFS pool (on hd1-gpt2, let’s say newpool) without dnodesize=auto, create new ROOT and ROOT/pve-1 and data (on newpool), copy everything from rpool/ROOT/pve-1 (to newpool/ROOT/pve-1), rename rpool to oldpool and rename newpool to rpool. In principle GRUB should be able to boot the new rpool and you can add oldpool as a Storage in the web GUI and move all virtual disks. If everything works, you can erase the oldpool and add the vdev (hd0-gpt2) to the new rpool as a mirror (and not as an extension! check command carefully). Maybe it is worth the risk to run without radi1 temporarily (run a zpool scrub rpool first!).

I would boot the old Proxmox using pendrive, make backups of all VMs and containters (to a directory on rpool) and run a scrub and remove all VMs and containers. Then remove one of the disks from the machine, wipe the other one and install Proxmox 6.3. on it with UEFI and systemd-boot Then add the other disk and restore the VMs and containers from backups (from the old rpool, which you need to import by another name). And them wipe the disk containing the old stuff and use it as a mirror again.

But as I said in my message 13 (that maybe you haven’t read because I double posted, sorry):

The problem is, how I copy the zvols from rpool to secondary-pool? The only methods I have found are send/receive and dd, and both would propagate the dnode problem. Import them from the webgui wouldn’t propagate the dnode properties? Why it’s different? Could I do a send/receive to secondary-pool and then import them with the GUI and dnode size will be changed to legacy¿

I mean, zvols can’t be rewrited with cp or rsync, they are moved as a block. If importing the zvols again to the new pool (with send/receive, dd or GUI) I propagate the old properties, the new pool will go unreadable again, isn’t?

Thanks for your patience.

But as I said in my message 13 (that maybe you haven’t read because I double posted, sorry):

I mean, zvols can’t be rewrited with cp or rsync, they are moved as a block. If importing the zvols again to the new pool (with send/receive, dd or GUI) I propagate the old properties, the new pool will go unreadable again, isn’t?

Thanks for your patience.

Good point! I think that when you use the move disk from the web GUI, but I am not sure. Making a backup and then restoring the VM on the new pool will work for sure.

It’s crazy.

I have deleted all datasets except the base rpool and still the same grub error message….

I’m going to do a fresh UEFI installation. Any advice to do an easier configuration of the new proxmox from the old one? I guess I can’t directly overwrite the /etc/pve folder with the older one.

The feature is still turned on (and cannot be disabled probably) and therefore GRUB cannot read/detect the rpool. As stated before, you need to create a fresh new pool.

My advice is to not use the whole disk for rpool but only 14GB or so (you can enter it in the installer). And to create an additional partition for a separate pool for the VMs.
I also advise to remove one of the hard disks and keep them for reference later and do a fresh install on the other disk drive.

I have done it this weekend and for the moment it’s working well.

Back up all the zfs datasets on rpool to a secondary pool, including ROOT/pve-1 (snapshot + send | receive works good for filesystem datasets and zvols)
Reinstalled proxmox to the lastest available version (with a smaller rpool, and creating a second zpool with the remaining space)
Bring back the backuped datasets (except ROOT/pve-1)
Take the vm/lxc configuration files from the backuped ROOT/pve-1, edit them to meet the new proxmox storages names if needed, and copy them to the new /etc/pve/qemu-server|lxc/

All this because I was mistaked and it was a BIOS/legacy installation, and systemd-boot was unavailable for me.

Thank you so much @avw and @H4R0 for your help.

Источник

Error: unknown filesystem.
grub rescue>

This was the nice error that greeted me when I tried to (re)boot my Proxmox server.
What unknown filesystem? The server was still supposed to boot from the same ZFS disk it always booted from.

TL;DR it was due to the large_dnode getting enabled on a dataset I had manually created. GRUB does not support that feature. Create a new dataset with that feature explicitly disabled, move the data to it, delete the original and rename the new one. Done.

Some background

Being space-constrained in my apartment, my Proxmox server is actually my everything server. It is my virtualization server, my router (it runs pfSense in a VM) and my NAS (it runs Samba in an LXC container).

For NAS duties, I decided a while back to create a dedicated dataset rpool/nas, which I then mounted in the Samba container. Without much thinking, I just ran a simple:

zfs create rpool/nas

Due to ZFS defaults, it had the feature dnodesize set to auto. It was never an issue, until the other day.

What happened

Some file must have triggered a non-legacy (512 bytes) dnode size in the dataset, which meant that GRUB could no longer read the drive.

I came to that conclusion by installing Proxmox in a VM on my Mac (with an ext4 boot drive, to avoid having to rename the pool), and attaching the server’s SSD through a SATA-USB adapter.

I changed the mountpoint of my server’s boot partition from / to /recovery, mounted /dev /sys and /proc in there and then chrooted into /recovery:

zfs set mountpoint=/recovery rpool/ROOT/pve-1
mount --rbind /dev /recovery/dev
mount --rbind /sys /recovery/sys
mount -t proc /proc /recovery/proc
chroot /recovery

I ran grub-probe -vvvv / to get some insight on why GRUB was failing and one line was interesting:

grub-core / fs / zfs / zfs.c: 2112: zap: name = org.zfsonlinux: large_dnode, value = 1, cd = 0

I read a bit online and I found out about the dnodesize thing. I usually like to link back to all the places that were useful to find a solution to any problem I blog about, but this time it was just too difficult to keep track of everything, except for this discussion on the german Proxmox forums.

The solution

I ran zfs get -r dnodesize rpool to get a sense of what were the different dnodesize values for all the datasets in the pool. They were all set to legacy, except for my rpool/nas dataset.
So I made a new dataset for my NAS data with dnodesize explicitly set to legacy, then I rsync’d everything from the old dataset into the new one, destroyed the old dataset and renamed the new one.

zfs create -o dnodesize=legacy rpool/nas2
rsync -av --progress /rpool/nas/ /rpool/nas2/
zfs destroy rpool/nas
zfs rename rpool/nas2 rpool/nas

Last step: moving back the mountpoint for `rpool/ROOT/pve-1`:

zfs set mountpoint=/rpool/ROOT/pve-1

And then I moved the SSD back into my server.

That’s it. It just took an afternoon of cursing.

Источник

На чтение 4 мин Просмотров 4.6к. Опубликовано Обновлено 30.04.2022

Grub — это универсальный загрузчик для Linux и других операционных систем, которые Вы используете параллельно вместе. При различных операциях(например перенос файлов диска, со старого устройства на новое), может возникать довольно частая ошибка Grub Rescue Unknown Filesystem. В этой статье, мы поговорим о том, как с ней бороться и нормально загрузить операционную систему.

Содержание

Почему появляется ошибка Grub Rescue Unknown Filesystem
Способ 1. Приоритет в загрузке
Способ 2. Запуск Grub
Такая ошибка есть на всех дистрибутивах
Способ 3. Ремонт с помощью Boot Repair в Ubuntu

Почему появляется ошибка Grub Rescue Unknown Filesystem

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

Способ 1. Приоритет в загрузке

Если у вас есть двойная загрузка систем Ubuntu и Windows, и вы получаете при загрузке файловую систему с ошибками, вы бы хотели перенести свои приоритеты одной из операционных систем. Вам необходимо запустить свой компьютер с Extranal Live CD или USB Ubuntu.

Как только вы запустите Ubuntu, вам нужно открыть терминал (Ctrl + Alt + t), для этого действия нужно быть root для доступа к корневым файлам:

sudo su

Затем последовательно введите следующие команды:

# Добавить репозиторий boot-repair
sudo add-apt-repository ppa:yannubuntu/boot-repair

# Обновим apt-get и установим boot-repair 
sudo apt-get update && sudo apt-get install -y boot-repair

# Запустим boot-repair
boot-repair

После того, как это будет сделано, откроется окно восстановления при загрузке с двумя вариантами, выберите первый вариант (нужно быть терпеливым, потребуется время). Перезагрузите компьютер без компакт-диска или USB-накопителя и проверьте, не устранена ли проблема.

Если не помогло, тогда запустите снова живую ubuntu, откройте терминал и введите boot-repair. Он снова отобразит окно, в котором нужно выбрать второй вариант. Дождитесь выполнения, перезагрузитесь и посмотрите, решилась ли проблема. Все должно запускаться.

Способ 2. Запуск Grub

Также есть второй вариант, развертывания событий при запуске загрузчика. C помощью команды ls проверяете какие диски у Вас установлены. Для первого жесткого диска я вижу следующее:
(hd0) (hd0, msdos6) (hd0, msdos5) (hd0, msdos2) (hd0, msdos1)

Теперь нужно узнать, как содержит Linux на нем, с помощью команды ls (hd0, msdos6) / проверяете списки каталогов. Другие разделы дадут «error: unknown filesystem».

С помощью терминала, вводите следующие значения:

set prefix=(hd0,1)/boot/grub

set root=(hd0,1)

Раздел /boot это раздел установленной системы вместе с загрузчиком. Именно вышеуказанными командами, мы указываем использовать диск (hd0,1) для последующих команд.

После, следует проверить диск на наличие модулей, и действительно ли на этом диске есть та информация, которая нам нужна. Вводим команду:

ls /boot/grub

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

insmod ext2
insmod normal
normal

Такая ошибка есть на всех дистрибутивах

Из этих многочисленных дистрибутивов Linux Ubuntu, Mint, Fedora, openSUSE и Debian являются одними из самых популярных операционных систем.

Если мы посмотрим на статистику, Ubuntu, произносится как «oo-boon-too», является самой популярной операционной системой с открытым исходным кодом. Для большинства из нас Ubuntu была фаворитом, если говорить про операционную систему на базе Linux.

Поиск программного обеспечения с вашим интересом намного проще в Ubuntu Linux. Вам просто нужно открыть Ubuntu Software Center и найти все полезное программное обеспечение. Просто нажмите кнопку установки и пакет будет установлен. Кроме того, вы можете установить множество программ с несколькими простыми командами. Для базового использования Ubuntu поставляется с предустановленным множеством программ, таких как Gimp, Chromium, VLC и Firefox. Но самое удобное это то, что здесь все можно починить за несколько минут. О чем мы и поговорим в следующем способе.

Новые версии Ubuntu с последним ядром Linux. Это позволяет запускать большее количество старых аппаратных средств, а также новые системы с последними чипами. Ubuntu также поставляется со многими предустановленными драйверами, которые экономят время.

Способ 3. Ремонт с помощью Boot Repair в Ubuntu

Ошибка Grub Rescue Unknown Filesystem также исправляется с помощью этой утилиты.

Boot Repair — простой инструмент для восстановления частых проблем с загрузкой для Linux, Windows и других ОС. Он бесплатный, с открытым исходным кодом и простой в использовании (ремонт одним щелчком мыши).

Так как загрузчик не работает, следует запустить Ubuntu с Live CD или USB-карты. И далее, через терминал скачать эту утилиту для починки загрузчика.

Важно! Чтобы каждый раз не проводить эту операцию заново, Вам нужно будет восстановить загрузчик Grub. Как это делается я уже рассказывал, в предыдущей статье.

Ошибка Grub Rescue Unknown Filesystem является частым явлением, но, очень быстро исправляется. Думаю, даже для новичка не составит особых усилий проследовать руководству и восстановить доступ к системе.

Источник

Before reading: The answer below is meant for Ubuntu users who have just updated/recovered/reinstalled/installed OS X. It’s likely that the answer will work if this isn’t the case (for example, if there are any inconsistencies in your partition table), but I’m not sure.

For me, this happened after updating to OS X Mavericks (10.9). Basically what may have happened is that OS X created a recovery partition («Recovery HD») that the system only detects sometimes. For example, GParted in Ubuntu will see the recovery partition fine, but when listing the partitions in terminal (fdisk -l), you may not see the partitions.

Diagnosing the issue: Did the OS X update/format/recovery cause this problem?

In order to diagnose that this is indeed the case, first use GRUB rescue to boot into Ubuntu. In order to do this, follow this page or see if any of the other answers on this question can get you into Ubuntu. For me, running the below commands temporarily allowed me to boot the correct partition. Depending on how your hard drives and partitions are set up, it may vary:

grub rescue> set prefix=(hd0,6)/boot/grub
grub rescue> insmod normal
grub rescue> normal

Now, log in to Ubuntu and check GParted. If you see the recovery partition, open up a terminal and type fdisk -l to see if that detects the recovery partition. If it doesn’t list the same partitions, check the device/partition column and see if those also don’t match up (for example, in GParted your boot partition may be /dev/sda4, but it is /dev/sda3 when running fdisk). If this is the case, keep reading. If it’s not, it looks like your partitions are lined up correctly. You can either choose to keep reading and follow the instructions (which, if GRUB was working before the restore/reinstall/etc…, this should work properly), or just reinstall GRUB on the right partition.

Fixing it by removing/merging the recovery partition

To fix this issue, what we want to do is get rid of the recovery partition — it’s causing issues and inconsistencies, and removing it shouldn’t cause damage. Ideally you want to merge it with the normal HFS+ OS X partition, so follow this question and answer here. After merging, GRUB should be back to normal.

Источник

Grub — это универсальный загрузчик, который используется для загрузки операционной системы Linux и других ОС, в случае, если на компьютере установлен Linux. Но когда вы выполняете какие-либо действия с разделами на диске, например, восстанавливаете их с помощью Clonezilla, изменяете размер или что-то другое, что Grub может быть поврежден.

Часто такие повреждения приводят к ошибке grub rescue unknown filesystem. Тогда перед вами не появляется меню, а только сообщение про ошибку и консоль восстановления для ввода команд. В этой небольшой статье мы рассмотрим как исправить эту ошибку.

Ошибка grub rescue unknown filesystem может возникать по разным причинам вот самые распространенные причины:

Вы восстанавливали диск из Clonezilla и были изменены метрики раздела /boot;
Раздел /boot был отформатирован и больше не существует;

Дело в том, что Grub устанавливается в два места. Первое — место в таблице разделов MBR. Там очень мало места, около 512 байт, а следовательно, весь загрузчик туда поместиться не может. Поэтому Grub имеет модульную структуру и все основные модули, конфигурационные файлы и ресурсы располагаются на обычном разделе, который монтируется после загрузки в /boot. Причем программа в MBR помнит где находится раздел /boot, но если с этим разделом что-то произойдет и программа не сможет загрузить привычные модули, то выдаст ошибку uncnown filesystem. Если раздела больше нет, то вам останется только брать LiveCD диск и переустанавливать загрузчик, если же раздел просто немного изменен, то еще можно все исправить.

Как исправить Grub unknown error

У вас есть простейший терминал с самой простой командной оболочкой. Чтобы знать какие команды можно там вводить наберите:

help

Дальше нам нужно посмотреть список доступных разделов, для этого используется команда ls, как в bash:

ls

Без модулей grub поддерживает только ту файловую систему, которая была на /boot. Вы можете попытаться просмотреть содержимое каждого раздела чтобы определить где находятся файлы модулей. Например:

ls (hd0,1)/

Если вы увидели папку boot, значит это наш раздел. Дальше устанавливаем этот раздел значением переменной root с помощью команды set:

set root=(hd0,1)
set prefix=(hd0,1)/boot/grub

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

insmod normal
normal

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

Выводы

В этой статье мы рассмотрели почему возникает ошибка error unknown filesystem grub rescue и что делать grub rescue, когда вы видите это сообщение. Да, во многих случаях у вас уже не получится загрузить систему без LiveCD диска. Но иногда все можно спасти. Надеюсь, эта информация была полезной для вас.

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна .

Об авторе

Основатель и администратор сайта losst.ru, увлекаюсь открытым программным обеспечением и операционной системой Linux. В качестве основной ОС сейчас использую Ubuntu. Кроме Linux, интересуюсь всем, что связано с информационными технологиями и современной наукой.

Источник

Содержание

Ошибка grub rescue unknown filesystem
Ошибка grub rescue unknown filesystem
Как исправить Grub unknown error
Выводы
Ошибка Grub Rescue Unknown Filesystem
Почему появляется ошибка Grub Rescue Unknown Filesystem
Способ 1. Приоритет в загрузке
Способ 2. Запуск Grub
Такая ошибка есть на всех дистрибутивах?
Способ 3. Ремонт с помощью Boot Repair в Ubuntu
Выводы

Ошибка grub rescue unknown filesystem

Ошибка grub rescue unknown filesystem может возникать по разным причинам вот самые распространенные причины:

Как исправить Grub unknown error

grub1

Дальше нам нужно посмотреть список доступных разделов, для этого используется команда ls, как в bash:

grub3

grub2

set root=(hd0,1)
set prefix=(hd0,1)/boot/grub

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

insmod normal
normal

grub4

Выводы

Источник

Ошибка Grub Rescue Unknown Filesystem

Почему появляется ошибка Grub Rescue Unknown Filesystem

Способ 1. Приоритет в загрузке

Затем последовательно введите следующие команды:

Способ 2. Запуск Grub

Также есть второй вариант, развертывания событий при запуске загрузчика. C помощью команды ls проверяете какие диски у Вас установлены. Для первого жесткого диска я вижу следующее:
(hd0) (hd0, msdos6) (hd0, msdos5) (hd0, msdos2) (hd0, msdos1)

Теперь нужно узнать, как содержит Linux на нем, с помощью команды ls (hd0, msdos6) / проверяете списки каталогов. Другие разделы дадут «error: unknown filesystem».

С помощью терминала, вводите следующие значения:

Раздел /boot это раздел установленной системы вместе с загрузчиком. Именно вышеуказанными командами, мы указываем использовать диск (hd0,1) для последующих команд.

Такая ошибка есть на всех дистрибутивах?

Способ 3. Ремонт с помощью Boot Repair в Ubuntu

Ошибка Grub Rescue Unknown Filesystem также исправляется с помощью этой утилиты.

Важно! Чтобы каждый раз не проводить эту операцию заново, Вам нужно будет восстановить загрузчик Grub. Как это делается я уже рассказывал, в предыдущей статье.

Выводы

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник