Ошибка symbol grub file filters not found - Ремонт и установка крупной бытовой техники

I too encountered the exact same problem after updating to Ubuntu 19.10. Here is how I (just now) resolved it:

First, you have two problems, not one. Both your installation is screwed up and the Grub Bootloader is messed up. And running only one fix won’t fix everything. You need both the «boot-repair-disk» and the latest version of Ubuntu (both on USB boot drives. Don’t use a DVD.)

If you try to do (only) a «Repair Install» from the Ubuntu Live disk first, you’ll still be greeted by the «grub rescue>» prompt when done. So, first you must use the «boot-repair-disk». Tell it to repair your broken boot partition with Ubuntu on it. If you aren’t sure of the partition ID, launch «GParted» from the «Start» menu (bottom left.)

Repair that boot partition. This should at least bring Grub back. Try to launch Ubuntu. If it works, you’re done. If not, boot the Live «CD» from USB.

Double-click the «Install Ubuntu 19.10» icon on the desktop (don’t worry, there will be an option to repair w/o losing your old programs/files.)

I recommend checking the boxes to download all updates during install, including 3rd party.

The Installer should detect your broken partition and give you the option to repair it (the first option.) It may need to disable some 3rd party repositories. Not a big deal, they’re easy enough to get back later.

(Note: If you had to login with a password before, don’t try to select «login w/o password» now. It won’t let you in when you’re done.)

Once done, you should have Ubuntu 19.10 installed with all/most of your existing apps still installed (though the toolbar shortcuts will be reset.) I had to reinstall a few 3rd party apps, but their configurations were still there afterwards, so nothing was lost.

Источник

After apt-get update; apt-get upgrade successfully on my Kali Linux VM, restarted to finish some installations and was taken to grub rescue mode.

On grub rescue >

ls, returns:

(hd0) (hd0,msdos1) (hd0,msdos5)

set, returns:

cmdpath=(hd0)
prefix=(hd0,msdos1)/boot/grub
root=hd0,msdos1

I ran ls on (hd0)/boot, (hd0,msdos1)/boot, (hd0,msdos5)/boot, and confirmed results of bootable images only on (hd0,msdos1)

insmod linux, returns following grub error:

symbol 'grub_file_filters' not found

Wanted to see where grub is looking so tried insmod kali which returned:

/boot/grub/i386-pc/kali.mod not found

Hence it seems that the linux module is found before I get the error.

From research, found that this error is filesystem/USB device related but since this is a Virtual image (and I’m on VirtualBox) I am unsure of how to fix it.

No problem in installing again from scratch but curious about this error and what it is referring to / how it can be resolved.

Thanks for any insights

Additional Note:
This is the output on my screen from the moment I boot the VM and after I execute some of the ls commands mentioned above

error: symbol ‘grub_file_filters’ not found. 
Entering rescue mode... 
grub rescue> ls 
(hd0) (hd0,msdos5) (hd0,msdos1) 
grub rescue> ls (hd0) 
(hd0): Filesystem is unknown. 
grub rescue> ls (hd0,msdos5) 
(hd0,msdos5): Filesystem is unknown. 
grub rescue> ls (hd0,msdos1) 
(hd0,msdos1): Filesystem is ext2. 
grub rescue> ls (hd0)/boot
error: unknown filesystem
grub rescue> ls (hd0,msdos5)/boot
error: unknown filesystem
grub rescue> ls (hd0,msdos1)/boot
./ . ./ System.map-4.18.0-kali2-amd64 config-4.18.0-kali2-amd64 
initrd.img—4.18.0-kali2-amd64 vmlinuz-4.18.0-kali2-amd64 
grub/ config-4.19.0-kali5-amd64 vmlinuz-4.19.0-kali5-amd64 
System.map-4.19.0-kali5-amd64 initrd.img-4.19.0-kali5-amd64
grub rescue>

Источник

This document (000019919) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 15 SP2 Running on Microsoft Azure

Situation

After upgrading a gen2 VM running on Microsoft Azure to SLES 15 SP2, the system fails to boot and prints the following error to the Azure VM console:

   Loading Linux 5.3.18-24.49-default ...
   error: symbol `grub_file_filters' not found.
   Loading initial ramdisk ...
   error: symbol `grub_file_filters' not found.

   Press any key to continue...

Resolution

If the system was rebooted, the issue can be fixed with these steps:

1- Create a recovery disk and set up a SLES15 SP2 gen2 chroot environment as described here:

2- Install the secure-boot shim to the recovery disk:

/usr/sbin/shim-install

3- Swap out the VM’s OsDisk in the Azure Portal WebUI or azure cli with the recovery disk created in step 1:

az vm update -g <resource group> -n <vm name> —os-disk <recovery disk>

If the system was not rebooted after the upgrade, kindly run:

/usr/sbin/shim-install

Cause

The issue is escalated to SUSE Engineering and Microsoft.

Status

Reported to Engineering

Additional Information

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented «AS IS» WITHOUT WARRANTY OF ANY KIND.

Document ID:000019919
Creation Date:
19-Mar-2021
Modified Date:22-Mar-2021
- SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com

Источник

Comments

Issue description

After upgrading bootloader breaks with

