On a newly installed Debian Testing system, I installed Fedora 13 in a different partition but chose not to install the boot loaded since I wanted to use Debian's boot loader for all OSes.
Now when I do update-grub in Debian, it detects all OSes installed in the hard drives connected to the system (Windows XP, Windows 7, Fedor 9), but does not detect Fedora 13. I had to manually add the stanza lines for F13 to get its option in the grub boot list.
I am using LVM. F13 is installed with its / mounted on /dev/mapper/vg1-lv8 and its boot on /dev/sdc5. Update-grub appears to miss detecting the kernels in /dev/sdc5 altogether. Any idea why is that? Is there is a bug in Fedora 13?
Thanks.
On Monday 12 July 2010 08:08 AM, H.S. wrote:
I am using LVM. F13 is installed with its / mounted on /dev/mapper/vg1-lv8 and its boot on /dev/sdc5. Update-grub appears to miss detecting the kernels in /dev/sdc5 altogether. Any idea why is that? Is there is a bug in Fedora 13?
I think its because grub 1 doesn't have LVM support. If you need LVM support install grub2.
On 12/07/10 12:50 PM, Suvayu Ali wrote:
On Monday 12 July 2010 08:08 AM, H.S. wrote:
I am using LVM. F13 is installed with its / mounted on /dev/mapper/vg1-lv8 and its boot on /dev/sdc5. Update-grub appears to miss detecting the kernels in /dev/sdc5 altogether. Any idea why is that? Is there is a bug in Fedora 13?
I think its because grub 1 doesn't have LVM support. If you need LVM support install grub2.
Yes, that is the one I am using: grub-pc 1.98+20100706-1 GRand Unified Bootloader, version 2 (PC/BIOS version) (sorry I skipped mentioning this earlier).
Note that boot partitions for both distros (F13 and Debian) are on non-LVM partitions precisely because even grub2 may not handle LMV boot partitions properly ... not sure about this though so just wanted to be cautious. Debian's /boot is on /dev/sdc3 and Fedora 13's /boot is on /dev/sdc5. Their other partitions (/, /usr, /home) all are on LVM volumes.
On 07/12/2010 10:20 AM, H.S. wrote:
On 12/07/10 12:50 PM, Suvayu Ali wrote:
On Monday 12 July 2010 08:08 AM, H.S. wrote:
I am using LVM. F13 is installed with its / mounted on /dev/mapper/vg1-lv8 and its boot on /dev/sdc5. Update-grub appears to miss detecting the kernels in /dev/sdc5 altogether. Any idea why is that? Is there is a bug in Fedora 13?
I think its because grub 1 doesn't have LVM support. If you need LVM support install grub2.
Yes, that is the one I am using: grub-pc 1.98+20100706-1 GRand Unified Bootloader, version 2 (PC/BIOS version) (sorry I skipped mentioning this earlier).
Note that boot partitions for both distros (F13 and Debian) are on non-LVM partitions precisely because even grub2 may not handle LMV boot partitions properly ... not sure about this though so just wanted to be cautious. Debian's /boot is on /dev/sdc3 and Fedora 13's /boot is on /dev/sdc5. Their other partitions (/, /usr, /home) all are on LVM volumes.
/dev/sdc5 is an extended partition. IIRC, update-grub only checks primary partitions--primarily because your BIOS can't boot anything in an extended partition, either. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, C2 Hosting ricks@nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Which is worse: ignorance or apathy? I don't know. Who cares? - ----------------------------------------------------------------------
On Monday 12 July 2010 10:20 AM, H.S. wrote:
On 12/07/10 12:50 PM, Suvayu Ali wrote:
On Monday 12 July 2010 08:08 AM, H.S. wrote:
I am using LVM. F13 is installed with its / mounted on /dev/mapper/vg1-lv8 and its boot on /dev/sdc5. Update-grub appears to miss detecting the kernels in /dev/sdc5 altogether. Any idea why is that? Is there is a bug in Fedora 13?
I think its because grub 1 doesn't have LVM support. If you need LVM support install grub2.
Yes, that is the one I am using: grub-pc 1.98+20100706-1 GRand Unified Bootloader, version 2 (PC/BIOS version) (sorry I skipped mentioning this earlier).
Note that boot partitions for both distros (F13 and Debian) are on non-LVM partitions precisely because even grub2 may not handle LMV boot partitions properly ... not sure about this though so just wanted to be cautious. Debian's /boot is on /dev/sdc3 and Fedora 13's /boot is on /dev/sdc5. Their other partitions (/, /usr, /home) all are on LVM volumes.
In that case that should have worked. (even grub 1 would work with that)
I am not well versed with grub, but have you checked whether you have the correct "device.map" file?
On 12/07/10 01:49 PM, Suvayu Ali wrote:
I am not well versed with grub, but have you checked whether you have the correct "device.map" file?
How do I check that? device.map file is something that I have never had to deal with before (Red Hat (7, 8, 9), Fedora Core and Fedora till ver. 9, or Debian). Do I need to change something in it on a newly installed Fedora system?
On Monday 12 July 2010 11:10 AM, H.S. wrote:
On 12/07/10 01:49 PM, Suvayu Ali wrote:
I am not well versed with grub, but have you checked whether you have the correct "device.map" file?
How do I check that? device.map file is something that I have never had to deal with before (Red Hat (7, 8, 9), Fedora Core and Fedora till ver. 9, or Debian). Do I need to change something in it on a newly installed Fedora system?
My device.map looks like this,
grub]# cat /boot/grub/device.map # this device map was generated by anaconda (hd0) /dev/sda
So for sdc there should be an entry like this
(hd2) /dev/sdc
However I think Rick's response has a valid point, and might be the real reason update-grub didn't work.
On 12/07/10 01:42 PM, Rick Stevens wrote:
/dev/sdc5 is an extended partition. IIRC, update-grub only checks primary partitions--primarily because your BIOS can't boot anything in an extended partition, either.
hmm .. then why does it detect OSes on my LVM volumes? I don't think BIOS can boot from an LVM volume, can it?
Also, among the other OSes it detected on my system, here are a couple of counter examples: -------------------------------------------------- menuentry "Debian, with Linux 2.6.32-100601-1394 (on /dev/sdc6)" { insmod part_msdos insmod ext2 set root='(/dev/sdc,msdos5)' search --no-floppy --fs-uuid --set 9db23921-b7bc-4f1f-8b31-306f2126af0e linux /vmlinuz-2.6.32-100601-bijli-1394 root=UUID=0300e89b-ae92-43f5-b1f0-0d53c2b589ca ro vga=792 quiet initrd /initrd.img-2.6.32-100601-bijli-1394 } menuentry "Fedora release 9 (Sulphur) (on /dev/sdc13)" { insmod part_msdos insmod ext2 set root='(/dev/sdc,msdos13)' search --no-floppy --fs-uuid --set 3cfc63bf-9e84-49a3-90ad-3fa623141200 linux /boot/vmlinuz-2.6.26.6-79.fc9.i686 root=/dev/sdc13 } --------------------------------------------------
Both logical partitions.
Besides, I don't think BIOS is booting from the partitions at all on my system. It just checks the mbr of sdc, which is set by grub, and the computer gets pointed to my /boot partition where vmlinuz continues to boot. Isn't that broadly what happens?
On 07/12/2010 11:39 AM, Tom Horsley wrote:
On Mon, 12 Jul 2010 10:42:01 -0700 Rick Stevens wrote:
/dev/sdc5 is an extended partition.
I boot from extended partitions all the time. I've never noticed that the bios cared.
Directly from the BIOS or via an intermediary such as grub or lilo? Most multi-OS users use some intermediary boot manager. I don't believe a BIOS can boot an extended partition unless the one in question is the first partition inside the extended partition and the extended partition has its "bootable" flag set. Even then, I'm not sure...haven't tried it in a LONG time.
In the OP's case, /dev/sdc5 would probably the first partition inside the extended partition, so it might work. I know grub can boot things inside an extended partition, but I don't think the grub-update (or whatever) utility checks extended partitions. I could be wrong (and often am :-)). ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, C2 Hosting ricks@nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - If this is the first day of the rest of my life... - - I'm in BIG trouble! - ----------------------------------------------------------------------
On 12/07/10 11:08 AM, H.S. wrote:
On a newly installed Debian Testing system, I installed Fedora 13 in a different partition but chose not to install the boot loaded since I wanted to use Debian's boot loader for all OSes.
Now when I do update-grub in Debian, it detects all OSes installed in the hard drives connected to the system (Windows XP, Windows 7, Fedor 9), but does not detect Fedora 13. I had to manually add the stanza lines for F13 to get its option in the grub boot list.
I am using LVM. F13 is installed with its / mounted on /dev/mapper/vg1-lv8 and its boot on /dev/sdc5. Update-grub appears to miss detecting the kernels in /dev/sdc5 altogether. Any idea why is that? Is there is a bug in Fedora 13?
Thanks.
I have no idea what has changed since I posted this. But now udpate-grub is detecting F13! I haven't really changed anything in grub and nor in os-prober. I just did a upgrade of my Debian system last night and now this stuff works. I wish I knew what has changed.
On 07/12/2010 11:39 AM, H.S. wrote:
On 12/07/10 01:42 PM, Rick Stevens wrote:
/dev/sdc5 is an extended partition. IIRC, update-grub only checks primary partitions--primarily because your BIOS can't boot anything in an extended partition, either.
hmm .. then why does it detect OSes on my LVM volumes? I don't think BIOS can boot from an LVM volume, can it?
Also, among the other OSes it detected on my system, here are a couple of counter examples:
menuentry "Debian, with Linux 2.6.32-100601-1394 (on /dev/sdc6)" { insmod part_msdos insmod ext2 set root='(/dev/sdc,msdos5)' search --no-floppy --fs-uuid --set 9db23921-b7bc-4f1f-8b31-306f2126af0e linux /vmlinuz-2.6.32-100601-bijli-1394 root=UUID=0300e89b-ae92-43f5-b1f0-0d53c2b589ca ro vga=792 quiet initrd /initrd.img-2.6.32-100601-bijli-1394 } menuentry "Fedora release 9 (Sulphur) (on /dev/sdc13)" { insmod part_msdos insmod ext2 set root='(/dev/sdc,msdos13)' search --no-floppy --fs-uuid --set 3cfc63bf-9e84-49a3-90ad-3fa623141200 linux /boot/vmlinuz-2.6.26.6-79.fc9.i686 root=/dev/sdc13 }
Both logical partitions.
Besides, I don't think BIOS is booting from the partitions at all on my system. It just checks the mbr of sdc, which is set by grub, and the computer gets pointed to my /boot partition where vmlinuz continues to boot. Isn't that broadly what happens?
Yes, but even though grub can boot /dev/sdc5, I don't think the update utility you're using to update grub.conf _checks_ extended partitions to put appropriate entries in the config file. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, C2 Hosting ricks@nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Reality: A crutch for those who can't handle science fiction - ----------------------------------------------------------------------
On Mon, Jul 12, 2010 at 1:49 PM, Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
On Monday 12 July 2010 10:20 AM, H.S. wrote:
On 12/07/10 12:50 PM, Suvayu Ali wrote:
On Monday 12 July 2010 08:08 AM, H.S. wrote:
I am using LVM. F13 is installed with its / mounted on /dev/mapper/vg1-lv8 and its boot on /dev/sdc5. Update-grub appears to miss detecting the kernels in /dev/sdc5 altogether. Any idea why is that? Is there is a bug in Fedora 13?
I think its because grub 1 doesn't have LVM support. If you need LVM support install grub2.
Yes, that is the one I am using: grub-pc 1.98+20100706-1 GRand Unified Bootloader, version 2 (PC/BIOS version) (sorry I skipped mentioning this earlier).
Note that boot partitions for both distros (F13 and Debian) are on non-LVM partitions precisely because even grub2 may not handle LMV boot partitions properly ... not sure about this though so just wanted to be cautious. Debian's /boot is on /dev/sdc3 and Fedora 13's /boot is on /dev/sdc5. Their other partitions (/, /usr, /home) all are on LVM volumes.
In that case that should have worked. (even grub 1 would work with that)
I am not well versed with grub, but have you checked whether you have the correct "device.map" file?
device.map is only used at install time.
On Mon, Jul 12, 2010 at 1:42 PM, Rick Stevens ricks@nerd.com wrote:
On 07/12/2010 10:20 AM, H.S. wrote:
On 12/07/10 12:50 PM, Suvayu Ali wrote:
On Monday 12 July 2010 08:08 AM, H.S. wrote:
I am using LVM. F13 is installed with its / mounted on /dev/mapper/vg1-lv8 and its boot on /dev/sdc5. Update-grub appears to miss detecting the kernels in /dev/sdc5 altogether. Any idea why is that? Is there is a bug in Fedora 13?
I think its because grub 1 doesn't have LVM support. If you need LVM support install grub2.
Yes, that is the one I am using: grub-pc 1.98+20100706-1 GRand Unified Bootloader, version 2 (PC/BIOS version) (sorry I skipped mentioning this earlier).
Note that boot partitions for both distros (F13 and Debian) are on non-LVM partitions precisely because even grub2 may not handle LMV boot partitions properly ... not sure about this though so just wanted to be cautious. Debian's /boot is on /dev/sdc3 and Fedora 13's /boot is on /dev/sdc5. Their other partitions (/, /usr, /home) all are on LVM volumes.
/dev/sdc5 is an extended partition. IIRC, update-grub only checks primary partitions--primarily because your BIOS can't boot anything in an extended partition, either.
You must be remembering incorrectly. I had a netbook a few months ago that I used for tests where I had swap on sda1 and five different installs on sda5-sda9.
On Mon, Jul 12, 2010 at 2:39 PM, H.S. hs.samix@gmail.com wrote:
On 12/07/10 01:42 PM, Rick Stevens wrote:
/dev/sdc5 is an extended partition. IIRC, update-grub only checks primary partitions--primarily because your BIOS can't boot anything in an extended partition, either.
hmm .. then why does it detect OSes on my LVM volumes? I don't think BIOS can boot from an LVM volume, can it?
Also, among the other OSes it detected on my system, here are a couple of counter examples:
menuentry "Debian, with Linux 2.6.32-100601-1394 (on /dev/sdc6)" { insmod part_msdos insmod ext2 set root='(/dev/sdc,msdos5)' search --no-floppy --fs-uuid --set 9db23921-b7bc-4f1f-8b31-306f2126af0e linux /vmlinuz-2.6.32-100601-bijli-1394 root=UUID=0300e89b-ae92-43f5-b1f0-0d53c2b589ca ro vga=792 quiet initrd /initrd.img-2.6.32-100601-bijli-1394 } menuentry "Fedora release 9 (Sulphur) (on /dev/sdc13)" { insmod part_msdos insmod ext2 set root='(/dev/sdc,msdos13)' search --no-floppy --fs-uuid --set 3cfc63bf-9e84-49a3-90ad-3fa623141200 linux /boot/vmlinuz-2.6.26.6-79.fc9.i686 root=/dev/sdc13 }
grub2 can boot from an lvm'd /boot; it needs an "insmod lvm".
On 13/07/10 01:35 AM, Tom H wrote:
grub2 can boot from an lvm'd /boot; it needs an "insmod lvm".
Aha! Wonderful news. I have just started using LVM and this is quite helpful. When I was reading up on LVM, many sources had trouble with /boot on an LVMed partition so I created /boot in a non-LVMed partition.
Thanks.