LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Issue Booting Slackware 13 with Grub (https://www.linuxquestions.org/questions/slackware-14/issue-booting-slackware-13-with-grub-773467/)

tommcd 12-10-2009 07:59 AM

Grady34,
You need to first make an initrd for the generic kernel as others have said. Read the README in the /boot directory on your Slackware system for instructions on how to do that. You can boot Slackware to the huge kernel from the first install CD or the DVD by running the command that is listed when you boot up the first CD or DVD.
The command for creating the initrd will be something like:
Code:

mkinitrd -c -k 2.6.29.5 -m mbcache:jbd:ext3 -f ext3 -r /dev/hdb3
That is one of the examples in the README. For my system using ext4 file system for Slackware on /dev/sda6 I used:
Code:

mkinitrd -c -k 2.6.29.6 -m ext4 -f ext4 -r /dev/sda6
I boot Slackware 13 64bit from grub2 on Ubuntu 9.10. You will probably need to create a custom entry in /etc/grub.d/ to boot Slackware, as I did. I would recommend reading this tutorial from the Ubuntu wiki:
https://wiki.ubuntu.com/Grub2
The specific part about creating custom entries is here:
https://wiki.ubuntu.com/Grub2#User-defined Entries
For reference, here is my custom entry for booting Slackware 13 64bit on /dev/sda6.
NOTE: You will need to change the partition number and UUID number according to your system:
Code:

echo "Adding Slackware64-13.0 on /dev/sda6" >&2
cat << EOF
menuentry "Slackware64-13.0 on /dev/sda6" {
        set root=(hd0,6)
        linux  /boot/vmlinuz-generic-2.6.29.6 root=UUID=548056ce-800a-4621-9fbd-4a9dd226e094 ro
        initrd  /boot/initrd.gz
}
EOF

It worked perfectly. Grub2 is a bit more complicated than grub-legacy. We will have to get used to that.
Remember, grub2 counts hard drives from zero, as grub-legacy did. But partitions are counted from 1, not zero. So /dev/sda1 would be (hd0,1) in grub2-speak. In grub-legacy-speak it would have been (hd0,0).

TSquaredF 12-10-2009 09:58 AM

arubin:
Quote:

Doesn't sda7 correspond to hd0,6?
No. That's one of the things they changed in GRUB2. The disk counting is still indexed to "0", but the partition counting starts with "1". See this thread.
Quote:

Or rather sd0,6
No. They are all "hd" to GRUB.
Regards,
Bill

grady34 12-11-2009 06:53 AM

Problem with that is that I can boot in to the huge kernel no problem with the exact same grub menu entry.

zordrak 12-11-2009 08:31 AM

So with huge you boot ok, with generic you cannot see the block device.

Perhaps the generic kernel does not have drivers for your SATA controller. You should check what driver is required and either add it into the initrd or compile a custom kernel based on the generic config that includes the controller.

tommcd 12-12-2009 07:09 AM

Quote:

Originally Posted by grady34 (Post 3787722)
Problem with that is that I can boot in to the huge kernel no problem with the exact same grub menu entry.

This is because the grub2 in Ubuntu (and Mint) does not add the initrd line that the generic kernel needs to boot. This is why you can boot the huge kernel, bucause it does not need an initrd. I had the same problem. That is why I created a custom entry to boot Slackware with the generic kernel as I discussed in my last post (post #16 in this thread).

grady34 12-13-2009 09:31 AM

Thanks tommcd, that was it.

I ran mkinitrd, and I manually edited the grub commands upon start up to point to the initrd, but with only the reiserfs.ko added it wasn't recognizing my SATA drives. Added a custom item that included the initrd line so that I don't have to type it every time, redid my mkinitrd with the options you mentioned and everything is booting properly now.

One last question -- now that grub2 is all automated and they tell you not to edit grub.cfg, is there a way for me to remove these non-working entries that don't have the initrd? From reading through the link you posted I can't think of anything short of manually editing it out, which I assume would be erased any time I did update-grub.

Not crucial, just to sooth my OCD...

TSquaredF 12-13-2009 01:26 PM

grady34
Quote:

One last question -- now that grub2 is all automated and they tell you not to edit grub.cfg
I haven't found a howto simple enough to explain to me the use of grub2's automated configuration. (If someone has found/written one, let me know.) Meanwhile, I am editing grub.cfg by hand & having no problems. I would think that if you don't get too elaborate with your configuration, editing by hand would be OK.
Regards,
Bill

tommcd 12-14-2009 10:01 AM

Quote:

Originally Posted by grady34 (Post 3789748)
Thanks tommcd, that was it.

I ran mkinitrd, and I manually edited the grub commands upon start up to point to the initrd, but with only the reiserfs.ko added it wasn't recognizing my SATA drives. Added a custom item that included the initrd line so that I don't have to type it every time, redid my mkinitrd with the options you mentioned and everything is booting properly now.

Glad you got things working!! I'm also glad that I could help with this. This moves me up one notch on the grub2 learning curve ;)
Quote:

Originally Posted by grady34 (Post 3789748)
One last question -- now that grub2 is all automated and they tell you not to edit grub.cfg, is there a way for me to remove these non-working entries that don't have the initrd? From reading through the link you posted I can't think of anything short of manually editing it out, which I assume would be erased any time I did update-grub.

Yes, you are correct that if you manually edit grub.cfg, any changes you made to grub.cfg will be overwritten the next time an update for grub2 or a kernel update comes along, since the update-grub command is automatically run when grub2 or the kernel is updated.

I admit that my grub2 menu is also looking a bit untidy, since I have those non-working Slackware entries in my grub.cfg just like you. The only thing I can think of to remove these non-working entries and tidy up the grub menu would be to add this line to /etc/default/grub
Code:

GRUB_DISABLE_OS_PROBER=true
See the end of this section of the grub2 tutorial from the Ubuntu wiki:
https://wiki.ubuntu.com/Grub2#grub (/etc/default/grub)
Quote:

GRUB_DISABLE_OS_PROBER=true
Enables/disables the os-prober check of other partitions for operating systems, including Windows, Linux, OSX and Hurd.
This would require you to manually add custom rules for booting all other operating systems on your computer, including Windows, to /etc/grub.d as specified here:
https://wiki.ubuntu.com/Grub2#User-defined Entries
Then when you run update-grub the only entries in grub.cfg would be the Ubuntu kernels, the recovery mode options for Ubuntu, plus the custom entries you have created in /etc/grub.d/. All those non-working options would be gone.
Another way to do this would be to remove the executable bit from /etc/grub.d/30_os-prober. To do that just run:
Code:

cd /etc/grub.d/
sudo chmod -x 30_os-prober

So the 30_os-prober script would not be run when grub2 is updated.
You would still need to create custom entries for booting all other operating systems in /etc/grub.d as I have discussed. Then just run:
"sudo update-grub" to have a grub menu exactly as you want it.
I have not disabled 30_os-prober, since I also boot Zenwalk, Debian and WindowsXP, and the os-prober works well for those. So I just live with the untidy non-working Slackware entries.

tommcd 12-14-2009 10:25 AM

Quote:

Originally Posted by TSquaredF (Post 3789989)
grady34
I haven't found a howto simple enough to explain to me the use of grub2's automated configuration. (If someone has found/written one, let me know.)

The best tutorials for grub2 that I have found:
https://wiki.ubuntu.com/Grub2
http://members.iinet.net/~herman546/p20.html
If you find anything else, please post it here.
Quote:

Originally Posted by TSquaredF (Post 3789989)
Meanwhile, I am editing grub.cfg by hand & having no problems. I would think that if you don't get too elaborate with your configuration, editing by hand would be OK.

There is nothing inherently wrong with editing grub.cfg. It will work. The problem is that anytime the update-grub command is automatically run, your custom edits to grub.cfg will be overwritten, and you will have to redo them. Adding custom entries to /etc/grub.d/ avoids that.


All times are GMT -5. The time now is 09:20 PM.