grub missing os

rasoran · 2013-03-25 10:06:09

So I just install arch and now grub cannot recognize Fedora.

I have installed os-prober and grub can only find arch and windows7.

and I've tried and failed in manually inserting entries into grub, all of them resulting in an error and going back to the grub menu.

David Batson · 2013-03-25 12:27:03

I have both installed on my system, along with Mageia 2 and Windows 7. Instead of os-prober, I made an entry into /etc/grub.d/40_custom. This is for Fedora 18 that comes with GRUB2. Earlier versions of Fedora came with legacy GRUB(1).

https://bugzilla.redhat.com/show_bug.cgi?id=872826#c23

https://bugzilla.redhat.com/show_bug.cgi?id=872826#c99

Last edited by David Batson (2013-03-25 12:28:41)

rasoran · 2013-03-25 18:33:58

I tried

menuentry "OS using grub2" {
        insmod xfs
        search --set=root --label OS1 --hint hd0,msdos7
        configfile /boot/grub2/grub.cfg
     }

to no avail.
I have Fedora 17 installed but are you sure it was GRUB Legacy? Im pretty sure it was GRUB2.

David Batson · 2013-03-25 21:12:50

rasoran wrote:

I have Fedora 17 installed but are you sure it was GRUB Legacy? Im pretty sure it was GRUB2.

A little Googling shows you are quite right. Poor memory on my part.

