Tag Info

Hot answers tagged

26

For Ubuntu 12.04 LTS there is a specific option that can be set in /etc/default/grub. For example, if you want to have a 2 seconds timeout (thus avoiding hangs for unattended reboots) just add the following line in /etc/default/grub: GRUB_RECORDFAIL_TIMEOUT=2 Remember to run update-grub after that...


17

Here are instructions for Ubuntu 10.10, which are slightly different from prior versions. In file /etc/grub.d/00_header comment out the stupid check for a prior boot failure: ##if [ \${recordfail} = 1 ]; then ## set timeout=-1 ##else set timeout=${2} ##fi Then update: sudo update-grub Be aware that if there is a second drive with Linux attached, ...


7

Take a look at the Boot Info Script: # ./boot_info_script.sh boot_info_script version: 0.60 [17 May 2011] Identifying MBRs... Computing Partition Table of /dev/sda... Computing Partition Table of /dev/sdb... Searching sda1 for information... Searching sda2 for information... Searching sda3 for information... Searching sdb1 for information... ...


6

I came across this deeply unpleasant design oversight with Ubuntu Server 9.10. Your fix has helped me enormously. I just wanted to point out that the fix needed for 9.10 is different as there is no "make_timeout ()" function in the same file. For Ubuntu 9.10, go to the end of the same file (00_header) and change the following: if [ \${recordfail} = 1 ]; ...


5

Are you using a particular distribution? On Debian based distributions it would be as simple as adjusting /etc/default/rcS and set FSCKFIX to yes. If you want to force a full fsck after every boot, then you could simply write create an empty file named /forcefsck. Though I do not suggest you actually do this.


5

To answer my own question. Add: GRUB_CMDLINE_XEN="xen-pciback.hide=(06:00.0)" to: /etc/default/grub Then run update-grub to commit the changes.


5

Solution is to use a bios_grub partition, which is not the same as the /boot partition. By default the bios_grub partition is 1MiB, and it must be flagged bios_grub. Mine is the first partition on my disk. If your partition 2 is actually /boot as parted suggests, that would not be correct and you should make another 1MiB partition. With GPT and GRUB2 the ...


4

I stumbled onto the answer in the grub2 debian source package. It turns out that it does require a dump of the bootsector - so a separately packaged script might be useful. Here is a script (just a wrapper around the official function) that will tell you whether or not grub2 has been installed into the boot sector. It can be easily modified for similar uses. ...


4

You need to install GRUB to the MBR of both drives, and you need to do it in a way that GRUB considers each disk to be the first disk in the system. GRUB uses it's own enumeration for disks, which is abstracted from what the linux kernel presents. You can change which device it thinks is the first disk (hd0), by using a "device" line in the grub shell, like ...


4

Regarding to the /etc/grub.d/20_linux_xen script, you should define parameters for each image: GRUB_CMDLINE_LINUX_DEFAULT = basic kernel GRUB_CMDLINE_LINUX = basic kernel, included in "recovery" GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT = kernel using Xen hypervisor GRUB_CMDLINE_LINUX_XEN_REPLACE = kernel w/ Xen, incl. in "recovery" GRUB_CMDLINE_XEN_DEFAULT = ...


4

If there had been a power loss fsck will run anyway since the filesystem will not be marked as "clean". You can use tune2fs -c 1 /dev/sda to set the check-interval for ext2/3 to one. IMHO that should force an fsck on every boot.


3

After all, it was a Grub2 bug/issue with a degraded software raid array. Grub2 1.9x has issues with booting from a degraded array. Booting in rescue mode onto the system and letting the raid recover itself has fixed the issue for the original setup in question. Incidentally the setup works (at the moment: 2012-06-26) straight out of the box on Fedora 17, ...


3

RAID is still one of the gray areas of bootloaders IMHO. I recently built a RAID1 system and after a few hours trying to get LILO/GRUB/GRUB2 to detect my raid i gave up and just told it to use the first partition of the first HDD detected and made sure that if a HDD failed the next HDD was already lined up with the correct MBR/bootloader ect... So what it ...


3

If you absolutely have to do Software RAID, I'd suggest keeping /boot out of your encrypted/LVM partitions.


3

Create a separate RAID partition on each of your disks for /boot, then RAID1 it (RAID1, not RAID10). From my similar server: $ cat /proc/mdstat Personalities : [raid1] [raid6] [raid5] [raid4] md1 : active raid6 sdc2[3] sdd2[1] sdb2[0] sda2[2] 143090816 blocks level 6, 64k chunk, algorithm 2 [4/4] [UUUU] md0 : active raid1 sdc1[2] sda1[0] sdd1[3] ...


2

