[SOLVED] grub2 1:2.00beta2-1 problems

nemesis2all · 2012-03-18 20:04:20

I have the lts kernel and the regular arch kernel. All up to date. With new grub2 version I have 3 options. 1st is to boot from Arch Linux (lts). 2nd is to go to Advanced Sub-Menu where I can choose lts kernel or standard Arch Linux kernel. 3rd is for memtest.

Issues

Can I boot directly from a submenu? If so how do I do that?
If I set 0 as primary option it tries to boot lts, I keep lts as a backup and do not see how to have it automatically add the other other kernel to the main menu. Also when I try to boot to lts I get an error message saying error: file not found a few times and then press any key to continue. If I press a key it will hang and reboot, if I don't press a key in a few seconds it will boot to lts. Image of error attached below.
Also pacnew wanted me to add this "add_efi_memmap" to /etc/default/grub, I did even tho I don't use efi. I have tried it both ways and doesn't seem to effect anything good or bad.
Why do the fallback images not show up anymore? I assume they should be under the advanced sub-menu but just have the two options like I stated.

error message: http://imgur.com/H5KaT

/etc/default/grub http://pastie.org/3623314

/boot/grub/grub.cfg http://pastie.org/3623328

Any help would be appreciated.

Last edited by nemesis2all (2012-03-19 23:14:58)

Jristz · 2012-03-18 23:02:02

for me:
The same avove except for the error message
using a gpt-bios at begin of the all after init grub, stege 1 give me a error soo fast for notice (any sugestion for take or loger or any this?)
and the fallbacks kernels not appeared neither in the main menu nor the submenus

cfr · 2012-03-19 00:12:40

As above but more complicated and with additional issues:
- menu gives me two "Arch Linux" entries and two "Advanced options for Arch Linux" (but the latter is my fault and should now be corrected)
EDIT: the latter was my fault and is corrected; the former is probably my fault as well
- neither of the "Arch Linux" entries is the default kernel - it is trying to use the 26 lts kernel
EDIT: I deleted the files for the 26 lts under /boot/ as I believe these are obsolete (actually I moved them just in case)
the default entries for "Arch Linux" now both use the lts kernel (but are not labelled as such in the main menu)
booting the default kernel is still an "Advanced option"
- no fallback options

Menu is plain white on black (I guess because colour options are now commented out)
EDIT: and version is given as 1.99

Update created a new /boot/grub/grub.cfg.pacnew even though I use /boot/efi/ef/grub/grub.cfg for EFI. New config file was useless and referenced partitions which do not exist. I think it picked up a stale /boot/grub/grub.cfg. I regenerated the correct grub.cfg.

On choosing the default Arch (by inspecting the command lines using the 'e' option), I get an error that the initial ram disk cannot be found. Press any key. I press any key and it boots (despite not finding the ram disk?)
EDIT: I rebooted and I'm wrong about this. What I actually get is three error messages about "file not found..." followed by two messages related to booting (loading the initial file thing and then the ram disk) followed by "press any key to continue..."
I am pretty sure that the files not found are due to this code appearing in the generated grub.cfg:

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
}

I do not have ieee1275_fb.mod, vbe.mod or vga.mod under /boot/efi/efi/grub/. Comparing the contents here with the contents under /usr/lib/grub/x86_64-efi/, these files are not present there either. But it does make me wonder if the contents of /boot/efi/efi/grub/ is ever meant to be updated. I don't remember reading anything about this but certainly the contents there is different from that under /usr/lib/.... I'm not sure if this is because the installation of grub customises the contents of the directory or if it is because files have since been updated and mine are no longer current.

I am now getting much worse graphics corruption. I realise this doesn't sound like grub2's fault but apart from grub2 only 32 bit compatibility libraries, firefox-noscript and unetbootin were updated.

I added the add_efi_memmap as instructed - what does this do? Could it affect graphics in this way?
EDIT: I removed add_efi_memmap from my kernel command line and so far I'm not seeing any corruption. (I don't think this option is responsible per se - there is some sort of bug somewhere as I've had lesser amounts of this before - but my very initial impression is that the option makes it a *lot* worse.)

Assistance would be much appreciated. Can grub2 be safely downgraded? The menu is currently almost useless for me even after my editing - basically, I have to go to edit for the command line to see what an entry does. And I assume it won't boot my last choice any longer because it cannot preselect the option as it doesn't appear in the main menu but only buried in the sub-menu. Though I haven't actually tried waiting to see what it does. (I assume pressing enter which is my usual strategy would boot the currently selected option which obviously won't be my saved default.) Also, is there any reason for the white on black? It looks like yaboot!

Last edited by cfr (2012-03-19 01:26:49)

pouar · 2012-03-19 02:09:46

I think part of the solution is to use the `grub-install` command the same you'd use it to install grub2 on Arch Linux the 1st time, afterwhich another error pops up thats too quick to read, but at least it's less errors than before. still trying to figure out the rest while looking like an idiot.

Last edited by pouar (2012-03-19 03:12:42)

cfr · 2012-03-19 02:38:17

pouar wrote:

