The update-grub command is just a script which runs the grub-mkconfig tool to generate a grub.cfg file. See the Archlinux GRUB documentation. It refers to the following:
# grub-mkconfig -o /boot/grub/grub.cfg
Most people coming to this from a search engine are probably wondering, "why do I get this error?":
warning: File system `ext2' doesn't support embedding.
warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
error: will not proceed with ...
This is a feature, and is used for system maintainance: it allows a sysadmin to recover a system from messed-up initialization files or change a forgotten password.
This post in the Red Hat mailing list explains some things:
In Unix-like systems, init is the first process to be run, and the
ultimate ancestor of all processes ever run. It's responsible ...
This answer is for others out there that DocSalvager's answer doesn't work for.
I followed DocSalvager's use of ls to find the correct hard drive partition. In my case it was (hd0,msdos5).
Then I executed the following commands to get back to the normal grub boot loader screen.
grub rescue> set boot=(hd0,msdos5)
grub rescue> set prefix=(hd0,msdos5)...
Ok, I booted up my UEFI box to check. First clue, near the top of dmesg. This shouldn't appear if you're booted via BIOS:
[ 0.000000] efi: EFI v2.31 by American Megatrends
[ 0.000000] efi: ACPI=0xd8769000 ACPI 2.0=0xd8769000 SMBIOS=0xd96d4a98
[ 0.000000] efi: mem00: type=6, attr=0x800000000000000f, range=[0x0000000000000000-...
After some research based on the answers of @fpmurphy and @hesse, also based on a comprehensive thread at ubuntuforums and on Fedora Wiki, I found out how to reduce the font size of GRUB2.
Choose a font, in this example I chose DejaVuSansMono.ttf
Convert the font in a format GRUB understands:
sudo grub2-mkfont -s 14 -o /boot/grub2/DejaVuSansMono.pf2 /usr/...
Here's what to do:
Boot a live distro. This can be your Ubuntu installation disc or another one such as Knoppix.
Find the drive/partition where you have installed your root filesystem. To do this you can open a terminal and run either sudo parted -l or sudo fdisk -l. If you can't tell, then edit your question and add the output.
Assuming that your ...
If you've booted using the UEFI firmware as opposed to using BIOS firmware then your system should make the EFI NVRAM variables available in:
When booting using a BIOS (or the BIOS emulation mode of UEFI firmware) then these variables aren't available.
In fact, as @Santropedro pointed out, the path
You are getting the warning because you are installing grub to a partition instead of the MBR. This means grub can not be embedded in the unused space between the MBR and the first partition. Instead it has to have the list of blocks that /boot/grub/core.img resides in placed into the MBR. This setup is subject to being broken by things like defrag and so ...
The boot process can't find the root partition (the part of the disk, that contains the information for starting up the system), so you have to specify its location yourself.
I think you have to look at something like this article: how-rescue-non-booting-grub-2-linux
short: in this grub rescue> command line type
... to list all available devices, ...
Managing EFI Boot Loaders for Linux: Using ELILO
It's really difficult for me to decide which part of that to copy+paste because it's all really good, so I'll just ask you please to read it.
Authored and maintains both gdisk and rEFInd.
But before you do I'd like to comment a little on it. The ELILO link above is to one of the many ...
Recovering from a grub rescue crash ...
grub rescue> does not support cd, cp or any other filesystem commands except its own variation of ls which is really a kind of find command.
So first, had to find the partition with the /boot directory containing the vmlinuz and other boot image files...
grub rescue> ls
(hd0,4) (hd0,3) (hd0,2) (hd0,1)
Fixed the efibootmgr errors by mounting the Boot variables for efibootmgr :
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
And then efibootmgr gave me errors about space :
Could not prepare Boot variable: No space left on device
Fixed that by deleting dump files :
# rm /sys/firmware/efi/efivars/dump-*
And then ran the usual
Edit the /etc/default/grub and replace GRUB_DEFAULT=0 with GRUB_DEFAULT=saved
your command will be:
sudo grub-reboot "$(grep -i 'windows' /boot/grub/grub.cfg|cut -d"'" -f2)" && sudo reboot
a pretty function in your ~/.bashrc will look like
# reboot directly to ...
After a day of research, I can now answer my own Question: yes it is possible, and you can even use that partition as /boot and store your kernels/initramfs/etc. there.
Grub >= 2.00 (1.98 and 1.99 do not work)
Grub must be installed from a Linux kernel, that has support for EFI variables (CONFIG_EFI_VARS compiled in or as module efivars)
I ran across the same issue just now, and found another workaround. Basically, it involves making the hosts /run directory available to the guest.
First, we mount /run where it can be accessed by the guest. I will assume that your install partition is mounted at /mnt
mount --bind /run /mnt/hostrun
Then, we chroot into the guest, and ...
This is usually fixed by running the scripts detect the installed operating systems and generate the boot loader's (grub2 in this case) configuration file. On CentOS 7, that should be grub2-mkconfig.
Check that windows is detected. Run grub2-mkconfig but discard its output:
$ sudo grub2-mkconfig > /dev/null
Generating grub configuration file ...
In order for the grub-reboot command to work, several required configuration changes must be in place:
The default entry for grub must be set to saved. One possible location for this is the GRUB_DEFAULT= line in /etc/default/grub
Use grub-set-default to set your default entry to the one you normally use.
Update your grub config (e.g. update-grub).
I found the answer.
Put Arch DVD or Flash Drive and boot it again.
Retry following commands :
mount /dev/sda1 /mnt #sda1 is `boot` partition
mount /dev/sda3 /mnt/home #sda3 is `home` partition
pacman -S os-prober
grub-mkconfig -o /boot/grub/grub.cfg
Strictly speaking, UUID is not addressing at all.
Addressing is very, very simple: read drive X sector Y - or else. Read memory address Z - or else. Addressing is simple, fast, leaves not much room for interpretation, and it's everywhere.
UUID is not addressing. Instead it's searching, finding, sometimes waiting for devices to appear, and also ...
Your system has mechanisms for running and debugging (like the init parameter) and it probably has security mechanisms to stop unwanted users from taking advantage of them. These are features, not bugs.
The bootloader is responsible for starting the OS. OS security obviously doesn't apply at that point. You could just load a different kernel, initrd, root ...
In GRUB2 the preferred method of setting framebuffer resolution (to GRUB and the kernel) is to edit /etc/default/grub to contain these variables:
GRUB_GFXMODE sets the resolution of GRUB
GRUB_GFXPAYLOAD_LINUX controls whether the linux kernel will keep the resolution, and if you want the linux kernel to use different resolution than GRUB, you can set it ...
Seems like you should do grub2-mkconfig in the chroot instead of doing it outside. grub2-mkconfig uses grub-probe to detect real devices associated with mount points, while airootfs (archiso's rootfs) is loaded into the ram and doesn't have a canonical path.
So before installing grub and generating config, do this first:
arch-chroot /mnt /bin/bash
Windows will overwrite the boot sector whenever you install it, upgrade it to a new version, or use tools like bootrec /fixmbr, bootrec /fixboot, or the older fdisk /mbr. In general, install Windows first, then Linux. The boot sector will stay put until you do one of the things above. (And perhaps there are also other ways to write onto the MBR.) But, if you ...
Basic Boot Process
Grub reads its disk, md, filesystem, etc. code from the MBR.
Grub finds its /boot partition, and reads the rest of itself out of it. Including the config, and any modules the config specifies need loading.
Grub follows the instructions in the config, which typically tell it to load a kernel and initramfs into memory, and execute the ...
If the two disks are /dev/sda and /dev/sdb, run both grub-install /dev/sda and grub-install /dev/sdb. Then both drives will be able to boot alone.
Make sure that your Grub configuration doesn't hard-code disks like (hd0), but instead searches for the boot and root filesystems' UUIDs.
I'm not aware of support in Grub to declare two disks as being in a RAID-...
Following up on the answer by @terdon - when you do the test-step, and grub2-mkconfig does not find the Windows partition. Next, make sure you have the "ntfs-3g" package installed, so that your Linux system can read the Windows partition(s).
sudo yum install ntfs-3g
After installing that, when you run
sudo grub2-mkconfig > /dev/null
... you should ...
Not sure if the installer does it by default, but if (once the system is booted) you run:
# dpkg-reconfigure -plow grub-pc
just hit enter until you're prompted for "GRUB install devices", then you can select the MBRs of both drives.
Here is a screenshot of the relevant screen in Debian Jessie (8.3), with GRUB2 version 2.02~beta2-22+deb8u1. This shows the ...