error: symbol `grub_file_filters' not found
Entering rescue mode

Steps to reproduce

Technical details

system: "x86_64-linux"
host os: Linux 4.19.44, NixOS, 19.09.git.2439b30 (Loris)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.2.2

Hi gnidorah,
I recently had the same issue.

A nixos-rebuild switch failed with some error about a full filesystem.
In my case the cause was a full efivars partition. This left me a broken boot like you have.

See #27821 for more info.

This is how I restored my system:

Put the NixOS installer on a usb stick
Boot into the NixOS installer
rm /sys/firmware/efi/efivars/dump-* (don’t delete anything else in that directory)
Reboot again into the NixOS installer
Mount your partitions to the correct locations in /mnt/
nixos-enter
echo 'nameserver 8.8.8.8' >> /etc/resolv.conf to fix network access.
nixos-rebuild boot --install-bootloader (install-bootloader might be optional, no idea)
This command should complete successfully.
reboot

This is all I had to do. However, for now I also disabled boot.loader.efi.canTouchEfiVariables which was initially set by nixos-generate-config. I have no idea what this setting does when enabled. It might be related.

I hope this helps,
Tom

@TomSmeets Unfortunately its not the case. My config is the following:

  fileSystems."/boot/efi" =
    { device = "/dev/disk/by-uuid/58D0-2B0F";
      fsType = "vfat";
      options = [ "defaults,noauto" ];
    };
  boot.loader.efi.efiSysMountPoint = "/boot/efi";
  boot.loader.grub = {
    efiSupport = true;
    device = "nodev";
  };

So fat partition only stores

/boot/efi
└── EFI
    ├── BOOT
    │   └── BOOTX64.EFI
    └── grub
        └── grubx64.efi

3 directories, 2 files

While system partition (/boot folder) stores everything else so I never run into #23926
It worked great for year or so until I got above issue. The latest nixos-unstable that currently works for me is bc94dcf Perhaps its a time for bisect 😞

Also a small hint. If you use recent NixOS installation usb stick, then you could boot from it, choose refind in menu, then choose bootx64 entry it will load directry to your nixos installation, so there is no real need for nixos-enter tricks

I have this error as well. I had to boot from a stick and rescue my system about a week ago.
I just tried today to update channels and the exact same bug popped up. Luckily I haven’t shut down my machine yet. Did anybody find a fix?

Follow up:
I accidentally updated yet again and had to go through the annoying rescue process another time.
I finally just cut grub out altogether and now it boots fine.
I’m sad though, I had a nicely customized grub loader that I am going to dearly miss

If you run into this issue in the future follow these steps:

Boot with a live USB
Mount as if you were installing nixos:

# Change mounts to your actual `nixos` and `boot` partitions.
mount /dev/sda1 /mnt
mount /dev/sda2 /mnt/boot
vim /mnt/etc/nixos/configuration.nix

Remove grub and fall back to the minimal loader.
My new boot.loader looks like:

boot.loader = {
    systemd-boot.enable = true;
    efi.canTouchEfiVariables = true;
    efi.efiSysMountPoint = "/boot";
};

nixos-install --root /mnt
Go get a coffee.

@BadDecisionsAlex
There is no need in steps 2,4 if you’re booting using unstable live USB

Remove grub and fall back to the minimal loader

Sorry, but no. I want to keep EFI partition as small as possible and I also want to run garbage collection as seldom as possible. For now I just reverted commit df4d0fa locally

TBH I don’t understand why we are pulling release candidates for such critical components as boot loaders.

@gnidorah I completely agree that our repo should roll back.

If you have other notes about my rescue process please let me know. I was just hoping to leave breadcrumbs for anybody else who bumps into the issue; but I am by no means an expert here.

Tried grub 2.04 locally and it didn’t work too.

I’m leaving this issue open, but since there is now a solution for out of space problem for systemd-boot #23926 (comment) I’ve switched to that

I use grub on EFI and can’t repro this bug.

My boot.loader.efi.canTouchEfiVariables is set to false.

I just did a fresh install on unstable (on ZFS root).
@obadz setting boot.loader.efi.canTouchEfiVariables to false initially resulted in no boot devices.

But essentially what was on the wiki worked:

  boot.supportedFilesystems = [ "zfs" ];
  boot.tmpOnTmpfs = true;
  boot.loader.systemd-boot.enable = false;
  boot.loader.efi.canTouchEfiVariables = true;
  boot.loader.efi.efiSysMountPoint = "/boot/efi";
  boot.loader.grub.efiSupport = true;
  boot.loader.grub.device = "nodev";

partition scheme

DISK=/dev/disk/by-id/<my disk>
sgdisk --zap-all $DISK
sgdisk -n2:1M:+512M -t2:EF00 $DISK
sgdisk -n1:0:0 -t1:BF01 $DISK

mkfs.vfat $DISK-part2

zpool create ...

And boot with grub efi seems to work fine

I switched yesterday from 19.03 to the 19.09-release channel on my tablet and the boot now complains with the same message. This is one of those x64 tablets that has a i686 EFI and thus requires boot.loader.grub.forcei686.

In the meantime, I’m booting via 32-bit USB grub with

configfile (hd1,3)/grub/grub.cfg

I tried the rm /sys/firmware/efi/efivars/dump-*, same result.

What does grub 2.04 offer? Couldn’t it just be rolled back to 2.02 in the release-19.09 branch?

I fixed my boot by just moving away all files in /boot and nixos-rebuild --install-bootloader switch.

I just had the same issue after switching to 19.09 and switching back to 19.03.

Timeline:

nix-channel --remove nixos
nix-channel add https://nixos.org/channels/nixos-19.09 nixos
nixos-rebuild switch
reboot now
booted fine, but there was an unrelated problem, so decided to rollback
nixos-rebuild switch --rollback
reboot now
got the error: symbol 'grub_file_filters' not found" error

I don’t use EFI.

Solved it by reinstalling the bootloader with a usb stick.

In order to avoid breaking boots on the 19.09 release, I’m in favour of rolling back to 2.02 on 19.09 before the release (but leaving 2.04 on master).

I’m unsure how to address this problem in general. A naive solution based on my incomplete understanding of the issue seems to me to have versioning for grub’s module directories, e.g. have /boot/grub-2.02/x86_64-efi and /boot/grub-2.04/x86_64-efi distinct so that both versions of GRUB can work. Overall though, this seems like another case of bootloaders being hard to upgrade, a problem that @samueldr has been thinking about a fair bit iirc. Maybe you can say something about this?

just tried again to upgrade to unstable and again get the grub_file_filters not found error

$ nixos-version
19.09.2370.e10c65cdb35 (Loris)
$ sudo nix-channel --add https://nixos.org/channels/nixos-unstable nixos
$ sudo nixos-rebuild switch --upgrade
$ reboot

That was probably already discussed somewhere, but:

Is there any problem with rolling back to 2.02 again? That version works, right?

elementary OS actually still uses 2.02 (5.1.2 release from 2020-02-07) also Fedora 31 from 2019-10-29, but even the two last debian releases use 2.04. but having a broken bootloader is worse than using older versions than debian

We could also implement this logic

IF efiSupport = true; THEN package 2.02 ELSE 2.04

True, or it could be based on stateVersion.

infinisil

pushed a commit
to infinisil/nixpkgs
that referenced
this issue

Apr 21, 2020

infinisil

pushed a commit
to infinisil/nixpkgs
that referenced
this issue

Apr 21, 2020

Still trying to restore my system…

I noticed that /boot/EFI/NixOS-boot/grubx64.efi hasn’t been touched — it still has a timestamp of Mar 15 2019. Shouldn’t that be replaced?

@emptyflask in case it helps:

Workaround for booting with GRUB `2.04`:

Boot the NixOS installation image (or something else that has/is rEFInd) via e.g. an USB stick
- Select rEFInd in the boot menu
Select Boot Fallback boot loader from EFI
Now you should see the usual GRUB boot menu (with all NixOS generations, etc.)
After a successful boot: Reverting to GRUB 2.02 should permanently fix the problem(?)

At least that worked for me (but: This is from my memory and online screenshots, therefore I might have missed some steps). I think these steps where posted in a related issue, but I didn’t find the link again

Regarding the GRUB regression (2.02 -> 2.04)

The issue is most likely hardware related. E.g. in my case Boot Fallback boot loader from EFI should boot the same EFI binary as without rEFInd (but I forgot to verify that last time). So this might actually be some weird issue during the transition to GRUB during the boot process (and therefore only affecting some devices).

That actually does help, I was able to boot into my normal system using rEFInd. Thanks!

So to summarize the issue above, there are 3 components:

the firmware (BIOS or UEFI)
the grub core image
grub modules

The issue boils down to your firmware and your OS disagreeing about where the grub core image is.

The firmware points to the grub core image. The core image loads modules. The interface between core and modules is not stable.

If your OS is installing core image and modules to location A, but your firmware is loading the core image from location B, then at some point the (old, non-updated) core image at location B is not able to load the (new, updated) modules at location A.

The problem has always been there (mismatched core and modules), but you hadn’t noticed until the interface between the two broke.

It does appear that there might be some duplication in /boot, maybe from attempting to use boot.loader.grub.efiInstallAsRemovable? I’m particularly wondering about /boot/EFI/NixOS-boot/grubx64.efi, nothing seems to touch it, and it’s got a timestamp from a year ago.

(I’ve omitted a bunch of modules and Microsoft-related things)

.
├── background.png
├── converted-font.pf2
├── EFI
│   ├── Boot
│   │   └── bootx64.efi
│   ├── grub
│   │   └── grubx64.efi
│   ├── Microsoft
│   │   └── Boot
│   ├── nixos
│   │   ├── 09iivcwr1b2ijxxa4z7bcnpfjwq9cap7-initrd-linux-4.19.101-initrd.efi
│   │   ├── 502dhxra32pxv99zm63m2si006bdaijc-linux-4.19.109-bzImage.efi
│   │   ├── aqdfl1zp8d767nng5w3wh3wv54npjb8y-initrd-linux-5.4.33-initrd.efi
│   │   ├── dpp68ayvn1xmx9d8wld1fjp8ax6lz2k5-initrd-linux-4.19.109-initrd.efi
│   │   ├── h9w801h7y09a315xi7x4pskpn8y4i7xf-initrd-linux-4.19.113-initrd.efi
│   │   ├── ia4zbwrkcigbiil3vhhfwjji0gn7m9yr-linux-4.19.96-bzImage.efi
│   │   ├── jg9gfc84svh76nkj2am2jxq977bqd2k8-linux-4.19.113-bzImage.efi
│   │   ├── k7f7l104af1ny3sliwpxybzf6dy5060l-linux-4.19.101-bzImage.efi
│   │   ├── l3389n3q8cas7z5ybbwga251hwx9m6gv-initrd-linux-5.4.33-initrd.efi
│   │   ├── li3v6p9mqsspm0zgglzba2szab2zdmiv-linux-5.4.33-bzImage.efi
│   │   ├── w8yq408lfmszipyjxl9swbajjmsmkyza-initrd-linux-4.19.113-initrd.efi
│   │   └── xmknk1cjh8kgpl6j1n95a7b2fhmk7saz-initrd-linux-4.19.96-initrd.efi
│   └── NixOS-boot
│       └── grubx64.efi
├── grub
│   ├── fonts
│   ├── grub.cfg
│   ├── grubenv
│   ├── locale
│   ├── state
│   └── x86_64-efi
│       ├── core.efi
│       └── grub.efi
├── kernels
│   ├── aqdfl1zp8d767nng5w3wh3wv54npjb8y-initrd-linux-5.4.33-initrd
│   ├── jg9gfc84svh76nkj2am2jxq977bqd2k8-linux-4.19.113-bzImage
│   ├── l3389n3q8cas7z5ybbwga251hwx9m6gv-initrd-linux-5.4.33-initrd
│   ├── li3v6p9mqsspm0zgglzba2szab2zdmiv-linux-5.4.33-bzImage
│   └── w8yq408lfmszipyjxl9swbajjmsmkyza-initrd-linux-4.19.113-initrd
├── loader
│   ├── entries
│   │   └── nixos-generation-154.conf
│   └── loader.conf
└── System Volume Information

If you’re not dual-booting, it should be safe to remove all of /boot (keep a backup in order to be able to reproduce the error again), then rerun nixos-rebuild boot. AFAIU, that should either (a) make everything work correctly, since the grub image will only be in one place or (b) break your boot (have your rEFInd USB stick at the ready!). The latter should only happen if either (i) both canTouchEfiVariables and efiInstallAsRemovable are set to false or (ii) your firmware is broken (disregards the boot order specified by the OS) or (iii) your firmware is not configured to use the fallback path (bootx64.efi). In any case, I’d consider removing the bad state as the right solution here.

@lheckemann I removed all of /boot and then nixos-rebuild boot. I am not able to boot anymore without usb. If boot with usb i stuck at grub (GNU GRUB version 2.04 Minimal BASH-line editing is supported. …).
At this point I tried:
grub> set root=(hd1,gpt1)
grub> linux /efi/nixos/hash-linux-<number>-bzImage.efi .... root=LABEL=NIXOS_ISO (i previously set this label to my usb)
grub> initrd /efi/nixos/initrd-linux-<number> ....
grub> boot
I end up at this problem #6265:
like

timed out waiting for device /dev/root, trying to mount anyway.
mounting /dev/root on /iso...
mount: mounting /dev/root on /mnt-root/iso failed: No such file or directory

An error occurred in stage 1 of the boot process, which must mount the root filesystem on /mnt-root' and then start stage 2. Press one of the following keys:
  r) to reboot immediately
  *) to ignore the error and continue

If I continue i end up in kernel panic.
Any ideas?

Update1: Found an old USB with nixos-19.03 with GRUB 2.02. Seems like the installer is working. rEFInd aint working. This means i have to totally fresh install nixos to upgrade it then to 20.03. which is not the optimal option, but ok! Keep you updated.

Update2: This actually could be an option too: https://gist.github.com/chris-martin/4ead9b0acbd2e3ce084576ee06961000

@saggzz sorry about that! Do you have either or both of canTouchEfiVariables or efiInstallAsRemovable set?

As for reinstalling: you don’t have to do a totally fresh install. You can boot the installation ISO, mount the filesystems, and run nixos-install. It will rebuild the system profile and set up the bootloader etc. without wiping anything. If you pass -I nixpkgs=channel:nixos-20.03 it should directly install NixOS 20.03, even from the 19.03 installer image. The one thing you may need to do after installation is make sure that the channel is set correctly (sudo nix-channel --add https://nixos.org/channels/nixos-20.03 nixos && sudo nix-channel --update) so that you don’t accidentally downgrade later.

EDIT: you can also get a shell in the initramfs to try and mount your root filesystem manually by passing boot.shell_on_fail on the kernel command line. Then you can try and enter the system by pressing f at the prompt and then using the following commands:

mount /dev/sda2 /mnt-root # substitute device name as appropriate
exec switch_root /mnt-root /nix/var/nix/profiles/system/init

@saggzz when I had problems with GRUB, I followed the steps here to re-install.

@lheckemann thank you for the hints. Either canTouchEfiVariables nor efiInstallAsRemovable had been set. I tried to nixos-install and mount the filesystems, but no filesystems were found. This brought me to the conclusion that something was totally messed up there. I fresh installed nixos und used the -I nixpkgs=channel:nixos-20.03 option — worked!
@asymmetric thank you, i switched to systemd-boot for now!

so I finally now have it booting normally and all I did afaik is change efiInstallAsRemovable to true
and canTouchEfiVariables to false instead of the inverse.
Seems like I can perfectly dual boot now and I’m on 20.03

Oh I also changed the efi mount point around and I think that may have cleaned up the efi directory, though it’s now back to where I started.

I do confirm that grub2 2.04 boots NixOS in the following scenario:

nixos-version: 19.09.1320.4ad6f1404a8

{
  boot.loader.systemd-boot.enable = false;
  boot.loader.efi.efiSysMountPoint = "/boot/efi";
  boot.loader.efi.canTouchEfiVariables = false;
  boot.loader.grub.efiInstallAsRemovable = true;
  boot.loader.grub.device = "nodev";
}

zstd btrfs compression affected files: init, initrd
packageOverrides: grub2 from unstable

Notably, I was unable to boot with grub2 2.02 until adding the override. zstd compression support appeared in grub2 2.04.

Today I got this upgrading to 20.03. I tried a couple times following @lheckemann steps:

boot the installation ISO
mount the filesystems
run nixos-install

with no success until I removed the content of /boot(recreating it anew).

Does this kind of error happen also in unstable channels or it is solved there?

Glad to hear removing all of /boot helped. This isn’t fixed anywhere because it’s a bit difficult to detect — on EFI systems, where it’s most likely to occur, we could check the BootCurrent EFI variable and the corresponding boot entry, then throw a warning if it doesn’t match the current bootloader installation path. Someone™ would need to implement that though

Thank you again @lheckemann

In fact, after recreating it, I had to fix it manually (it created EFI/EFI/etc). Not sure if this is strictly related to the issue or I just messed it during attempts

Источник

I too encountered the exact same problem after updating to Ubuntu 19.10. Here is how I (just now) resolved it:

Repair that boot partition. This should at least bring Grub back. Try to launch Ubuntu. If it works, you’re done. If not, boot the Live «CD» from USB.

Double-click the «Install Ubuntu 19.10» icon on the desktop (don’t worry, there will be an option to repair w/o losing your old programs/files.)

I recommend checking the boxes to download all updates during install, including 3rd party.

(Note: If you had to login with a password before, don’t try to select «login w/o password» now. It won’t let you in when you’re done.)

After apt-get update; apt-get upgrade successfully on my Kali Linux VM, restarted to finish some installations and was taken to grub rescue mode.

On grub rescue >

ls, returns:

(hd0) (hd0,msdos1) (hd0,msdos5)

set, returns:

cmdpath=(hd0)
prefix=(hd0,msdos1)/boot/grub
root=hd0,msdos1

I ran ls on (hd0)/boot, (hd0,msdos1)/boot, (hd0,msdos5)/boot, and confirmed results of bootable images only on (hd0,msdos1)

insmod linux, returns following grub error:

symbol 'grub_file_filters' not found

Wanted to see where grub is looking so tried insmod kali which returned:

/boot/grub/i386-pc/kali.mod not found

Hence it seems that the linux module is found before I get the error.

From research, found that this error is filesystem/USB device related but since this is a Virtual image (and I’m on VirtualBox) I am unsure of how to fix it.

No problem in installing again from scratch but curious about this error and what it is referring to / how it can be resolved.

Thanks for any insights

Additional Note:
This is the output on my screen from the moment I boot the VM and after I execute some of the ls commands mentioned above

error: symbol ‘grub_file_filters’ not found. 
Entering rescue mode... 
grub rescue> ls 
(hd0) (hd0,msdos5) (hd0,msdos1) 
grub rescue> ls (hd0) 
(hd0): Filesystem is unknown. 
grub rescue> ls (hd0,msdos5) 
(hd0,msdos5): Filesystem is unknown. 
grub rescue> ls (hd0,msdos1) 
(hd0,msdos1): Filesystem is ext2. 
grub rescue> ls (hd0)/boot
error: unknown filesystem
grub rescue> ls (hd0,msdos5)/boot
error: unknown filesystem
grub rescue> ls (hd0,msdos1)/boot
./ . ./ System.map-4.18.0-kali2-amd64 config-4.18.0-kali2-amd64 
initrd.img—4.18.0-kali2-amd64 vmlinuz-4.18.0-kali2-amd64 
grub/ config-4.19.0-kali5-amd64 vmlinuz-4.19.0-kali5-amd64 
System.map-4.19.0-kali5-amd64 initrd.img-4.19.0-kali5-amd64
grub rescue>

# # DO NOT EDIT THIS FILE # # It is automatically generated by grub-mkconfig using templates # from /etc/grub.d and settings from /etc/default/grub # ### BEGIN /etc/grub.d/00_header ### insmod part_gpt insmod part_msdos if [ -s $prefix/grubenv ]; then load_env fi if [ "${next_entry}" ] ; then set default="${next_entry}" set next_entry= save_env next_entry set boot_once=true else set default="0" fi if [ x"${feature_menuentry_id}" = xy ]; then menuentry_id_option="--id" else menuentry_id_option="" fi export menuentry_id_option if [ "${prev_saved_entry}" ]; then set saved_entry="${prev_saved_entry}" save_env saved_entry set prev_saved_entry= save_env prev_saved_entry set boot_once=true fi function savedefault { if [ -z "${boot_once}" ]; then saved_entry="${chosen}" save_env saved_entry fi } function load_video { if [ x$feature_all_video_module = xy ]; then insmod all_video else insmod efi_gop insmod efi_uga insmod ieee1275_fb insmod vbe insmod vga insmod video_bochs insmod video_cirrus fi } if [ x$feature_default_font_path = xy ] ; then font=unicode else insmod part_msdos insmod ext2 set root='hd1,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos1' --hint-bios=hd1,msdos1 --hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1 45b1a8e3-5fb4-48d8-89f0-532c516a8262 else search --no-floppy --fs-uuid --set=root 45b1a8e3-5fb4-48d8-89f0-532c516a8262 fi font="/usr/share/grub/unicode.pf2" fi if loadfont $font ; then set gfxmode=auto load_video insmod gfxterm set locale_dir=$prefix/locale set lang=en_US insmod gettext fi terminal_input console terminal_output gfxterm if [ x$feature_timeout_style = xy ] ; then set timeout_style=menu set timeout=5 # Fallback normal timeout code in case the timeout_style feature is # unavailable. else set timeout=5 fi ### END /etc/grub.d/00_header ### ### BEGIN /etc/grub.d/10_linux ### menuentry 'Arch Linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-45b1a8e3-5fb4-48d8-89f0-532c516a8262' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='hd1,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos1' --hint-bios=hd1,msdos1 --hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1 45b1a8e3-5fb4-48d8-89f0-532c516a8262 else search --no-floppy --fs-uuid --set=root 45b1a8e3-5fb4-48d8-89f0-532c516a8262 fi echo 'Loading Linux linux-lts ...' linux /boot/vmlinuz-linux-lts root=UUID=45b1a8e3-5fb4-48d8-89f0-532c516a8262 rw loglevel=3 quiet echo 'Loading initial ramdisk ...' initrd /boot/intel-ucode.img /boot/initramfs-linux-lts.img } submenu 'Advanced options for Arch Linux' $menuentry_id_option 'gnulinux-advanced-45b1a8e3-5fb4-48d8-89f0-532c516a8262' { menuentry 'Arch Linux, with Linux linux-lts' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-lts-advanced-45b1a8e3-5fb4-48d8-89f0-532c516a8262' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='hd1,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos1' --hint-bios=hd1,msdos1 --hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1 45b1a8e3-5fb4-48d8-89f0-532c516a8262 else search --no-floppy --fs-uuid --set=root 45b1a8e3-5fb4-48d8-89f0-532c516a8262 fi echo 'Loading Linux linux-lts ...' linux /boot/vmlinuz-linux-lts root=UUID=45b1a8e3-5fb4-48d8-89f0-532c516a8262 rw loglevel=3 quiet echo 'Loading initial ramdisk ...' initrd /boot/intel-ucode.img /boot/initramfs-linux-lts.img } menuentry 'Arch Linux, with Linux linux-lts (fallback initramfs)' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-lts-fallback-45b1a8e3-5fb4-48d8-89f0-532c516a8262' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='hd1,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos1' --hint-bios=hd1,msdos1 --hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1 45b1a8e3-5fb4-48d8-89f0-532c516a8262 else search --no-floppy --fs-uuid --set=root 45b1a8e3-5fb4-48d8-89f0-532c516a8262 fi echo 'Loading Linux linux-lts ...' linux /boot/vmlinuz-linux-lts root=UUID=45b1a8e3-5fb4-48d8-89f0-532c516a8262 rw loglevel=3 quiet echo 'Loading initial ramdisk ...' initrd /boot/initramfs-linux-lts-fallback.img } menuentry 'Arch Linux, with Linux linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-advanced-45b1a8e3-5fb4-48d8-89f0-532c516a8262' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='hd1,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos1' --hint-bios=hd1,msdos1 --hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1 45b1a8e3-5fb4-48d8-89f0-532c516a8262 else search --no-floppy --fs-uuid --set=root 45b1a8e3-5fb4-48d8-89f0-532c516a8262 fi echo 'Loading Linux linux ...' linux /boot/vmlinuz-linux root=UUID=45b1a8e3-5fb4-48d8-89f0-532c516a8262 rw loglevel=3 quiet echo 'Loading initial ramdisk ...' initrd /boot/intel-ucode.img /boot/initramfs-linux.img } menuentry 'Arch Linux, with Linux linux (fallback initramfs)' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-fallback-45b1a8e3-5fb4-48d8-89f0-532c516a8262' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='hd1,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos1' --hint-bios=hd1,msdos1 --hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1 45b1a8e3-5fb4-48d8-89f0-532c516a8262 else search --no-floppy --fs-uuid --set=root 45b1a8e3-5fb4-48d8-89f0-532c516a8262 fi echo 'Loading Linux linux ...' linux /boot/vmlinuz-linux root=UUID=45b1a8e3-5fb4-48d8-89f0-532c516a8262 rw loglevel=3 quiet echo 'Loading initial ramdisk ...' initrd /boot/initramfs-linux-fallback.img } } ### END /etc/grub.d/10_linux ### ### BEGIN /etc/grub.d/20_linux_xen ### ### END /etc/grub.d/20_linux_xen ### ### BEGIN /etc/grub.d/30_os-prober ### menuentry 'void (on /dev/sda1)' --class void --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-2e233891-1937-4969-a34e-d052d1d84a1d' { insmod part_msdos insmod ext2 set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos1' --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 2e233891-1937-4969-a34e-d052d1d84a1d else search --no-floppy --fs-uuid --set=root 2e233891-1937-4969-a34e-d052d1d84a1d fi linux /boot/vmlinuz-4.18.17_1 root=/dev/sda1 initrd /boot/initramfs-4.18.17_1.img } submenu 'Advanced options for void (on /dev/sda1)' $menuentry_id_option 'osprober-gnulinux-advanced-2e233891-1937-4969-a34e-d052d1d84a1d' { menuentry 'void (on /dev/sda1)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.18.17_1--2e233891-1937-4969-a34e-d052d1d84a1d' { insmod part_msdos insmod ext2 set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos1' --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 2e233891-1937-4969-a34e-d052d1d84a1d else search --no-floppy --fs-uuid --set=root 2e233891-1937-4969-a34e-d052d1d84a1d fi linux /boot/vmlinuz-4.18.17_1 root=/dev/sda1 initrd /boot/initramfs-4.18.17_1.img } menuentry 'void (on /dev/sda1)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.19.45_1--2e233891-1937-4969-a34e-d052d1d84a1d' { insmod part_msdos insmod ext2 set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos1' --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 2e233891-1937-4969-a34e-d052d1d84a1d else search --no-floppy --fs-uuid --set=root 2e233891-1937-4969-a34e-d052d1d84a1d fi linux /boot/vmlinuz-4.19.45_1 root=/dev/sda1 initrd /boot/initramfs-4.19.45_1.img } menuentry 'void (on /dev/sda1)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.19.46_1--2e233891-1937-4969-a34e-d052d1d84a1d' { insmod part_msdos insmod ext2 set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos1' --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 2e233891-1937-4969-a34e-d052d1d84a1d else search --no-floppy --fs-uuid --set=root 2e233891-1937-4969-a34e-d052d1d84a1d fi linux /boot/vmlinuz-4.19.46_1 root=/dev/sda1 initrd /boot/initramfs-4.19.46_1.img } menuentry 'void (on /dev/sda1)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.19.47_1--2e233891-1937-4969-a34e-d052d1d84a1d' { insmod part_msdos insmod ext2 set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos1' --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 2e233891-1937-4969-a34e-d052d1d84a1d else search --no-floppy --fs-uuid --set=root 2e233891-1937-4969-a34e-d052d1d84a1d fi linux /boot/vmlinuz-4.19.47_1 root=/dev/sda1 initrd /boot/initramfs-4.19.47_1.img } menuentry 'void (on /dev/sda1)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.19.48_1--2e233891-1937-4969-a34e-d052d1d84a1d' { insmod part_msdos insmod ext2 set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos1' --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 2e233891-1937-4969-a34e-d052d1d84a1d else search --no-floppy --fs-uuid --set=root 2e233891-1937-4969-a34e-d052d1d84a1d fi linux /boot/vmlinuz-4.19.48_1 root=/dev/sda1 initrd /boot/initramfs-4.19.48_1.img } menuentry 'void (on /dev/sda1)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.19.57_1--2e233891-1937-4969-a34e-d052d1d84a1d' { insmod part_msdos insmod ext2 set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos1' --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 2e233891-1937-4969-a34e-d052d1d84a1d else search --no-floppy --fs-uuid --set=root 2e233891-1937-4969-a34e-d052d1d84a1d fi linux /boot/vmlinuz-4.19.57_1 root=/dev/sda1 initrd /boot/initramfs-4.19.57_1.img } menuentry 'void (on /dev/sda1)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.19.58_1--2e233891-1937-4969-a34e-d052d1d84a1d' { insmod part_msdos insmod ext2 set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos1' --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 2e233891-1937-4969-a34e-d052d1d84a1d else search --no-floppy --fs-uuid --set=root 2e233891-1937-4969-a34e-d052d1d84a1d fi linux /boot/vmlinuz-4.19.58_1 root=/dev/sda1 initrd /boot/initramfs-4.19.58_1.img } menuentry 'void (on /dev/sda1)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.19.60_1--2e233891-1937-4969-a34e-d052d1d84a1d' { insmod part_msdos insmod ext2 set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos1' --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 2e233891-1937-4969-a34e-d052d1d84a1d else search --no-floppy --fs-uuid --set=root 2e233891-1937-4969-a34e-d052d1d84a1d fi linux /boot/vmlinuz-4.19.60_1 root=/dev/sda1 initrd /boot/initramfs-4.19.60_1.img } menuentry 'void (on /dev/sda1)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.19.65_1--2e233891-1937-4969-a34e-d052d1d84a1d' { insmod part_msdos insmod ext2 set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos1' --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 2e233891-1937-4969-a34e-d052d1d84a1d else search --no-floppy --fs-uuid --set=root 2e233891-1937-4969-a34e-d052d1d84a1d fi linux /boot/vmlinuz-4.19.65_1 root=/dev/sda1 initrd /boot/initramfs-4.19.65_1.img } } ### END /etc/grub.d/30_os-prober ### ### BEGIN /etc/grub.d/40_custom ### # This file provides an easy way to add custom menu entries. Simply type the # menu entries you want to add after this comment. Be careful not to change # the 'exec tail' line above. ### END /etc/grub.d/40_custom ### ### BEGIN /etc/grub.d/41_custom ### if [ -f ${config_directory}/custom.cfg ]; then source ${config_directory}/custom.cfg elif [ -z "${config_directory}" -a -f $prefix/custom.cfg ]; then source $prefix/custom.cfg; fi ### END /etc/grub.d/41_custom ###

You can also see the duplicated entries of my Void install of which I was trying to get rid of.

Печать

Страницы: [1] 2 Все Вниз

Тема: Grub2 — катастрофа (Прочитано 2112 раз)

0 Пользователей и 1 Гость просматривают эту тему.

medusa_10001

Дорогие профи. прошу вашей помощи, потому, что попал в какой-то капкан. проблема в следующем — я решил скопировать систему на новый винчестер. Новый диск я подсоединил так, что он стал sda, а диск с системой sdb. Копирование прошло в общем нормально. В конце копирования было необходимо установить загрузчик. Я выполнил

sudo mount /dev/sdb2 /mnt sudo grub-install --root-directory=/mnt /dev/sda
Перезагрузился. Все сначала открылось как будто хорошо

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

error: symbol ‘grub_file_filters_all’ not found
Entering rescue mode…
grub rescue>
А непосредственно в Grub Customizer просто какая-то каша
Помогите пожалуйста разъеденить диски. Я не могу это сделать. Очень прошу помощи. спасибо

« Последнее редактирование: 13 Февраля 2021, 20:01:58 от ALiEN175 »

ALiEN175

sudo mount /dev/sdb2 /mnt
sudo grub-install —root-directory=/mnt /dev/sda

Пользователь добавил сообщение 13 Февраля 2021, 01:34:08:

Сам загрузчик на sda, а все то, что загружается — на sdb

« Последнее редактирование: 13 Февраля 2021, 01:34:08 от ALiEN175 »

ASUS P5K-C :: Intel Xeon E5450 @ 3.00GHz :: 8 GB DDR2 :: Radeon R7 260X :: XFCE
ACER 5750G :: Intel Core i5-2450M @ 2.50GHz :: 6 GB DDR3 :: GeForce GT 630M :: XFCE

medusa_10001

Сам загрузчик на sda, а все то, что загружается — на sdb

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

ALiEN175

medusa_10001, ну во-первых спокойствие — ничего вы не потеряли, тем более что пока подключены оба диска всё работает.

Я так понял, sda — новый диск, который хотите использовать. но имейте ввиду, что буквы дисков могут измениться при перезагрузке — проверяйте командой lsblk

sudo mount /dev/sdaX /mnt # X-номер раздела нового диска со скопированной системой sudo grub-install --root-directory=/mnt /dev/sda

ASUS P5K-C :: Intel Xeon E5450 @ 3.00GHz :: 8 GB DDR2 :: Radeon R7 260X :: XFCE
ACER 5750G :: Intel Core i5-2450M @ 2.50GHz :: 6 GB DDR3 :: GeForce GT 630M :: XFCE

medusa_10001

Код: [Выделить]

sudo mount /dev/sdaX /mnt # X-номер раздела нового диска со скопированной системой
sudo grub-install —root-directory=/mnt /dev/sda

Я только что проверил смонтированные диски и вот, что у меня сейчас есть:
Смантированы — sda2 (корень), sdb1 (linux-swap), sdb3 (/home)
пожалуйста уточните, как правильно сделать. спасибо.

ALiEN175

medusa_10001,

lsblk покажите

ASUS P5K-C :: Intel Xeon E5450 @ 3.00GHz :: 8 GB DDR2 :: Radeon R7 260X :: XFCE
ACER 5750G :: Intel Core i5-2450M @ 2.50GHz :: 6 GB DDR3 :: GeForce GT 630M :: XFCE

medusa_10001

покажите

[ medusa@oleg-PC-O-E-M ~ ]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 276K 1 loop /snap/gnome-characters/550
loop1 7:1 0 161,4M 1 loop /snap/gnome-3-28-1804/128
loop2 7:2 0 956K 1 loop /snap/gnome-logs/100
loop3 7:3 0 21,3M 1 loop /snap/communitheme/1987
loop4 7:4 0 97,9M 1 loop /snap/core/10583
loop5 7:5 0 219M 1 loop /snap/gnome-3-34-1804/66
loop6 7:6 0 62,1M 1 loop /snap/gtk-common-themes/1506
loop7 7:7 0 140K 1 loop /snap/gtk2-common-themes/13
loop8 7:8 0 276K 1 loop /snap/gnome-characters/570
loop9 7:9 0 956K 1 loop /snap/gnome-logs/93
loop10 7:10 0 217,9M 1 loop /snap/gnome-3-34-1804/60
loop11 7:11 0 55,5M 1 loop /snap/core18/1988
loop12 7:12 0 16M 1 loop /snap/communitheme/1768
loop13 7:13 0 162,9M 1 loop /snap/gnome-3-28-1804/145
loop14 7:14 0 132K 1 loop /snap/gtk2-common-themes/9
loop15 7:15 0 64,8M 1 loop /snap/gtk-common-themes/1514
loop16 7:16 0 98,4M 1 loop /snap/core/10823
loop17 7:17 0 55,4M 1 loop /snap/core18/1944
sda 8:0 0 931,5G 0 disk
├─sda1 8:1 0 11,2G 0 part
├─sda2 8:2 0 79,1G 0 part /
├─sda3 8:3 0 136,9G 0 part
├─sda4 8:4 0 512B 0 part
├─sda5 8:5 0 352,2G 0 part
└─sda6 8:6 0 352,2G 0 part
sdb 8:16 0 931,5G 0 disk
├─sdb1 8:17 0 11,2G 0 part [SWAP]
├─sdb2 8:18 0 79,1G 0 part
├─sdb3 8:19 0 136,9G 0 part /home
├─sdb4 8:20 0 512B 0 part
├─sdb5 8:21 0 353,7G 0 part
└─sdb6 8:22 0 350,6G 0 part
sr0 11:0 1 1024M 0 rom
0 ✓ 02:04:52 Сб фев 13

Пользователь добавил сообщение 13 Февраля 2021, 06:03:42:

Сейчас происходит следующее

[ medusa@oleg-PC-O-E-M ~ ]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 132K 1 loop /snap/gtk2-common-themes/9 loop1 7:1 0 62,1M 1 loop /snap/gtk-common-themes/1506 loop2 7:2 0 276K 1 loop /snap/gnome-characters/570 loop3 7:3 0 98,4M 1 loop /snap/core/10823 loop4 7:4 0 55,5M 1 loop /snap/core18/1988 loop5 7:5 0 21,3M 1 loop /snap/communitheme/1987 loop6 7:6 0 161,4M 1 loop /snap/gnome-3-28-1804/128 loop7 7:7 0 219M 1 loop /snap/gnome-3-34-1804/66 loop8 7:8 0 16M 1 loop /snap/communitheme/1768 loop9 7:9 0 64,8M 1 loop /snap/gtk-common-themes/1514 loop10 7:10 0 217,9M 1 loop /snap/gnome-3-34-1804/60 loop11 7:11 0 276K 1 loop /snap/gnome-characters/550 loop12 7:12 0 956K 1 loop /snap/gnome-logs/100 loop13 7:13 0 162,9M 1 loop /snap/gnome-3-28-1804/145 loop14 7:14 0 55,4M 1 loop /snap/core18/1944 loop15 7:15 0 140K 1 loop /snap/gtk2-common-themes/13 loop16 7:16 0 97,9M 1 loop /snap/core/10583 loop17 7:17 0 956K 1 loop /snap/gnome-logs/93 sda 8:0 0 931,5G 0 disk ├─sda1 8:1 0 11,2G 0 part [SWAP] ├─sda2 8:2 0 79,1G 0 part / ├─sda3 8:3 0 136,9G 0 part /home ├─sda4 8:4 0 512B 0 part ├─sda5 8:5 0 352,2G 0 part └─sda6 8:6 0 352,2G 0 part sdb 8:16 0 931,5G 0 disk ├─sdb1 8:17 0 11,2G 0 part ├─sdb2 8:18 0 79,1G 0 part ├─sdb3 8:19 0 136,9G 0 part ├─sdb4 8:20 0 1K 0 part ├─sdb5 8:21 0 353,7G 0 part └─sdb6 8:22 0 350,6G 0 part sr0 11:0 1 1024M 0 rom 0 ✓ 06:01:33 Сб фев 13Но при отсоединении диска вылетает все та-же ошибка. Господа прошу вас ПОМОГИТЕ((( Я заплачу, ведь вся работа годичного срока будет уничтожена. Спасибо

Пользователь добавил сообщение 13 Февраля 2021, 06:15:06:

Сейчас снова перезагрузил систему и вот что теперь получается

[ medusa@oleg-PC-O-E-M ~ ]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 217,9M 1 loop /snap/gnome-3-34-1804/60 loop1 7:1 0 276K 1 loop /snap/gnome-characters/550 loop2 7:2 0 162,9M 1 loop /snap/gnome-3-28-1804/145 loop3 7:3 0 16M 1 loop /snap/communitheme/1768 loop4 7:4 0 55,5M 1 loop /snap/core18/1988 loop5 7:5 0 276K 1 loop /snap/gnome-characters/570 loop6 7:6 0 219M 1 loop /snap/gnome-3-34-1804/66 loop7 7:7 0 132K 1 loop /snap/gtk2-common-themes/9 loop8 7:8 0 140K 1 loop /snap/gtk2-common-themes/13 loop9 7:9 0 64,8M 1 loop /snap/gtk-common-themes/1514 loop10 7:10 0 55,4M 1 loop /snap/core18/1944 loop11 7:11 0 98,4M 1 loop /snap/core/10823 loop12 7:12 0 161,4M 1 loop /snap/gnome-3-28-1804/128 loop14 7:14 0 21,3M 1 loop /snap/communitheme/1987 loop15 7:15 0 62,1M 1 loop /snap/gtk-common-themes/1506 loop16 7:16 0 956K 1 loop /snap/gnome-logs/100 loop17 7:17 0 97,9M 1 loop /snap/core/10583 loop18 7:18 0 548K 1 loop /snap/gnome-logs/103 sda 8:0 0 931,5G 0 disk ├─sda1 8:1 0 11,2G 0 part ├─sda2 8:2 0 79,1G 0 part ├─sda3 8:3 0 136,9G 0 part ├─sda4 8:4 0 1K 0 part ├─sda5 8:5 0 352,2G 0 part └─sda6 8:6 0 352,2G 0 part sdb 8:16 0 931,5G 0 disk ├─sdb1 8:17 0 11,2G 0 part [SWAP] ├─sdb2 8:18 0 79,1G 0 part / ├─sdb3 8:19 0 136,9G 0 part /home ├─sdb4 8:20 0 512B 0 part ├─sdb5 8:21 0 353,7G 0 part └─sdb6 8:22 0 350,6G 0 part sr0 11:0 1 1024M 0 rom 0 ✓ 06:12:04 Сб фев 13Теперь он загрузился с диска SDB. Я что-то делаю не так, но что я не знаю просто помогите прошу вас. Спасибо.

« Последнее редактирование: 13 Февраля 2021, 06:15:06 от medusa_10001 »

AnrDaemon

Да что вы дурью маетесь. Подключите новый диск вторым, загрузитесь со старого и просто тупо скопируйте ВЕСЬ ДИСК. А не только разделы.

dd if=/dev/sda of=/dev/sdb bs=4M

Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.

Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…

medusa_10001

Да что вы дурью маетесь. Подключите новый диск вторым, загрузитесь со старого и просто тупо скопируйте ВЕСЬ ДИСК. А не только разделы.

Я уже не могу этого сделать. Даже при попытке поменять их местами загрузка не происходит. Или я чего-то не понял. Я уже сутки как не спилю. Вы извините, но дурью мне маяться нельзя. Объясните пожалуйста.

Пользователь добавил сообщение 13 Февраля 2021, 07:41:07:

Господа, ну если нет никакой возможности может кто-то знающий объяснит, как восстановить GRUB на том диске, который я копировал, чтобы полноценная система загрузилась? Пожалуйста. Я почитал порядок восстановления, но боюсь что-то сделать коряво, а почему-то только коряво и выходит. Я прочитал этот мануал,https://losst.ru/vosstanovlenie-grub2 но уже не в чем не уверен.Кроме того пропала часть меню

Может имеет смысл просто переустановить GRUB, а потом уже пробовать переносить систему? Спасибо.

« Последнее редактирование: 13 Февраля 2021, 09:53:13 от medusa_10001 »

andytux

Кратко, в общих чертах.

sudo mount /dev/sdb2 /mnt
sudo grub-install —root-directory=/mnt /dev/sda

Вот твоя ошибка, здесь ты «размазал» груб по разным дискам.

/dev/sdb2

Здесь должен быть корневой раздел твоей системы в данной конкретной сессии. Сейчас вроде как у тебя это sda2.

/dev/sda

Здесь диск (устройство), в MBR которого запишется головная часть загрузчика. Сейчас вроде как у тебя это sda.
В этом случае весь загрузчик будет на одном диске (устройстве).
Если нужно, подробней напишу позже.

medusa_10001

Сейчас вроде как у тебя это sda2.

Сейчас загрузка прошла с диска sdb

[ medusa@oleg-PC-O-E-M ~ ]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 97,9M 1 loop /snap/core/10583 loop1 7:1 0 956K 1 loop /snap/gnome-logs/100 loop2 7:2 0 21,3M 1 loop /snap/communitheme/1987 loop3 7:3 0 98,4M 1 loop /snap/core/10823 loop4 7:4 0 132K 1 loop /snap/gtk2-common-themes/9 loop5 7:5 0 219M 1 loop /snap/gnome-3-34-1804/66 loop6 7:6 0 55,5M 1 loop /snap/core18/1988 loop7 7:7 0 276K 1 loop /snap/gnome-characters/570 loop8 7:8 0 161,4M 1 loop /snap/gnome-3-28-1804/128 loop9 7:9 0 16M 1 loop /snap/communitheme/1768 loop10 7:10 0 276K 1 loop /snap/gnome-characters/550 loop11 7:11 0 62,1M 1 loop /snap/gtk-common-themes/1506 loop12 7:12 0 217,9M 1 loop /snap/gnome-3-34-1804/60 loop13 7:13 0 140K 1 loop /snap/gtk2-common-themes/13 loop14 7:14 0 548K 1 loop /snap/gnome-logs/103 loop15 7:15 0 64,8M 1 loop /snap/gtk-common-themes/1514 loop16 7:16 0 55,4M 1 loop /snap/core18/1944 loop17 7:17 0 162,9M 1 loop /snap/gnome-3-28-1804/145 sda 8:0 0 931,5G 0 disk ├─sda1 8:1 0 11,2G 0 part [SWAP] ├─sda2 8:2 0 79,1G 0 part ├─sda3 8:3 0 136,9G 0 part ├─sda4 8:4 0 1K 0 part ├─sda5 8:5 0 352,2G 0 part └─sda6 8:6 0 352,2G 0 part sdb 8:16 0 931,5G 0 disk ├─sdb1 8:17 0 11,2G 0 part ├─sdb2 8:18 0 79,1G 0 part / ├─sdb3 8:19 0 136,9G 0 part /home ├─sdb4 8:20 0 1K 0 part ├─sdb5 8:21 0 353,7G 0 part └─sdb6 8:22 0 350,6G 0 part sr0 11:0 1 1024M 0 rom 0 ✓ 08:36:16 Сб фев 13Дело в том, что после кеаждой перезагрузки меняются примонтированные диски. сейчас они такие.. Теперь я презагружусь и покажу какие примонтировались снова.

Пользователь добавил сообщение 13 Февраля 2021, 08:43:45:

А это только-что

[ medusa@oleg-PC-O-E-M ~ ]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 62,1M 1 loop /snap/gtk-common-themes/1506 loop1 7:1 0 276K 1 loop /snap/gnome-characters/550 loop2 7:2 0 132K 1 loop /snap/gtk2-common-themes/9 loop3 7:3 0 55,5M 1 loop /snap/core18/1988 loop4 7:4 0 55,4M 1 loop /snap/core18/1944 loop5 7:5 0 219M 1 loop /snap/gnome-3-34-1804/66 loop6 7:6 0 217,9M 1 loop /snap/gnome-3-34-1804/60 loop7 7:7 0 276K 1 loop /snap/gnome-characters/570 loop8 7:8 0 98,4M 1 loop /snap/core/10823 loop9 7:9 0 548K 1 loop /snap/gnome-logs/103 loop10 7:10 0 956K 1 loop /snap/gnome-logs/100 loop11 7:11 0 21,3M 1 loop /snap/communitheme/1987 loop12 7:12 0 64,8M 1 loop /snap/gtk-common-themes/1514 loop13 7:13 0 161,4M 1 loop /snap/gnome-3-28-1804/128 loop14 7:14 0 97,9M 1 loop /snap/core/10583 loop15 7:15 0 16M 1 loop /snap/communitheme/1768 loop16 7:16 0 140K 1 loop /snap/gtk2-common-themes/13 loop17 7:17 0 162,9M 1 loop /snap/gnome-3-28-1804/145 sda 8:0 0 931,5G 0 disk ├─sda1 8:1 0 11,2G 0 part ├─sda2 8:2 0 79,1G 0 part / ├─sda3 8:3 0 136,9G 0 part ├─sda4 8:4 0 1K 0 part ├─sda5 8:5 0 352,2G 0 part └─sda6 8:6 0 352,2G 0 part sdb 8:16 0 931,5G 0 disk ├─sdb1 8:17 0 11,2G 0 part [SWAP] ├─sdb2 8:18 0 79,1G 0 part ├─sdb3 8:19 0 136,9G 0 part /home ├─sdb4 8:20 0 1K 0 part ├─sdb5 8:21 0 353,7G 0 part └─sdb6 8:22 0 350,6G 0 part sr0 11:0 1 1024M 0 rom 0 ✓ 08:42:31 Сб фев 13

Пользователь добавил сообщение 13 Февраля 2021, 08:45:46:

Т.е после каждой перезагрузке меняются примонтированные разделы. Может действительно имеет смысл переустановить GRUB2? Может у Вас есть такой опыт и вы провели бы меня по этому пути? Спасибо.

Пользователь добавил сообщение 13 Февраля 2021, 08:50:01:

И Вы наверное правы — я размазал GRUB. Но почему не грузится система, которую я копировал на новый диск? Ведь в ней то я ничего не менял.Спасибо.

« Последнее редактирование: 13 Февраля 2021, 08:50:01 от medusa_10001 »

mahinist

medusa_10001

Сделал. Ну а Вы может подскажете по теме? Спасибо.

andytux

после кеаждой перезагрузки меняются примонтированные диски

Т.е. ты не прочитал главную часть фразы: «…в данной конкретной сессии».
В добавок, прочитай это.
Все, что ты написал-нарисовал — наплевать и забыть.
Абсолютно точно, определись для себя, на какой диск собираешься устанавливать загрузчик.
Запускаешь систему. Смотришь, какое каноничесое имя получил требуемый диск в данную конкретную сессию. Условно для конкретики, предположим, что sda.
Уточняешь, какой раздел является системным (корневым). Предположим sda2.
Устанавливаешь на этот диск (устройство) груб:

sudo mount /dev/sda2 /mnt sudo grub-install --root-directory=/mnt /dev/sdaТеперь у тебя система и весь груб на одном диске (устройстве) — sda. Должен запускаться груб и загружаться система, даже если подключен только один этот диск.
Если нужен загрузчик на втором диске, повторяешь все это для второго диска.

почему не грузится система, которую я копировал на новый диск?

Что значит копировал? Просто скопировал файлы? Или клонировал (копировал) устройство.

Peter_I

Вообще копировать диск, с которого загрузилась система, неправильно, и весь диск копировать тоже не надо.
Надо загрузиться с чего-то другого и уже из системы, загруженной с этого другого, скопировать на новый диск
каталоги, но /proc, /dev, /run, /sys, /tmp не копировать, а только создать. Затем установить загрузчик
на новый диск, либо с этого другого, либо снова загрузиться со сарого и тогда установить, как тут говорили.
Что-то другое — это может быть какой-нибудь Live CD или установочный диск в режиме восстановления, если он
предусмотрен. Например, в Astra Linux он есть. Или же для полного копирования диска с разделами воспользоваться
clonzilla, она создаст образ старого диска в виде каталога, а потом распакует его на новый.

Печать

Страницы: [1] 2 Все Вверх

This document (000019919) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 15 SP2 Running on Microsoft Azure

Situation

After upgrading a gen2 VM running on Microsoft Azure to SLES 15 SP2, the system fails to boot and prints the following error to the Azure VM console:

 Loading Linux 5.3.18-24.49-default ... error: symbol `grub_file_filters' not found. Loading initial ramdisk ... error: symbol `grub_file_filters' not found. Press any key to continue...