I think part of the solution is to use the `grub-install` command the same you'd use it to install grub2 on Arch Linux the 1st time, afterwhich another error pops up thats too quick to read, but at least it's less errors than before. still trying to figure out the rest while looking like an idiot.

Unfortunately, this isn't possible if you are booting in EFI mode because the command I used before no longer exists. grub_efi_x86_64-install was what I used to install grub initially and that is no longer part of grub2. Moreover, the manual page is unhelpfully silent and the script is complex (by my standards) and I'm not sure what it might do. I have no idea whether it is safe to use grub-install as a drop-in replacement for grub_efi_x86_64-install in the command I originally used. (I can't remember that but I could probably piece something together from the wiki - but that still tells me to use grub_efi_x86_64-install!)

I think more information about this update really should have been provided. This isn't a question of not checking the news or failing to read pacman's output. This is a question of things changing in ways which potentially break (and certainly mangle boot) with no hint as to what to do with them. I've been googling all evening but all I've found is some two year old bug reports for Ubuntu and a slightly more recent one for Debian which appears, however, entirely unrelated (so far as I can tell).

Currently, grub.cfg and modules for Arch are under /boot/efi/efi/grub and the shell is under /boot/efi/efi/boot. The current wiki instructions no longer use this pattern, either. For example, one possibility suggested is:

modprobe dm-mod
grub_efi_x86_64-install --root-directory=/boot/efi --boot-directory=/boot/efi/efi --bootloader-id=arch_grub --no-floppy --recheck --debug
modprobe efivars

Copy shell to one of various places (none of which is under /boot/efi/efi/grub) and use efibootmgr to install the boot entry.

I don't know if grub-install works the same way. I also don't know if I need to uninstall my current config (if that's even possible?) or let it be. I don't know if I should change the bootloader_id to arch_grub or, if I do, if I need to reuse efibootmgr. If so do I modify an existing entry, add one, or delete and add one?

I'm just very confused and panicking somewhat since my laptop doesn't have the best time booting in the first place...

Last edited by cfr (2012-03-19 02:53:51)

nemesis2all · 2012-03-19 03:19:00

cfr wrote:

Assistance would be much appreciated. Can grub2 be safely downgraded? The menu is currently almost useless for me even after my editing - basically, I have to go to edit for the command line to see what an entry does. And I assume it won't boot my last choice any longer because it cannot preselect the option as it doesn't appear in the main menu but only buried in the sub-menu. Though I haven't actually tried waiting to see what it does. (I assume pressing enter which is my usual strategy would boot the currently selected option which obviously won't be my saved default.) Also, is there any reason for the white on black? It looks like yaboot!

I downgraded for now and have pacman set to not upgrade grub2 until more information is available for this new version. The reason why it is white on black is because the /etc/default/grub.pacnew had the "arch" color combination commented out.

Hopefully no one goes down the path I did. I decided with the grub2 fun I'd try syslinux. Then when I tried to boot with syslinux I got some error about compression I believe. So eventually I ended up having to chroot and then install grub2 1.99. Today was interesting day for me in arch land and it seems like the wikis need to be updated in regards to grub2 and syslinux.

Last edited by nemesis2all (2012-03-19 03:35:10)

the.ridikulus.rat · 2012-03-19 08:39:17

I have updated the wiki for 2.00beta2 update. For the grub.cfg, can you guys try compiling https://www.dropbox.com/sh/jth3mchm3hob … src.tar.gz and post the status. This should fix the fallback initramfs entries. Only issue is that lts might come before actual core repo kernel (ie the menu ordering).

the.ridikulus.rat · 2012-03-19 11:37:12

nemesis2all wrote:

I have the lts kernel and the regular arch kernel. All up to date. With new grub2 version I have 3 options. 1st is to boot from Arch Linux (lts). 2nd is to go to Advanced Sub-Menu where I can choose lts kernel or standard Arch Linux kernel. 3rd is for memtest.
Issues
Can I boot directly from a submenu? If so how do I do that?
If I set 0 as primary option it tries to boot lts, I keep lts as a backup and do not see how to have it automatically add the other other kernel to the main menu.

Try the menuentry title instead if entry number, like

set default="Arch Linux Testing Kernel"

Also when I try to boot to lts I get an error message saying error: file not found a few times and then press any key to continue. If I press a key it will hang and reboot, if I don't press a key in a few seconds it will boot to lts. Image of error attached below.

That error is for graphics modules, which is just harmless info.

Also pacnew wanted me to add this "add_efi_memmap" to /etc/default/grub, I did even tho I don't use efi. I have tried it both ways and doesn't seem to effect anything good or bad.

Harmless. In bios systems, it has no effect.

Why do the fallback images not show up anymore? I assume they should be under the advanced sub-menu but just have the two options like I stated.

My bad, updated patch and PKGBUILD sent to Ronald.

the.ridikulus.rat · 2012-03-19 11:51:03

cfr wrote:

As above but more complicated and with additional issues:
- menu gives me two "Arch Linux" entries and two "Advanced options for Arch Linux" (but the latter is my fault and should now be corrected)
EDIT: the latter was my fault and is corrected; the former is probably my fault as well
- neither of the "Arch Linux" entries is the default kernel - it is trying to use the 26 lts kernel
EDIT: I deleted the files for the 26 lts under /boot/ as I believe these are obsolete (actually I moved them just in case)
the default entries for "Arch Linux" now both use the lts kernel (but are not labelled as such in the main menu)
booting the default kernel is still an "Advanced option"
- no fallback options

I accidentally deleted the fallback related code in /etc/grub.d/10_linux when I sent 2.00beta2 PKGBUILD to Ronald. I have now sent a 2.00beta2-2 src.tar.gz which should have the updated patch.

BTW submenu support has confused a lot of users, and its probably one of the most unreadable grub.cfg I have ever seen. In the new patch, I have disabled submenu support for Archlinux alone (not via an option in /etc/default/grub - no such submenu disabling option exists) directly in 10_linux .

Menu is plain white on black (I guess because colour options are now commented out)
EDIT: and version is given as 1.99

The actual bootloader update should be done by the user, not by pacman. You only updated the package, but not the files at /boot/grub and the mbr code in your drive.

Update created a new /boot/grub/grub.cfg.pacnew even though I use /boot/efi/ef/grub/grub.cfg for EFI. New config file was useless and referenced partitions which do not exist. I think it picked up a stale /boot/grub/grub.cfg. I regenerated the correct grub.cfg.

That grub.cfg is from my system. That is just an example grub.cfg intended to ensure the "backup" option for "boot/grub/grub.cfg" in grub2-common pkg works.
Of course it will be useless in your system. For your system, change the corresponding uuids.

On choosing the default Arch (by inspecting the command lines using the 'e' option), I get an error that the initial ram disk cannot be found. Press any key. I press any key and it boots (despite not finding the ram disk?)
EDIT: I rebooted and I'm wrong about this. What I actually get is three error messages about "file not found..." followed by two messages related to booting (loading the initial file thing and then the ram disk) followed by "press any key to continue..."
I am pretty sure that the files not found are due to this code appearing in the generated grub.cfg:
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
}
I do not have ieee1275_fb.mod, vbe.mod or vga.mod under /boot/efi/efi/grub/. Comparing the contents here with the contents under /usr/lib/grub/x86_64-efi/, these files are not present there either. But it does make me wonder if the contents of /boot/efi/efi/grub/ is ever meant to be updated. I don't remember reading anything about this but certainly the contents there is different from that under /usr/lib/.... I'm not sure if this is because the installation of grub customises the contents of the directory or if it is because files have since been updated and mine are no longer current.