Have you considered installing a third drive to serve as just the boot drive? I have seen problems too with raid 1 lvm setups (on CentOS) not being able to boot the second drive. I think the problem stems from grub not being able to handle native lvm partitions, although I'm not entirely sure. Anyway, that's my answer: install a third small drive solely ...


2

I see you've already figured out how to accomplish this from a high level interface, but for the sake of anybody else who would like to learn how to configure software RAID10, I'll link to a fantastic article that goes into great depth on how to accomplish this. Rather than copy the article verbatim, I'll link to it instead. I used this article as a guide to ...


2

Don't forget GRUB2 is still in a development stage, so if you want to use it... it is at your own risk. Given the above, I think you'd be best advised to get the latest source and compile to see if that fixes any issues you may be seeing. You should be using version 1.9.6 at least, as the docs say, and make sue your raid is built using the v0.90 mdadm ...


2

Even with gpt you should still be able to install Grub on the drive (/dev/sda?) Try these commands: # grub_bios-install --boot-directory=/boot --no-floppy --recheck --debug /dev/sda # grub-mkconfig -o /boot/grub/grub.cfg it should make you a working grub install. You will however probably need to tune some options in the grub config files to get grub the ...


2

The vmlinuz images for the -virtual kernels stopped being named virtual a while ago (even though the package still is). In Ubuntu Lucid i386 they are named generic-pae, in amd64 they are named server. amd64: % apt-file list linux-image-2.6.32-37-virtual | grep vmlinuz linux-image-2.6.32-37-virtual: /boot/vmlinuz-2.6.32-37-server i386: % apt-file list ...


2

On the off-chance that some as inexperienced as me gets here via Google... the kernel reported was a KVM kernel which means my VPS is using shared kernel virtualisation (http://www.virtuatopia.com/index.php/An_Overview_of_Virtualization_Techniques#Shared_Kernel_Virtualization) and so I couldn't update the kernel from within the VPS. I contacted my host who ...


2

check the /etc/default/grub -- there should be an entry GRUB_DEFAULT=0, this refers to the menuentry you'll get. There are some glitches if you have submenus, but I've only run into that when I've added Xen kernels. Make sure you're not chaining from GRUB1 to GRUB2 menus (usually occurs from an upgrade), set the GRUB_DEFAULT and run 'grub-mkconfig -o ...


2

You are using the wrong install media. The Server Edition ISO does not use a graphical installer program. The server edition uses a text based menu based process for the install. From: https://help.ubuntu.com/13.10/serverguide/installing-from-cd.html Unlike the Desktop Edition, the Server Edition does not include a graphical installation program. The ...


1

As long as your raids are in the sda and sdb, especially were /boot is, you will not have any problem to reboot the system and it will work since you have did a shoutgun approach and installed grub on all your disks and grub is automatically sniff your drives to see where the /boot is.


1

I think you can just do grub-install /dev/sda grub-install /dev/sdb grub-install /dev/sdc grub-install /dev/sdd grub-install /dev/sde grub-install /dev/sdf grub-install /dev/sdg I can't really foresee what kind of problems you'll be having with grub's HD addressing, though, if your disks are mixed up.


1

Edit your /etc/grub.conf (or /boot/grub/menu.lst) on the /dev/sdb partition to reflect the necessary changes (sda replaced with sdb) Run chroot MOUNT_POINT_OF_/DEV/SDB Run grub-install /dev/sdb Test if you can that the setup is working as expected If you have issues with the boot, you can boot the system manually by using the grub shell at boot. EDIT: I ...


1

found it. apparently adding export DEBIAN_FRONTEND=noninteractive solves the problem, which is weird, because it doesn't work for samba installs, where --force-confdef is required.


1

At the grub menu, press 'e' to edit the menu entry and manually change the root= kernel argument to point to the raid array and boot from it manually. Then run update-grub, and it will see that you are currently booting from the raid array and configure itself to do so in the future. Also, you don't need to have a separate /boot partition.


1

Grub2 now has some understanding for md devices. It should be provided via loadable modules as necessary. Make sure that your system understands that it needs the md devices to boot. Ensure all arrays are listed in /etc/mdadm/mdadm.conf and run: # dpkg-reconfigure mdadm (nb: I recently has to something similar on my Debian system, but it ought to apply ...


1

I usually don`t do this with grub. The problem - which is not addressed in the referenced article is: If you loose sda (=hd0) your previous sdb (=hd1) will become sda (=hd0) which confuses grub: It was installed to sdb/hd1. I use dd from one partition to the other to copy the whole boot-partition (including grub-setup). And don`t forget to set up your ...



Only top voted, non community-wiki answers of a minimum length are eligible