Resolution

If the system was rebooted, the issue can be fixed with these steps:

1- Create a recovery disk and set up a SLES15 SP2 gen2 chroot environment as described here:

2- Install the secure-boot shim to the recovery disk:

/usr/sbin/shim-install

3- Swap out the VM’s OsDisk in the Azure Portal WebUI or azure cli with the recovery disk created in step 1:

az vm update -g <resource group> -n <vm name> —os-disk <recovery disk>

If the system was not rebooted after the upgrade, kindly run:

/usr/sbin/shim-install

Cause

The issue is escalated to SUSE Engineering and Microsoft.

Status

Reported to Engineering

Additional Information

Disclaimer

Document ID:000019919
Creation Date:
19-Mar-2021
Modified Date:22-Mar-2021
- SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com

Как правильно задавать вопросы

Правильно сформулированный вопрос и его грамотное оформление способствует высокой вероятности получения достаточно содержательного и по существу ответа. Общая рекомендация по составлению тем: 1. Для начала воспользуйтесь поиском форума. 2. Укажите версию ОС вместе с разрядностью. Пример: LM 19.3 x64, LM Sarah x32 3. DE. Если вопрос касается двух, то через запятую. (xfce, KDE, cinnamon, mate) 4. Какое железо. (достаточно вывод inxi -Fxz в спойлере (как пользоваться спойлером смотрим здесь)) или же дать ссылку на hw-probe 5. Суть. Желательно с выводом консоли, логами. 6. Скрин. Просьба указывать 2, 3 и 4 независимо от того, имеет ли это отношение к вопросу или нет. Так же не забываем об общих правилах Как пример вот