These messages are harmless and can be ignored.

I am now getting much worse graphics corruption. I realise this doesn't sound like grub2's fault but apart from grub2 only 32 bit compatibility libraries, firefox-noscript and unetbootin were updated.
I added the add_efi_memmap as instructed - what does this do? Could it affect graphics in this way?
EDIT: I removed add_efi_memmap from my kernel command line and so far I'm not seeing any corruption. (I don't think this option is responsible per se - there is some sort of bug somewhere as I've had lesser amounts of this before - but my very initial impression is that the option makes it a *lot* worse.)

You mean add_efi_memmap is causing graphics corruption. Thats highly unlikely. I think you used 2.00~beta2's grub-mkconfig to generate grub.cfg which will work only with 2.00~beta2's grub.efi and its modules, not 1.99. Did you update the files at /boot/efi/efi/grub ? What is your system?

Update the files at /boot/efi/efi/grub, try grub-mkconfig with add_efi_memmap included, and check for any video corruption.

Assistance would be much appreciated. Can grub2 be safely downgraded? The menu is currently almost useless for me even after my editing - basically, I have to go to edit for the command line to see what an entry does. And I assume it won't boot my last choice any longer because it cannot preselect the option as it doesn't appear in the main menu but only buried in the sub-menu. Though I haven't actually tried waiting to see what it does. (I assume pressing enter which is my usual strategy would boot the currently selected option which obviously won't be my saved default.) Also, is there any reason for the white on black? It looks like yaboot!

I don't recommend downgrading. Yes submenu is useless and unnecessarily complicates things. You can change the "white on black", you should just read the documentation more.

the.ridikulus.rat · 2012-03-19 12:01:16

cfr wrote:

Unfortunately, this isn't possible if you are booting in EFI mode because the command I used before no longer exists. grub_efi_x86_64-install was what I used to install grub initially and that is no longer part of grub2. Moreover, the manual page is unhelpfully silent and the script is complex (by my standards) and I'm not sure what it might do. I have no idea whether it is safe to use grub-install as a drop-in replacement for grub_efi_x86_64-install in the command I originally used. (I can't remember that but I could probably piece something together from the wiki - but that still tells me to use grub_efi_x86_64-install!)

The wiki as been updated. Now there are no grub_efi_x86_64-install or grub_bios-install, just grub-install for all platform. That split was a hack (courtesy of me) which is no longer required in case of 2.00beta2.

I think more information about this update really should have been provided. This isn't a question of not checking the news or failing to read pacman's output. This is a question of things changing in ways which potentially break (and certainly mangle boot) with no hint as to what to do with them. I've been googling all evening but all I've found is some two year old bug reports for Ubuntu and a slightly more recent one for Debian which appears, however, entirely unrelated (so far as I can tell).

I was waiting for the updated packages to come into the repos before updating the wiki page. While I understand that this info should have been given when the updated landed in extra, updating the wiki without the updated packages might confuse some users who might try 2.00beta2 instructions on 1.99 packages.

Currently, grub.cfg and modules for Arch are under /boot/efi/efi/grub and the shell is under /boot/efi/efi/boot. The current wiki instructions no longer use this pattern, either.
I don't know if grub-install works the same way. I also don't know if I need to uninstall my current config (if that's even possible?) or let it be. I don't know if I should change the bootloader_id to arch_grub or, if I do, if I need to reuse efibootmgr. If so do I modify an existing entry, add one, or delete and add one?
I'm just very confused and panicking somewhat since my laptop doesn't have the best time booting in the first place...

Yes, now it is recommended to have the files under /boot/grub instead of /boot/efi/efi/grub (since prefix/platform subdir support has been added upstream). You can have both bios and uefi modules in /boot/grub without each overwriting the other, which was not possible in 1.99, hence the suggestion to use /boot/efi/efi/grub for uefi systems. There is nothing wrong if you wish to continue using /boot/efi/efi/grub, or using --bootloader-id=grub instead of arch_grub.

Even if you change the id to arch_grub, changing the boot entries is simple using efibootmgr. You might need to update your grub.cfg though.

the.ridikulus.rat · 2012-03-19 12:04:03

nemesis2all wrote:

I downgraded for now and have pacman set to not upgrade grub2 until more information is available for this new version. The reason why it is white on black is because the /etc/default/grub.pacnew had the "arch" color combination commented out.

Ideally it should have been commented out even before. It has just been corrected now. It won't take 3 min for you to uncomment those lines and regenerate grub.cfg .

Hopefully no one goes down the path I did. I decided with the grub2 fun I'd try syslinux. Then when I tried to boot with syslinux I got some error about compression I believe. So eventually I ended up having to chroot and then install grub2 1.99. Today was interesting day for me in arch land and it seems like the wikis need to be updated in regards to grub2 and syslinux.

The wiki has been updated, but it won't be updated unless the packages first hit the repo, since users might be confused with 2.00beta2 instructions in the wiki while the extra/grub2-* pkgs are still 1.99 .

the.ridikulus.rat · 2012-03-19 12:11:05

ChangeLog of the PKGBUILDs https://bugs.archlinux.org/task/27985#comment90186

My grub.cfg (common for both bios and uefi - working since 2.00beta1 till current bzr mainline - no submenu)

set _kernel_params="radeon.modeset=1 gpt loglevel=6 printk.time=y pcie_aspm=force elevator=noop"
set _systemd="init=/bin/systemd"
set _rootfstype="ext4"

## Linux Kernel Video Mode 1024x768x32, vga=824
set _video_mode="824"

insmod part_gpt
insmod fat
insmod ext2

set _hdd_disk_gpt_guid="XXXXXXX"

set _root_part_disk_id="XXXXXXX"
set _root_part_gpt_guid="XXXXXXX"
set _root_part_fs_uuid="XXXXXXX"

set _boot_part_disk_id="XXXXXXX"
set _boot_part_gpt_guid="XXXXXXX"
set _boot_part_fs_uuid="XXXXXXX"

set _uefisys_part_disk_id="XXXXXXX"
set _uefisys_part_gpt_guid="XXXXXXX"
set _uefisys_part_fs_uuid="XXXXXXX"

search --fs-uuid --no-floppy --set=_arch64_boot --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3 "${_boot_part_fs_uuid}"
search --fs-uuid --no-floppy --set=_arch64_root --hint-bios=hd0,gpt9 --hint-efi=hd0,gpt9 --hint-baremetal=ahci0,gpt9 "${_root_part_fs_uuid}"

search --fs-uuid --no-floppy --set=_uefisys_part --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 "${_uefisys_part_fs_uuid}"

if [ "${grub_platform}" == "efi" ]; then
	set _UEFI_ARCH="${grub_cpu}"
	
	if [ "${grub_cpu}" == "x86_64" ]; then
		set _SPEC_UEFI_ARCH="x64"
	fi
	
	if [ "${grub_cpu}" == "i386" ]; then
		set _SPEC_UEFI_ARCH="ia32"
	fi
fi

if [ "${grub_platform}" == "efi" ]; then
	set _kernel_params="${_kernel_params} add_efi_memmap none=UEFI_ARCH_${_UEFI_ARCH}"
fi

if [ "${grub_platform}" == "efi" ]; then
	insmod efi_gop
	# insmod efi_uga
	# insmod video_bochs
	# insmod video_cirrus
fi

if [ "${grub_platform}" == "pc" ]; then
	insmod vbe
	# insmod vga
	# insmod video_bochs
	# insmod video_cirrus
fi

if [ -e "(${_arch64_root})/usr/share/grub/unicode.pf2" ]; then
	_fontfile="(${_arch64_root})/usr/share/grub/unicode.pf2"
else
	if [ -e "(${_uefisys_part})/efi/grub_uefi_x86_64/fonts/unicode.pf2" ]; then
		_fontfile="(${_uefisys_part})/efi/grub_uefi_x86_64/fonts/unicode.pf2"
	else
		if [ -e "(${_arch64_boot})/grub_bios/fonts/unicode.pf2" ]; then
			_fontfile="(${_uefisys_part})/efi/grub_uefi_x86_64/fonts/unicode.pf2"
		fi
	fi
fi

insmod font

if loadfont "${_fontfile}" ; then
	insmod gfxterm
	
	set gfxmode="1024x768x32;auto"
	
	terminal_input console
	terminal_output gfxterm
	
	# set color_normal=light-blue/black
	# set color_highlight=light-cyan/blue
	
	# insmod png
	# insmod jpeg
	# insmod gfxmenu
	
	# background_image "(${_arch64_boot})/images/archlinux.png"
	
	set locale_dir="${prefix}/locale"
	set lang="en_US"
	
	# insmod gettext
fi

if [ "${grub_platform}" == "efi" ]; then
	set default="Arch Linux Testing Kernel"
	
	set _hidden_timeout="5"
fi

if [ "${grub_platform}" == "pc" ]; then
	set default="Boot Tianocore UDK DUET UEFI x86_64 - Partition"
	
	set _hidden_timeout="2"
fi

if sleep --verbose --interruptible "${_hidden_timeout}" ; then
	set timeout="0"
fi

set pager="1"
# set debug="all"

# menuentry "Arch Linux Testing Kernel" --users "keshav_pr,user" {

menuentry "Arch Linux Testing Kernel" {
	set gfxpayload="keep"
	set root="${_arch64_boot}"
	linux /vmlinuz-linux root=/dev/disk/by-partuuid/${_root_part_gpt_guid} ro rootfstype=${_rootfstype} ${_kernel_params} ${_systemd}
	initrd /initramfs-linux.img
}

menuentry "Arch Linux Testing Kernel Fallback" {
	set gfxpayload="keep"
	set root="${_arch64_boot}"
	linux /vmlinuz-linux root=/dev/disk/by-partuuid/${_root_part_gpt_guid} ro rootfstype=${_rootfstype} ${_kernel_params} ${_systemd}
	initrd /initramfs-linux-fallback.img
}

menuentry "Arch Linux Mainline Kernel" {
	set gfxpayload="keep"
	set root="${_arch64_boot}"
	linux /vmlinuz-linux-mainline root=/dev/disk/by-partuuid/${_root_part_gpt_guid} ro rootfstype=${_rootfstype} ${_kernel_params} ${_systemd}
	initrd /initramfs-linux-mainline.img
}

menuentry "Arch Linux Mainline Kernel Fallback" {
	set gfxpayload="keep"
	set root="${_arch64_boot}"
	linux /vmlinuz-linux-mainline root=/dev/disk/by-partuuid/${_root_part_gpt_guid} ro rootfstype=${_rootfstype} ${_kernel_params} ${_systemd}
	initrd /initramfs-linux-mainline-fallback.img
}

if [ "${grub_platform}" == "pc" ]; then
	
	menuentry "Boot Tianocore UDK DUET UEFI x86_64 - Partition" {
		search --fs-uuid --no-floppy --set=root 5FA3-2472
		chainloader +1
	}
	
	# menuentry "Boot Tianocore UDK DUET UEFI x86_64 - Memdisk" {
	# 	set root="${_arch64_boot}"
	# 	linux16 /memdisk_syslinux floppy ro nopass
	# 	initrd16 /Tianocore_UEFI_UDK_DUET_X86_64.img
	# }
	
fi

if [ "${grub_platform}" == "efi" ]; then
	
	menuentry "UEFI ${_UEFI_ARCH} Shell 2.0" {
		set root="${_uefisys_part}"
		chainloader /efi/shell/shell${_SPEC_UEFI_ARCH}.efi
	}
	
	menuentry "UEFI ${_UEFI_ARCH} Shell 1.0" {
		set root="${_uefisys_part}"
		chainloader /efi/shell/shell${_SPEC_UEFI_ARCH}_old.efi
	}
	
	menuentry "Microsoft Windows x86_64 UEFI-GPT" {
		set root="${_uefisys_part}"
		chainloader /efi/Microsoft/Boot/bootmgfw.efi
	}
	
fi

Last edited by the.ridikulus.rat (2012-03-19 12:12:06)

nemesis2all · 2012-03-19 15:27:02

Marking this post as solved although I have not tested the changes yet. I appreciate your responses and help very much in this matter the.ridikulus.rat.

Edit: Also I am fine with keeping the sub menus as I wasn't aware that you could use menu entry name instead of number. I did appreciate how the menu was cleaner with that setup. That's just my 2 cents in case you decide to add it back.

Last edited by nemesis2all (2012-03-19 15:45:02)

cfr · 2012-03-19 16:45:46

the.ridikulus.rat wrote:

.
BTW submenu support has confused a lot of users, and its probably one of the most unreadable grub.cfg I have ever seen. In the new patch, I have disabled submenu support for Archlinux alone (not via an option in /etc/default/grub - no such submenu disabling option exists) directly in 10_linux .

This gets my vote - even if it did make the menu "cleaner" in some sense.

The actual bootloader update should be done by the user, not by pacman. You only updated the package, but not the files at /boot/grub and the mbr code in your drive.
...
That grub.cfg is from my system. That is just an example grub.cfg intended to ensure the "backup" option for "boot/grub/grub.cfg" in grub2-common pkg works.
Of course it will be useless in your system. For your system, change the corresponding uuids.

I understand this now. I already deleted the file. However, I do think it is rather misleading. Some indication that the file is an example for another system would be helpful. Plus the fact that grub.cfg can be generated automatically makes the .pacnew file ambiguous. Usually, .pacnew files *need* to be merged but this one doesn't necessarily need to be.

These messages are harmless and can be ignored.

Is there some way of getting the machine to automatically ignore them so that boot can proceed?

You mean add_efi_memmap is causing graphics corruption. Thats highly unlikely. I think you used 2.00~beta2's grub-mkconfig to generate grub.cfg which will work only with 2.00~beta2's grub.efi and its modules, not 1.99. Did you update the files at /boot/efi/efi/grub ? What is your system?
Update the files at /boot/efi/efi/grub, try grub-mkconfig with add_efi_memmap included, and check for any video corruption.

OK I will try this later. At least, if I can figure out how. Should I delete the current contents of /boot/efi/efi/? I looked in the wiki to see if there was anything about upgrading grub2 but didn't see anything obvious.

System details at https://bbs.archlinux.org/viewtopic.php?id=131149. The only change is that I currently have 2G RAM as I'm waiting for a replacement memory module and my firmware has been updated to the latest available from Lenovo (as of a week or two ago, anyway). This means it is possible that some of the bugginess mentioned there no longer applies but I'd be reluctant to put that to the test...

I don't recommend downgrading. Yes submenu is useless and unnecessarily complicates things. You can change the "white on black", you should just read the documentation more.

I don't pretend to be anything like expert but I have read the documentation quite carefully where that means the wiki pages on uefi, grub2 etc. I've also read a bunch of other stuff on uefi and grub2 (and bios and gpt) just because I had so many problems getting uefi boot to work in the first place. I knew which lines affected the colours of the menu. But in the absence of documentation about the new version, I thought those lines might have been commented out in the .pacnew file for a reason.

Last edited by cfr (2012-03-19 16:59:03)

cfr · 2012-03-19 16:54:41

the.ridikulus.rat wrote:

The wiki as been updated. Now there are no grub_efi_x86_64-install or grub_bios-install, just grub-install for all platform. That split was a hack (courtesy of me) which is no longer required in case of 2.00beta2.

Thanks for the info. I *do* appreciate your help and expertise on this. If it were not for your earlier help, my computer would not be booting _at all_.

I was waiting for the updated packages to come into the repos before updating the wiki page. While I understand that this info should have been given when the updated landed in extra, updating the wiki without the updated packages might confuse some users who might try 2.00beta2 instructions on 1.99 packages.

But a message could have been included in the output of pacman or something posted on the news page pending the wiki update. Those seem to be fairly usual ways to convey urgently required information to users in these sorts of cases. I always scrutinise the output of pacman very carefully and note any instructions included there. Some sort of heads up would have made a huge difference to my level of alarm!

Yes, now it is recommended to have the files under /boot/grub instead of /boot/efi/efi/grub (since prefix/platform subdir support has been added upstream). You can have both bios and uefi modules in /boot/grub without each overwriting the other, which was not possible in 1.99, hence the suggestion to use /boot/efi/efi/grub for uefi systems. There is nothing wrong if you wish to continue using /boot/efi/efi/grub, or using --bootloader-id=grub instead of arch_grub.
Even if you change the id to arch_grub, changing the boot entries is simple using efibootmgr. You might need to update your grub.cfg though.

Since my machine can't seem to boot in bios mode without my reformatting its drive as mbr, the conflict isn't likely to be a problem for me. However, I will change it if the new locations are likely to be relatively stable as it will make it that much easier to follow documentation etc. without introducing avoidable errors on my part. From what you say, it sounds as if the locations are likely to be relatively stable. Is that right? (I won't hold you to this - just if you tell me they are likely to change next week, I won't bother.)

the.ridikulus.rat · 2012-03-19 16:56:06

nemesis2all wrote:

Marking this post as solved although I have not tested the changes yet. I appreciate your responses and help very much in this matter the.ridikulus.rat.
Edit: Also I am fine with keeping the sub menus as I wasn't aware that you could use menu entry name instead of number. I did appreciate how the menu was cleaner with that setup. That's just my 2 cents in case you decide to add it back.

The current way submenu is added by 10_linux is not ideal. It creates a simgle entry for the first kernel it detects, and then dumps all other kernels (even those different from the first one) into the submenu. Also it creates many duplicate entries. Since there is no "disable submenu" option in /etc/default/grub, I thought it is better to disable submenu for now. If you want fine-grained support ditch grub-mkconfig and manually maintain grub.cfg like I do. Thats also one of the reasons why I did not find out about the lack of fallback entries in grub-mkconfig generated grub.cfg .

cfr · 2012-03-20 01:12:50

So I did this:

modprobe dm-mod
modprobe efivars
grub-install --directory=/usr/lib/grub/x86_64-efi --target=x86_64-efi --root-directory=/boot/efi --boot-directory=/boot --bootloader-id=arch_grub --recheck --debug

This seemed to go OK. I currently have two entries for grub in the UEFI boot manager but I guess I can delete the old one once I'm sure this is working and rename the new one.

I think the warning in the wiki about it not being recommended if you also use bios no longer applies to the code immediately preceding it, by the way. But I might just be confused.

The wiki says:

The <root-directory>/<efi or EFI>/<bootloader-id>/grubx64.efi is an exact copy of <boot-directory>/grub/x86_64-efi/core.efi.

However:

$ diff /boot/efi/efi/arch_grub/grubx64.efi /boot/grub/x86_64-efi/grub.efi 
Binary files /boot/efi/efi/arch_grub/grubx64.efi and /boot/grub/x86_64-efi/grub.efi differ

$ ls -l /boot/efi/efi/arch_grub/grubx64.efi /boot/grub/x86_64-efi/grub.efi 
-rwxr-xr-x 1 root root 120320 Mar 20 00:44 /boot/efi/efi/arch_grub/grubx64.efi
-rw-r--r-- 1 root root 120320 Mar 20 00:44 /boot/grub/x86_64-efi/grub.efi

$ file /boot/efi/efi/arch_grub/grubx64.efi /boot/grub/x86_64-efi/grub.efi 
/boot/efi/efi/arch_grub/grubx64.efi: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows
/boot/grub/x86_64-efi/grub.efi:      PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows

Is this intended? I'm assuming diff is commenting on something more than the file permissions since it doesn't normally report files as different just because one is executable and the other not. Is the wiki out of date regarding this? Or is diff not to be trusted in this case? Does it not like the difference in file system?

The wiki says:

The --root-directory option mentions the mountpoint of UEFI SYSTEM PARTITION , --bootloader-id mentions the name of the directory used to store the grubx64.efi file and --boot-directory mentions the directory wherein the actual modules will be installed (and into which grub.cfg should be created).

But using the recommended command, the modules end up in /boot/grub/x86_64-efi while the instructions for generating grub.cfg, which use only the value from --boot-directory, cause grub.cfg to end up at /boot/grub.cfg. Should these all end up in the same directory? If so, should

# grub-mkconfig -o <boot-directory>/grub/grub.cfg

be

# grub-mkconfig -o <boot-directory>/grub/<target>/grub.cfg

or have I done something (else) wrong?

cfr · 2012-03-20 02:10:41

I rebooted OK with the new setup. At least, I assume it was the new setup. I didn't get errors about files not being found on reboot, at least. I copied grub.cfg everywhere I thought grub might look before rebooting. When I find out which is correct, I'll delete the others.

The grub menu doesn't seem as tidy as before. Initially, "grub..." etc. - the stuff which appears before the menu - is very large. The menu itself looks OKish but when I edit a command line (which I have to do to see what I'm booting), long lines are messed up. Not only to they extend beyond the frame around the screen, they seem to extend beyond the screen. The lines do wrap but not, it seems, soon enough. The lettering on this screen looks generally too large but not huge so maybe it is just another font and the textwidth isn't adjusted for it or something. The spacing of characters in long lines is also wrong and some characters are blank. Not odd characters but things like '0'. I know (roughly) what the command lines say but it is pretty difficult to figure out what they say in this screen. I don't remember it being like this with 1.99 but I didn't often edit the lines and I didn't need to check on what I was booting so I may just not have noticed.

Looking forward to the updated no-menu setup.

How difficult is it to keep grub.cfg up to date if you maintain it manually? Is there a way to tell when updates require or recommend changes to it?

the.ridikulus.rat · 2012-03-20 06:48:08

cfr wrote:

I think the warning in the wiki about it not being recommended if you also use bios no longer applies to the code immediately preceding it, by the way. But I might just be confused.

Yes, it no longer applies.

The wiki says:
The <root-directory>/<efi or EFI>/<bootloader-id>/grubx64.efi is an exact copy of <boot-directory>/grub/x86_64-efi/core.efi.
However:
$ diff /boot/efi/efi/arch_grub/grubx64.efi /boot/grub/x86_64-efi/grub.efi 
Binary files /boot/efi/efi/arch_grub/grubx64.efi and /boot/grub/x86_64-efi/grub.efi differ
Is this intended? I'm assuming diff is commenting on something more than the file permissions since it doesn't normally report files as different just because one is executable and the other not. Is the wiki out of date regarding this? Or is diff not to be trusted in this case? Does it not like the difference in file system?

Read it carefully. It says grubx64.efi and "core.efi" , not grub.efi .

But using the recommended command, the modules end up in /boot/grub/x86_64-efi while the instructions for generating grub.cfg, which use only the value from --boot-directory, cause grub.cfg to end up at /boot/grub.cfg. Should these all end up in the same directory? If so, should
# grub-mkconfig -o <boot-directory>/grub/grub.cfg
be
# grub-mkconfig -o <boot-directory>/grub/<target>/grub.cfg
or have I done something (else) wrong?

The file path is <boot-directory>/grub/grub.cfg , NOT <boot-directory>/grub/<target>/grub.cfg . I have added a note in the wiki regarding this.

This also means if you have same --boot-directory for BIOS and 64-bit UEFI, you will have bios modules in <boot-directory>/grub/i386-pc/ , 64-bit UEFI modules in <boot-directory>/grub/x86_64-efi/ , font files in <boot-directory>/grub/fonts/ , themes in <boot-directory>/grub/themes/ and a common grub.cfg at <boot-directory>/grub/grub.cfg .

the.ridikulus.rat · 2012-03-20 06:50:29

cfr wrote:

How difficult is it to keep grub.cfg up to date if you maintain it manually? Is there a way to tell when updates require or recommend changes to it?

I generally use bzr versions so i keep track of config changes in bzr repo and accordingly modify my grub.cfg . If you know bash well, it shouldn't be a problem a problem for you to manually maintain grub.cfg , since it is essentially a minimal sh script running within the grub environment. Look at my config file if you want any ideas.

the.ridikulus.rat · 2012-03-20 06:53:42

All those who are getting "file not found" error, you still have grub 1.99 in your /boot or UEFISYS. You shouldn't simply update your grub.cfg without updating your core.img or core.efi (using grub-install). You shouldn't be getting such errors if you are booting via 2.00beta2, since in that case grub2 will load all_video.mod and ignore the individual graphics modules.

Last edited by the.ridikulus.rat (2012-03-20 07:39:56)

Padfoot · 2012-03-20 07:29:21

the.ridikulus.rat wrote:

All those who are getting "file not found" error, you still have grub 1.99 in your /boot or UEFISYS. You shouldn't simply update your grub.cfg without updating your core.img or core.efi . You shouldn't be getting such errors if you are booting via 2.00beta2, since in that case grub2 will load all_video.mod and ignore the individual graphics modules.

Please correct me if I am wrong, but after install, I did the following:

# grub-mkconfig -o /boot/grub/grub.cfg

and

# mkinitcpio -p linux

and I still get the "file not found" errors. Also, even though I have not changed the boot hooks in my kernel image, and my grub kernel line still has the splash details, my fbsplash no longer works. It seems the theme can no longer be found, yet it is still exactly where it has always been.

While not 'vital', my seemless 100% graphic boot is now screwed. While not so important for my desktop, it does detract from the experience on my media centre machine (set to have xbmc splash screens from grub to boot to login - seemless boot)

Cheers.

Last edited by Padfoot (2012-03-20 07:30:19)

the.ridikulus.rat · 2012-03-20 07:38:51

@Padfoot: You forgot to do grub-install . Don't do grub-mkconfig without doing grub-install first. https://wiki.archlinux.org/index.php/GR … os_package

Padfoot · 2012-03-20 08:07:25

the.ridikulus.rat wrote:

@Padfoot: You forgot to do grub-install . Don't do grub-mkconfig without doing grub-install first. https://wiki.archlinux.org/index.php/GR … os_package

ummmmmm, I knew I would miss something so simple..lol..

Thankyou, my seemless boot is back. Just waiting for the 1:2.00beta2-2 package so I can get my custom /etc/grub.d/10_linux back.

Cheers.

cfr · 2012-03-20 12:03:40

Read it carefully. It says grubx64.efi and "core.efi" , not grub.efi .

Oops. Very sorry. It was late... Apologies.

Arch Linux

#1 2012-03-18 20:04:20

[SOLVED] grub2 1:2.00beta2-1 problems

#2 2012-03-18 23:02:02

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#3 2012-03-19 00:12:40

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#4 2012-03-19 02:09:46

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#5 2012-03-19 02:38:17

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#6 2012-03-19 03:19:00

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#7 2012-03-19 08:39:17

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#8 2012-03-19 11:37:12

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#9 2012-03-19 11:51:03

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#10 2012-03-19 12:01:16

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#11 2012-03-19 12:04:03

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#12 2012-03-19 12:11:05

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#13 2012-03-19 15:27:02

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#14 2012-03-19 16:45:46

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#15 2012-03-19 16:54:41

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#16 2012-03-19 16:56:06

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#17 2012-03-20 01:12:50

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#18 2012-03-20 02:10:41

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#19 2012-03-20 06:48:08

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#20 2012-03-20 06:50:29

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#21 2012-03-20 06:53:42

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#22 2012-03-20 07:29:21

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#23 2012-03-20 07:38:51

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#24 2012-03-20 08:07:25

Re: [SOLVED] grub2 1:2.00beta2-1 problems

#25 2012-03-20 12:03:40

Re: [SOLVED] grub2 1:2.00beta2-1 problems

Board footer