Can you see the Fedora 17 partition and the files in /boot/* ? Are they on the same hard drive as Arch, and you have not added a hard drive since installing Fedora 17?

Perhaps there is a problem with a UUID having changed.

I am using Arch's GRUB2 for Fedora 18, and previously for Fedora 17. I'll boot into Arch and see what I currently have for Fedora (18).

EDIT: Here is my Arch /etc/grub.d/40_custom file (with relevant entries).

#!/bin/sh
exec tail -n +3 $0
# 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.
menuentry "Fedora 18 Gnome" {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos6'
	configfile /boot/grub2/grub.cfg
}

You should look for the /boot/grub2/grub.cfg file on your Fedora 17 partition from within Arch.

I have these files in Fedora 18 /boot/

# ls -1
System.map-3.8.1-201.fc18.x86_64
System.map-3.8.2-206.fc18.x86_64
System.map-3.8.3-203.fc18.x86_64
config-3.8.1-201.fc18.x86_64
config-3.8.2-206.fc18.x86_64
config-3.8.3-203.fc18.x86_64
grub2
initramfs-3.8.1-201.fc18.x86_64.img
initramfs-3.8.2-206.fc18.x86_64.img
initramfs-3.8.3-203.fc18.x86_64.img
initrd-plymouth.img
vmlinuz-3.8.1-201.fc18.x86_64
vmlinuz-3.8.2-206.fc18.x86_64
vmlinuz-3.8.3-203.fc18.x86_64

And these files below are in Fedora 18 /boot/grub2/
Entries 1, 4, 5, & 6 are folders. Entries 2 & 3 are files.

# ls -1
fonts
grub.cfg
grubenv
i386-pc
locale
themes

# blkid
{edited out irrelevant lines}
/dev/sda6: LABEL="Fedora" UUID="fdc058c0-3a5b-4b7a-a736-a380206e83a2" TYPE="ext4"

Note that the hard drive is 0 (hd0) {only have 1 hard drive installed atm}
Note that msdos6 corresponds to /sda6

# fdisk -l

Disk /dev/sda: 320.1 GB, 320072933376 bytes, 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xad0a92f6

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048     2459647     1228800    7  HPFS/NTFS/exFAT
/dev/sda2         2459648   297459711   147500032    7  HPFS/NTFS/exFAT
/dev/sda3       297475605   604659711   153592053+   f  W95 Ext'd (LBA)
/dev/sda4       604659712   625139711    10240000    7  HPFS/NTFS/exFAT
/dev/sda5       297475668   389608379    46066356   83  Linux
/dev/sda6       399863808   502263807    51200000   83  Linux
/dev/sda7       502265856   604659711    51196928   83  Linux
/dev/sda8       389608443   399857849     5124703+  82  Linux swap / Solaris

Last edited by David Batson (2013-03-25 21:39:15)

rasoran · 2013-03-26 17:50:44

I don't know how to access my Fedora's /boot but here are some outputs

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

Generating grub.cfg ...
Found linux image: /boot/vmlinuz-linux
Found initrd image: /boot/initramfs-linux.img
Found Windows 7 (loader) on /dev/sda2
Found Fedora release 17 (Beefy Miracle) on /dev/mapper/vg_olas-lv_root
done

$ dmesg

[ 4250.896252] EXT4-fs (sda3): unable to read superblock
[ 4250.899536] EXT4-fs (sda3): unable to read superblock
[ 4250.902767] EXT4-fs (sda3): unable to read superblock
[ 4250.906048] REISERFS warning (device sda3): sh-2006 read_super_block: bread failed (dev sda3, block 8, size 1024)
[ 4250.906064] REISERFS warning (device sda3): sh-2006 read_super_block: bread failed (dev sda3, block 64, size 1024)
[ 4250.906069] REISERFS warning (device sda3): sh-2021 reiserfs_fill_super: can not find reiserfs on sda3
[ 4250.910014] XFS (sda3): bad magic number
[ 4250.910036] XFS (sda3): SB validate failed
[ 4250.917335] FAT-fs (sda3): bogus number of reserved sectors
[ 4250.917344] FAT-fs (sda3): Can't find a valid FAT filesystem
[ 4250.920765] FAT-fs (sda3): bogus number of reserved sectors
[ 4250.920772] FAT-fs (sda3): Can't find a valid FAT filesystem
[ 4250.947714] NTFS-fs error (device sda3): read_ntfs_boot_sector(): Primary boot sector is invalid.
[ 4250.947726] NTFS-fs error (device sda3): read_ntfs_boot_sector(): Mount option errors=recover not used. Aborting without trying to recover.
[ 4250.947731] NTFS-fs error (device sda3): ntfs_fill_super(): Not an NTFS volume.
[ 4250.950869] MINIX-fs: unable to read superblock
[ 4250.953492] attempt to access beyond end of device
[ 4250.953501] sda3: rw=0, want=3, limit=2
[ 4250.953506] hfs: unable to find HFS+ superblock
[ 4250.956533] You didn't specify the type of your ufs filesystem

mount -t ufs -o ufstype=sun|sunx86|44bsd|ufs2|5xbsd|old|hp|nextstep|nextstep-cd|openstep ...

>>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old
[ 4250.962621] hfs: can't find a HFS filesystem on dev sda3.

my arch is /dev/sda1 and /dev/sda4

# blkid

/dev/sda2: LABEL="OS" UUID="62BE5D8DBE5D5A9D" TYPE="ntfs" 
/dev/sda5: LABEL="DATA" UUID="08C4599CC4598CB6" TYPE="ntfs" 
/dev/sda6: UUID="881e8959-52dc-4463-9de7-481d89a25c1a" TYPE="ext4" 
/dev/sda7: UUID="xx7Xo9-Psd7-0wO3-3QWb-iqFo-JNY5-0NGlgM" TYPE="LVM2_member" 
/dev/sda1: UUID="deff7182-f14b-4c08-b619-59bb55643738" TYPE="ext3" 
/dev/sda4: UUID="ae53255b-972d-48ce-8540-890b21e8d022" TYPE="ext3" 
/dev/mapper/vg_olas-lv_swap: UUID="eb3566fc-4409-4e72-aaf1-a40dcda89ad2" TYPE="swsuspend" 
/dev/mapper/vg_olas-lv_home: UUID="7b140451-dd5c-4699-ae07-8e65600c17e3" TYPE="ext4" 
/dev/mapper/vg_olas-lv_root: LABEL="_Fedora-17-x86_6" UUID="97a95929-242f-4578-9016-9bfd22bb14e2" TYPE="ext4"

# fdisk -l

Disk /dev/sda: 640.1 GB, 640135028736 bytes, 1250263728 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x343771f7

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1       447678464   479135743    15728640   83  Linux
/dev/sda2   *    52430848   447678463   197623808    7  HPFS/NTFS/exFAT
/dev/sda3       552536064  1250260991   348862464    f  W95 Ext'd (LBA)
/dev/sda4       479135744   552536063    36700160   83  Linux
/dev/sda5       552538112   559650815     3556352    7  HPFS/NTFS/exFAT
/dev/sda6       559652864   560676863      512000   83  Linux
/dev/sda7       560678912  1250260991   344791040   8e  Linux LVM

Partition table entries are not in disk order

Disk /dev/mapper/vg_olas-lv_swap: 8321 MB, 8321499136 bytes, 16252928 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/mapper/vg_olas-lv_home: 291.1 GB, 291051143168 bytes, 568459264 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/mapper/vg_olas-lv_root: 53.7 GB, 53687091200 bytes, 104857600 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

David Batson · 2013-03-26 18:37:39

Unable to read superblock seems like you might have run into the fragility mentioned in the thread I linked to.

Try to install grub again in Fedora using the method here:
https://bugzilla.redhat.com/show_bug.cgi?id=872826#c99

You should boot a rescue disk to reinstall GRUB to Fedora. Install GRUB to the root partition / of Fedora, not the MBR, so as not to mess up Arch's GRUB.

EDIT: Note that Fedora's grub.cfg is in a different path than Arch's. This is important when rebuilding grub.cfg.
Arch: /boot/grub/grub.cfg
Fedora: /boot/grub2/grub.cfg

Last edited by David Batson (2013-03-26 18:40:13)

cfr · 2013-03-27 00:11:59

Why would you install both Arch's and Fedora's grub? Especially since grub does not like being installed to partitions. I thought the recommended strategy was to manage grub from *one* distro. (Whichever you prefer.)

Aren't those disk errors concerning the extended partition? Why are you trying to mount /dev/sda3 if it is an extended partition, as it seems to be?

WonderWoofy · 2013-03-27 01:06:00

cfr wrote:

Why would you install both Arch's and Fedora's grub? Especially since grub does not like being installed to partitions. I thought the recommended strategy was to manage grub from *one* distro. (Whichever you prefer.)

This is not just the recommended strategy, this is the correct way to do it.

David Batson · 2013-03-27 02:28:54

I apologize for an error in my previous post. The link I provided has the correct procedure, but I hastily wrote (incorrectly) to install Fedora's grub to the root partition of Fedora. Actually you are only installing grub tools with the lines:

grub2-install --grub-setup=/bin/true /dev/sdX
grub2-mkconfig -o /boot/grub2/grub.cfg

(note the X in sdX has to reflect your system's correct hard drive)

As pointed out in that bug report I linked, if Fedora was installed in addition to a previously installed linux distro, and one did not want Fedora to overwrite the previous distro's GRUB, there is a way to have Fedora not install grub at installation time. However Fedora will not be bootable until the grub files are installed for Fedora, and this is what I was getting at.

In all the OSes install GRUB tools but disable installing GRUB in
bootsector, so you'll have menu.lst and grub.cfg available for use.
Also disable os-prober use by setting:
`GRUB_DISABLE_OS_PROBER=true'
in /etc/default/grub
Then write a grub.cfg (/mnt/boot/grub2/grub.cfg):
menuentry "OS using grub2" {
insmod xfs
search --set=root --label OS1 --hint hd0,msdos8
configfile /boot/grub2/grub.cfg
}

It is possible the above isn't necessary for the OP, but I believe his Fedora install got corrupted by using blocklists. I was hoping that the procedure I linked to would straighten it up.

cfr · 2013-03-27 03:45:39

I don't think that is correct for Fedora 17. That bug concerns a change in the configuration for Fedora 18. (I use Fedora 17 on my work machine, it never automatically upgrades grub for reasons I haven't bothered to investigate, and I just use grub2-mkconfig the way I would on Arch if I didn't maintain grub.cfg manually there.)

David Batson · 2013-03-27 09:48:03

I had Fedora 17 installed until Fedora 18 came out. Yes there are differences in GRUB2's behavior between them. The following bug report discusses issues with Fedora 17's grub. It was linked to by Till Bubeck in the bug report link I posted above.

It is grubby that updates grub for Fedora when new kernels are installed.

https://bugzilla.redhat.com/show_bug.cgi?id=804835

Till Bubeck re: Fedora 17 wrote:

Description of problem:
When choosing to install GRUB2 into boot partition (in contrast to MBR, which is normally used), then no error message appeare, but the system is unable to boot. After BIOS-Power-On it shows only "GRUB" and does not continue.
Explanation: I use a seperate partition (sda1) which only has a GRUB-1.99 to device which partition to chainload. I installed F17 onto sda7 and choose sda7 in the master grub. Instead of getting the second GRUB of F17 I only get "GRUB". This concept normally works for anything including F16.
Version-Release number of selected component (if applicable):
Fedora-17-Beta-TC2-x86_64-DVD.iso
How reproducible:
always
Steps to Reproduce:
1. Install F17
2. Choose "Install GRUB onto Boot Partition"
3. reboot

Actual results:
GRUB after BIOS Power On.
Expected results:
Grub working

cfr · 2013-03-28 00:33:31

Yes but if you use the *recommended* way - or, as WonderWoofy puts it, the correct way - none of this applies. You pick *one* distro to install grub to. Then you manage grub from that distro. You don't install grub to a partition or install a second grub or chainload one grub from the other or anything of the sort.

You are making this way more complicated than it should be as far as I can tell. What makes you think the OP wants to install grub in a way which is considered inherently fragile, not to say completely broken by upstream?

About grubby: all I can say is that grubby does not update grub.cfg on my machine. /boot/grub2/grub.cfg never gets automatically updated. (It does generate a grub.cfg but it doesn't put it anywhere useful so I don't really see the point.)

David Batson · 2013-03-28 08:07:18

Part of what you are saying I agree with. It is possible we are misunderstanding one another. I am only talking about BIOS grub, as I haven't delved into UEFI yet. Yes I agree that you should have a primary grub that boots other distros. However, how do you boot those other distros in a multiboot setup? I have seen 3 methods described for BIOS boot (not counting GPT).

1) Chainload another distro (worked well in the past, but has problems with grub2 because of image sizes).
2) Use a few lines plus configfile in /etc/grub.d/40_custom to boot another distro. This requires grub tools to be installed. This is the method I am using now.
3) Use kernel in /etc/grub.d/40_custom to boot another distro from it's /boot/grub/i386-pc/core.img file. This still requires some pieces of grub to be installed.

In the first method, the other distros would have their own grub installed to their root partition (normally).

In the second method, grub tools is installed for each distro so they could create their own core.img, grub.cfg, and other grub files. Works pretty well, but some of the custom options in grub may not work with each distro.

The third method I am less familiar with (haven't tried it). Apparently no problems with different numbered versions of grub. Yet I don't understand how kernel updates are handled among all the distros using this method in a multiboot setup.

See also: https://wiki.archlinux.org/index.php/GR … .img_alone
This is Arch's way of doing what I was describing with Fedora in previous posts.

cfr wrote:

Yes but if you use the *recommended* way - or, as WonderWoofy puts it, the correct way - none of this applies. You pick *one* distro to install grub to. Then you manage grub from that distro. You don't install grub to a partition or install a second grub or chainload one grub from the other or anything of the sort.

So, what boot section do you have in /etc/grub.d/40_custom in the method above to boot other distros? Any example?
Here is what I've got, using method #2 above (note that Mageia is using legacy grub installed to the root partition of Mageia).

#!/bin/sh
exec tail -n +3 $0
# 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.
menuentry "Microsoft Windows 7 BIOS-MBR" {
    insmod part_msdos
    insmod ntfs
    insmod search_fs_uuid
    insmod ntldr     
    search --fs-uuid --no-floppy --set=root 44EAEFD5EAEFC172
    ntldr (${root})/bootmgr
}
# (1) Mageia 2
menuentry "Mageia 2 KDE" {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd0,msdos5)'
	chainloader +1
}
# (2) Fedora 18
menuentry "Fedora 18 Gnome" {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos6'
	configfile /boot/grub2/grub.cfg
}
# (3) Bodhi Enlightenment
menuentry "Bodhi Enlightenment" {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='hd1,msdos6'
	configfile /boot/grub/grub.cfg
}

An interesting tidbit I ran across...

Mads Kiilerich wrote:

> Without --force GRUB2 will outright refuse to be installed anywhere other than
> in the MBR.
Correct. Partitioned devices will usually have 31k free where core.img can be stored without force. Partitions do not have that space and the boot loader can thus only be installed with the unreliable blocklist method that requires force.
An external chain loader that points to core.img will however not use the blocklist and will thus be reliable.

cfr · 2013-03-28 23:39:39

For example:

menuentry 'Finnix' --class finnix --class gnu-linux --class gnu --class os {
        load_video
        set gfxpayload=keep
        insmod xzio
        insmod part_gpt
        insmod ext2
        set root='hd0,gpt3'
        search --no-floppy --fs-uuid --set=root baa1a541-4aaf-4763-a180-ceb98b98200f
        echo    'Loading Finnix ...'
        linux   /isolinux/linux64 root=UUID=baa1a541-4aaf-4763-a180-ceb98b98200f ro quiet add_efi_memmap
        echo    'Loading initial ramdisk ...'
        initrd  /isolinux/initrd.xz
}

Are you saying that this would not work if this were not the EFI version of grub? (Appropriately adapted, obviously.)

I don't see the need for a separate configuration file. grub.cfg should include entries for all distros. At least, it certainly can do. Why complicate things? (Well, I mean, this is grub, so obviously things are going to be complicated but why complicate them beyond necessity?)

The only thing I can see in favour of installing grub tools for each distro would be to enable automatic updates to grub.cfg on kernel update. But that strikes me as somewhat fragile since there is no guarantee that the versions of grub in the different distros will be kept in sync. Again, managing grub from one distro avoids this problem.

Last edited by cfr (2013-03-28 23:42:22)

David Batson · 2013-03-29 03:59:44

cfr wrote:

Are you saying that this would not work if this were not the EFI version of grub? (Appropriately adapted, obviously.)

It works. I just tested it by copying the appropriate entry from my Fedora 18 /boot/grub2/grub.cfg file into Arch's /etc/grub.d/40_custom file and rebuilding Arch's grub with grub-mkconfig -o /boot/grub/grub.cfg.

# (4) Fedora 18 Test
menuentry 'Fedora (3.8.3-203.fc18.x86_64)' --class fedora --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-fdc058c0-3a5b-4b7a-a736-a380206e83a2' {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos6'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos6 --hint-efi=hd0,msdos6 --hint-baremetal=ahci0,msdos6  fdc058c0-3a5b-4b7a-a736-a380206e83a2
	else
	  search --no-floppy --fs-uuid --set=root fdc058c0-3a5b-4b7a-a736-a380206e83a2
	fi
	echo 'Loading Fedora (3.8.3-203.fc18.x86_64)'
	linux	/boot/vmlinuz-3.8.3-203.fc18.x86_64 root=UUID=fdc058c0-3a5b-4b7a-a736-a380206e83a2 ro rd.md=0 rd.dm=0  rd.luks=0 vconsole.keymap=us resume=/dev/sda8 rhgb quiet quiet LANG=en_US.UTF-8
	echo 'Loading initial ramdisk ...'
	initrd /boot/initramfs-3.8.3-203.fc18.x86_64.img
}

cfr wrote:

I don't see the need for a separate configuration file. grub.cfg should include entries for all distros. At least, it certainly can do. Why complicate things? (Well, I mean, this is grub, so obviously things are going to be complicated but why complicate them beyond necessity?)

grub.cfg does not include entries for other distros by default unless os-prober is installed. If os-prober is installed and operational, then os-prober puts other os boot lines in /etc/grub.d/30_os-prober. These entries get added to grub.cfg when grub.cfg is rebuilt. You are not supposed to edit grub.cfg manually as seen below (you probably know this already).

grub.cfg wrote:

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

cfr wrote:

The only thing I can see in favour of installing grub tools for each distro would be to enable automatic updates to grub.cfg on kernel update. But that strikes me as somewhat fragile since there is no guarantee that the versions of grub in the different distros will be kept in sync. Again, managing grub from one distro avoids this problem.

I have found os-prober to be wanting. I have used it in the past, but it hasn't done a very good job. If you don't use os-prober, then you have to add the appropriate os boot lines to /etc/grub.d/40_custom manually and rebuild grub.cfg. How does one know exactly what to put in there if grub tools does not create a grub.cfg file for all the distros that you want to boot? If you are running a multiboot setup, then I believe you are using os-prober to accomplish this. os-prober make work well for you, but it hasn't worked that well for me to create the grub menu that I want.

I was manually adding entries to /etc/grub.d/40_custom using copy/paste until it was pointed out to me (in the Fedora bug report I linked to) that using config file was easier and took less maintenance. Only need to run grub-mkconfig -o /boot/grub/grub.cfg in the primary grub after a kernel update takes place in any distro you have installed.

cfr · 2013-03-29 05:17:43

I am not using os-prober. I maintain grub.cfg manually on my Arch machine (including anything I want for other distros).

Is there any guarantee that if the version of grub on your primary distro does not match the version of grub in Fedora, say, that it will all still work?

I'm not sure what you mean in asking how one knows what to put in 40_custom. Whatever you enter will go verbatim into grub.cfg so it is just a question of writing a stanza appropriately. It is just a config file, after all. there's nothing especially mysterious about it. (grub.cfg when auto-generated is a nightmare, I grant you, but 40_custom need not be and should not be.)

In any case, how people prefer to maintain the config is a matter of taste. But not installing grub itself for more than one distro is not. And not installing it to a partition, rather than a disk, is not. The rest is just what you find most convenient.

Incidentally, there is no such warning about not editing in my grub.cfg . There is actually no issue with maintaining this manually on Arch because Arch will never update the file automatically.

David Batson · 2013-03-29 08:01:56

cfr wrote:

In any case, how people prefer to maintain the config is a matter of taste. But not installing grub itself for more than one distro is not. And not installing it to a partition, rather than a disk, is not. The rest is just what you find most convenient.

Again, I am not talking about installing the entire grub package, mainly the part that generates grub.cfg when any flavor of linux is installed.

cfr wrote:

Incidentally, there is no such warning about not editing in my grub.cfg . There is actually no issue with maintaining this manually on Arch because Arch will never update the file automatically.

Now that's really strange since that warning came from my Arch's grub2 grub.cfg file.

GRUB2 ArchWiki wrote:

Manually creating grub.cfg
Warning: Editing this file is strongly not recommended. The file is generated by the grub-mkconfig command, and it is best
to edit your /etc/default/grub or one of the scripts in the /etc/grub.d folder.

https://wiki.archlinux.org/index.php/GR … g_grub.cfg

Too tired from lack of sleep to comment any more just now.

Last edited by David Batson (2013-03-29 08:02:23)

cfr · 2013-03-29 16:35:29

David Batson wrote:

cfr wrote:
Incidentally, there is no such warning about not editing in my grub.cfg . There is actually no issue with maintaining this manually on Arch because Arch will never update the file automatically.
Now that's really strange since that warning came from my Arch's grub2 grub.cfg file.

Not especially strange. As I say, I maintain grub.cfg manually. So it is not auto-generated and there is no reason it should look like yours .

GRUB2 ArchWiki wrote:
Manually creating grub.cfg
Warning: Editing this file is strongly not recommended. The file is generated by the grub-mkconfig command, and it is best
to edit your /etc/default/grub or one of the scripts in the /etc/grub.d folder.
https://wiki.archlinux.org/index.php/GR … g_grub.cfg
Too tired from lack of sleep to comment any more just now.

Yes, I know it says that. But it will not be overwritten *on Arch*. So if you manage grub from Arch, manually editing it is safe. If, on the other hand, you manage grub from another distro, it is not. (Well, it would be for me on Fedora because it never gets updated automatically but I think that's a bug rather than a feature so I wouldn't trust to it.)

I used to use the auto-generated grub.cfg but I had numerous issues whereas I've had none since managing it manually. Moreover, I *understand* (more-or-less) my grub.cfg which is not something I could say about the auto-generated version. Furthermore, I don't have to worry about the contents of /etc/default/grub or /etc/grub.d/*. That's all just irrelevant.

I'm not recommending this. I think whatever works for you is good. Just this is what has worked well for me.

David Batson · 2013-03-29 22:04:56

cfr wrote:

Is there any guarantee that if the version of grub on your primary distro does not match the version of grub in Fedora, say, that it will all still work?

As they say, there is more than one way to skin a cat. One of these should work: kernel (linux), configfile, multiboot, or chainload.

cfr wrote:

In any case, how people prefer to maintain the config is a matter of taste.

Yes, to each his own.

cfr wrote:

But not installing grub itself for more than one distro is not. And not installing it to a partition, rather than a disk, is not.

I disagree with this point. Grub can be installed to a partition without the blocklist problem if core.img is called from /boot/grug/i386-pc/core.img directly rather than being called from the blocklist. While this may not be the preferred method, it is nevertheless an acceptable method (IMO). Just tried it - and it works. When I select the 'Fedora 18 Gnome Test' entry in Arch's Grub, It loads Fedora's grub menu, from which you can boot Fedora. Here is the appropriate entry in /etc/grub.d/40_custom to use multiboot to boot another grub2 system.

menuentry "Fedora 18 Gnome Test" {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos6'
	multiboot /boot/grub2/i386-pc/core.img
}

Last edited by David Batson (2013-03-29 22:05:56)

Arch Linux

#1 2013-03-25 10:06:09

grub missing os

#2 2013-03-25 12:27:03

Re: grub missing os

#3 2013-03-25 18:33:58

Re: grub missing os

#4 2013-03-25 21:12:50

Re: grub missing os

#5 2013-03-26 17:50:44

Re: grub missing os

#6 2013-03-26 18:37:39

Re: grub missing os

#7 2013-03-27 00:11:59

Re: grub missing os

#8 2013-03-27 01:06:00

Re: grub missing os

#9 2013-03-27 02:28:54

Re: grub missing os

#10 2013-03-27 03:45:39

Re: grub missing os

#11 2013-03-27 09:48:03

Re: grub missing os

#12 2013-03-28 00:33:31

Re: grub missing os

#13 2013-03-28 08:07:18

Re: grub missing os

#14 2013-03-28 23:39:39

Re: grub missing os

#15 2013-03-29 03:59:44

Re: grub missing os

#16 2013-03-29 05:17:43

Re: grub missing os

#17 2013-03-29 08:01:56

Re: grub missing os

#18 2013-03-29 16:35:29

Re: grub missing os

#19 2013-03-29 22:04:56

Re: grub missing os

Board footer