electra: Сообщения: 4; Зарегистрирован: 31 мар 2019, 18:04; Контактная информация:

Не устанавливается Manjaro с USB (проблема с GRUB)

31 мар 2019, 19:34

Записываю ISO c Manjaro на флеху, загружаюсь с нее и выдает:
error: symbol `grub_file_filters` not found
grub rescue>

slant: Сообщения: 4026; Зарегистрирован: 21 июн 2017, 18:09; Решено: 79; Благодарил (а): 50 раз; Поблагодарили: 1758 раз; Контактная информация:

Не устанавливается Manjaro с USB (проблема с GRUB)

31 мар 2019, 19:36

1. Какой именно ISO (их много у majaro — разные версии).
2. Как и чем записываете.

electra: Сообщения: 4; Зарегистрирован: 31 мар 2019, 18:04; Контактная информация:

Не устанавливается Manjaro с USB (проблема с GRUB)

31 мар 2019, 19:38

Решил проблему.
Записывал образ руфусом, что и вызвало ошибку, перезаписал образ в Etcher — все отлично загрузилось.

AlexZ: Сообщения: 1395; Зарегистрирован: 06 янв 2018, 21:06; Решено: 3; Откуда: Горно-Алтайск; Благодарил (а): 212 раз; Поблагодарили: 177 раз; Контактная информация:

