I have been happily running multi-boot on all of my computers thanks to Grub and Saikee's How-to's.
I just installed Kubuntu 9.04 and got the dreaded Error 2 Bad File or Directory.
The problem is that 9.04 has 256 bit inodes, and Grub 0.97 will not boot to a partition with 256 bit inodes.
To verify:
sudo dumpe2fs /dev/sda8 | grep -i "inode size"
Change sda8 to desired partition, of course.
I have sda5 with Kubuntu 7.04 and it's /boot/menu.lst has all of the OS in it.
Kubuntu 9.04 is on sda8. I did not install the bootloader because normally I modify the existing loader to run it.
My thought was to re-install Kubuntu 9.04, put the boot loader in sda8, and move the menu.lst details over from sda5. I assume the Grub with 9.04 will run all my OS, yes?
Or, is there a better way to do this? I Googled and found nothing else except re-format the partition with 128 bit inodes, and re-install without formatting, which assumes it will let you do that.
Another fellow said to move the Grub files over from the 9.04 partition, which assumes you installed them, which I did not.
gamblor01
05-24-2009, 08:38 PM
I had this same problem when trying to use Ubuntu 8.04 to launch Slackware 12.1 (which uses 256 byte inodes). I wound up resolving the issue by just running:
sudo grub-install /dev/sda
There is a patch that most distros (including Ubuntu) apply for 0.97 series grub which will allow it to boot 256 byte inodes. It was certainly there for 8.04, you might just try reinstalling grub to see if it works in 7.04. I don't know if they put that patch out for 7.04 or not.
In any case, if it fails then certainly you can install grub on your 9.04 partition and then use it to boot everything. You shouldn't need to reinstall just to get grub installed, though I am not sure what the exact commands are. If anyone knows certainly Saikee does. ;)
saikee
05-24-2009, 08:54 PM
I got the feeling that you may be on an Ext4 filing system. I have temporarily steered clear of that filing system because it needs a Linux with 2.6.28 or above to rescue it. Don't remember any difficulty in booting it but I have been a strong advocate on "chainloading" which can bypass the difficulty you have.
In any case if you can't rescue it, like mount its partition with a Linux on an older kernel then your best chance is to boot up the original installation CD, or one that is newer, and do the following
(1) Create /boot/grub subdirectory in partition sda8
(2) Copy stage1 and stage2 from either the CD or the installed Kubuntu (in /usr/lib/grub/i386-pc) and put these two files inside /boot/grub of sda8
(3) write your own menu.lst inside /boot/grub/menu.lst
(4) Invoke a Grub shell and put Grub inside sda8 by command
root (hd0,7)
setup (hd0,7)
(5) You can now boot Kubuntu inside sda8 by whatever Grub controlling the MBR by these lines in its menu.lst
title Kubuntu 9.04 in sda8 known to Grub as (hd0,7)
root (hd0,7)
chainloader +1
The above should work because in booting up the original CD you would have Grub patched up for Kubuntu and so the GRub inside sda8 would be able to boot Kubuntu inside it. The other Grub in the MBR simply hands over the control to the Grub inside sda8.
For your information my Kubuntu in sda57 has these entries in the menu.lst
title Kubuntu jaunty (development branch), kernel 2.6.28-11-generic in sda57
root (hd0,56)
kernel /boot/vmlinuz-2.6.28-11-generic root=/dev/sda57 ro quiet splash
initrd /boot/initrd.img-2.6.28-11-generic
quiet
irlandes
05-24-2009, 11:38 PM
No, I told it to use ext3, which apparently on newer distros uses 256 bit inodes and grub .97 can't open it. Problem with 7.04 I assume mirrors are canceled since I have not been able to download anything for quite a while. In fact, if I could get updates etc. for 7.04 I would not be installing 9.04.
I will be working my way through your suggestions. There is no /usr/lib/grub on the sda8, probably because I told it not to install grub loader, so will go to CD and see if I can find it. It is there on sda5 Kubuntu 7.04. Thanks for now.
I am in Kubuntu installed in /dev/sda57 in the hard disk.
When I interrogate the inode size and the locations that have Grub's stage1 file here is what I got
root@saikee-desktop:/home/saikee# sudo dumpe2fs /dev/sda57 | grep -i "inode size"
dumpe2fs 1.41.4 (27-Jan-2009)
Inode size: 256
root@saikee-desktop:/home/saikee# find / -name stage1
/usr/lib/grub/i386-pc/stage1
/boot/grub/stage1
root@saikee-desktop:/home/saikee# ls /usr/lib/grub/i386-pc/
e2fs_stage1_5 fat_stage1_5 jfs_stage1_5 minix_stage1_5 reiserfs_stage1_5 stage1 stage2 stage2_eltorito xfs_stage1_5
If you have not installed Grub in your kubuntu then stage1 will not be in /boot/grub subdirectory. However AFAIK the source of the Grub files is part of the kernel and will be in every distro that uses Grub. It will be missing only in distros that use exclusively Lilo, like Slackware or Slax.
I have carried out an experiment using Grub 0.91, 0.95 and 0.97 floppies
With Grub 0.91 and 0.95 I could not see the file when I issued the command
cat (hd0,56)/boot/grub/menu.lst
Only Grub 0.97 could show the file. However I am in Kubuntu booted by Grub 0.91, the oldest Grub I have, using
root (hd0,56)
chainloader +1
boot
The above doesn't really prove Grub 0.97 is the answer because my floppy could have been created by a recent Ubuntu already patched up. Thus if you restore Grub inside your kubuntu in sda8 your Linux should become bootable by any version of Grub.
May be next time you would allow the installer to place the boot loader in the root partition because you lose nothing but gain everything the boot loader can do for you. For a start you don't need to dream up a menu.lst for it as in this case.
gamblor01
05-25-2009, 09:47 AM
(1) Create /boot/grub subdirectory in partition sda8
(2) Copy stage1 and stage2 from either the CD or the installed Kubuntu (in /usr/lib/grub/i386-pc) and put these two files inside /boot/grub of sda8
(3) write your own menu.lst inside /boot/grub/menu.lst
(4) Invoke a Grub shell and put Grub inside sda8 by command
Oh man -- I didn't even think about installing grub in /dev/sda8 and then chainloading it. Good idea! Thank you for step 2 above there -- that was precisely the part that I was unsure about, but now I know where the files are located!
Guess the same commands would work if you just setup (hd0) and then the grub on sda8 would become the "main" bootloader instead of that on sda5.
Good info here.
saikee
05-25-2009, 10:08 AM
gamblor01,
Yep
root (hd0,7)
setup (hd0)would put the Grub residing in (hd0,7) or sda8 to control the MBR.
Needless to say one can put Grub in sda8 on a floppy too
root (hd0,7)
setup (fd0)
Booting in Linux is laughingly simple if you give it a go.
You can boot up a Linux even if it has no boot loader inside.
As an example if you want to boot up sda8 which has no boot loader installed you type
[code]root (hd0,7)
kernel /boot/vmli and press the "tab" key then Grub will search the /boot directory to find the kernels that have the starting name with "vmli". You choose the one you want and just add "ro root=/dev/sda8" afterward.
Samething for the ramdisk file using the "initrd" command.
There afterward you give Grub the green light to fire it up by the command
boot
That is the sure fire method to boot any Linux.
irlandes
05-27-2009, 12:12 PM
Saikee is right (of course). Though the old version of Grub cannot directly load a partition with the new 256 bit inodes, chainloader can open Grub on that partition.
Not fully at the time understanding what he was telling me, :) , I installed Kubuntu 9.04 on sda9, the empty partition. It could be loaded by chainloader.
I then installed Grub loader in sda8:
>grub
>root (hd0,7)
>setup (hd0,7)
>quit
Note that I did not use a rescue disk, but simply installed it from sda9, which one assumes has the correct grub version on it.
sda8 would then load via chainloader. I had not installed the loader because I have chosen to use direct load from an existing OS. I may change that in the future.
I looked at /boot/grub/menu.lst on sda9, and to my surprise, when I installed 9.04 on sda9, it build a menu.lst with all the OS, for direct loading.
After some thought, I burned a CD with puppy 4.2.1. I renamed sda5 (Kubuntu 7.04) /boot/grub as /boot/sda5_grub. Then, I moved /boot/grub from sda9 to sda5.
I had puppy in case it did a crash and burn. Then, I rebooted, and it gave me the complete menu choice from sda9, which includes direct loading for all OS on the computer, including XP.
So, if you have a copy of /boot/grub with the new version, simply pop it on the distro you are using and it will be the latest. Be sure to have a puppy CD or some other effective rescue disk in case you booboo.
The grub commands above put a grub boot loader on the partition named without touching the mbr. I am wondering if the following produces a mbr boot loader, which loads the chosen partition. I will be trying it when I get 9.04 working to suit me. (No audio except kalarm, no youtube audio, no mplayer audio, no Amarok audio. When I get around to that problem, if I need help, I will start a different thread.)
>grub
>root (hd0,7)
>setup (hd0)
>quit
If this does load the grub loader on MBR, pointing at the root partition listed, that will be cool.
A comment on chainloader. Linux is about choice. Different people have different reasons for their choices, which strikes directly at my personal political beliefs on personal liberty. Saikee has almost 150 distros on one computer, it is not clear if his 146 XP are the same computer or not. It would be irrational to have to build a menu.lst for that many distros, with direct load to the specific vmlinuz or initrd.img. So, chainloader is probably the best choice.
Though let me point out Mandrake/Mandriva traditionally solved such problems with links in /boot called vmlinuz and initrd, linking to whatever kernel and initrd.img was used. Thus, if the kernel was changed, one need not go to another partition to update the menu.lst
Ubuntu builds menu.lst for direct loading, except of course XP, heh, heh.
And, since I have few distros on my machine, I prefer to avoid loading grub twice. If I had 150 distros, I would also use chainloader.
##############
KOWABUNGA!!!!!!! Kubuntu 9.04 has the driver for my Vostro 1000 wireless chip, no dinking around needed, except setting up once the specific router information with the hex key. It also lets you set up to open automatically. The problem is, it demands the password for Wallet, so I put in a two character Wallet password. I will be seeing if I can use visudo to bypass that and give me automatic wireless, as it should be. It is not totally rational to demand a password on something like wireless, on a system which is itself protected by password, and especially so in my private home.
There are some dramatic new features which will take some getting used to. For example, I don't think Plasma lets me put application icons on the tool bar, though maybe there is a way and I haven't found it yet.
The K-menu was all different, which I don't like. Right clicking on the K icon lets you change it back to traditional K-menu. I like to run my cursor up and down to find what I want.
gamblor01
05-27-2009, 06:58 PM
I am wondering if the following produces a mbr boot loader, which loads the chosen partition. I will be trying it when I get 9.04 working to suit me. (No audio except kalarm, no youtube audio, no mplayer audio, no Amarok audio. When I get around to that problem, if I need help, I will start a different thread.)
>grub
>root (hd0,7)
>setup (hd0)
>quit
If this does load the grub loader on MBR, pointing at the root partition listed, that will be cool.
Yep those steps would indeed install grub into the MBR (much like the "fixmbr" command for Windows). I have used that several times to fix things up for my own system as well as friends of mine (and recommended it to several people on forums).
If you don't know which partition should be root you can always use the commands:
> grub
> find /boot/grub/stage1
On your system this should spit out "(hd0,7)" and then you would follow it up with:
> root (hd0,7)
> setup (hd0)
It may find several stage1 files on different partitions though, then you should be able to use any of them (or pick the "right" one if one of the partitions has the menu.lst file configured properly while the other does not).
It's definitely a problem with vanilla (unpatched) grub-0.97 from sources. We fixed it in LFS by adding the same patch that all the distros are (...or should be ;)) using by now.
Satanic Atheist
06-09-2009, 03:35 PM
You could evade the problem and use XFS which I'm now using since ReiserFS is too dated for a modern system (IMHO) and won't get updated after Hans Reiser is (ahem) "being punished".
So far, I've found XFS to be fast, stable and I've had no troubles with it. My encrypted laptop has no slow down on disk accesses (that are noticeable, anyway) and it's also bloody good on a USB stick.
Slightly off-topic, but I thought I'd throw my t'penth in anyway.
James
saikee
06-09-2009, 07:10 PM
Don't use XFS partition myself but I believe, after checking with the Internet, this is one of the rare filing systems that starts its superblock at the first sector of the partition where the boot loader resides. Thus such a partition may have difficulty for booting purpose.
As a data partition it doesn't matter.
Can Satanic Atheist confirm if you manage to use XFS partition to install Grub or Lilo?
Satanic Atheist
06-10-2009, 08:13 AM
I run an encrypted system that boots HDA1 natively into XP and the Linux partitions are hidden from view by not even being referenced in the partition table. Linux itself, on my laptop, boots from USB.
However, I use XFS on my USB pen drive and it's bootable so it works there (GRUB is in the MBR) and when I installed this machine, I initially installed a plain, new Debian system direct onto HDA1 before I set up the rest of the partitions. That partition also ran on an XFS filesystem and GRUB was also loaded into the MBR, so yes, it is possible to boot XFS using GRUB.
XFS, from what I've read, is an excellent filesystem for very large files with optimizations in place for handling these files. It's performance is only referred to as "average" for small files but I certainly have no trouble looking through, say, /usr/bin and that's even with the cryptographic layer. One other drawback of the XFS filesystem is that it can only be enlarged, never shrunk. In order to do this, the whole system must be backed up, the partitions remade and formatted and then everything copied back. Still, for most static machines, this doesn't seem much of a problem.
Hope this helps,
James
justlinux.com
Copyright Internet.com Inc. All Rights Reserved.