Не устанавливается Manjaro с USB (проблема с GRUB)

31 мар 2019, 21:31

electra писал(а): ↑

31 мар 2019, 19:38

Записывал образ руфусом, что и вызвало ошибку, перезаписал образ в Etcher — все отлично загрузилось

В руфус при записи нужно было выбрать режим DD-образ (именно так записывает Etcher) — и все так же бы отлично загрузилось.

Проблема в том, что в Манджаро используется новый grub 2.03.2 и руфус (по каким-то причинам) не может его скачать для режима ISO-образ. Собственно касается это только Манджаро, остальные дистрибутивы отлично записываются в режиме ISO-образ, который рекомендуется и используется по умолчанию.

Источник

Environment

Situation

Resolution

Cause

Status

Additional Information

Disclaimer

Comments

Issue description

Steps to reproduce

Technical details

Workaround for booting with GRUB 2.04:

Regarding the GRUB regression (2.02 -> 2.04)

medusa_10001

ALiEN175

medusa_10001

ALiEN175

medusa_10001

ALiEN175

medusa_10001

AnrDaemon

medusa_10001

andytux

medusa_10001

mahinist

medusa_10001

andytux

Peter_I

Environment

Situation

Resolution

Cause

Status

Additional Information

Disclaimer

Не устанавливается Manjaro с USB (проблема с GRUB)

Не устанавливается Manjaro с USB (проблема с GRUB)

Не устанавливается Manjaro с USB (проблема с GRUB)

Не устанавливается Manjaro с USB (проблема с GRUB)

Workaround for booting with GRUB `2.04`: