How-to Install 9.10 on fakeraid

[[Neurotic]]

Okay, I'm getting somewhere.

It seems the steps that are missing are after 'sudo apt-get install grub', you also need to run:

sudo update-grub

While will create the menu.list

I'm not as familiar with grub, but it seem you also need to run:

grub-install /dev/mapper/nvidia_dhfedfae5

Which looks like it will fail, but will generate the device.map for you to edit.

Although I'm a little hazy on whether that should be aimed at the partition or the hdd itself. (i.e. remove the '5' at the end).

[[Neurotic]]

So still a little stuck...

I can't seem to get grub-install to run correctly, so that stage1 & stage2 files get written to /boot/grub (and so that 'find /grub/boot/stage1' works from within the grub console).

I've updated my device.map to be the follwing configuration:

root@ubuntu:/boot/grub# cat device.map
(fd0)	/dev/fd0
(hd0)	/dev/mapper/nvidia_dhfedfae #was /dev/sda
(hd1)	/dev/sdb

Which looks to be correct.

If I attemt to run grub-install, I get:

root@ubuntu:/boot/grub# grub-install /dev/mapper/nvidia_dhfedfae
/dev/mapper/nvidia_dhfedfae does not have any corresponding BIOS drive.

I've tried running the code above against the partitions, but also get the same error

Is there a different commnd I should be running, or should I be doing this all through the grub console?

[[Neurotic]]

I got it to work ;o)

(Just documenting my process).

I went back to the original FakeRaidHowTo guide

And realised you couldn't do a grub-install. So instead, copied over the files from cp /usr/lib/grub/<your-cpu-arch>-pc/

From there I could run through the grub console section perfectly.

The only change I needed to make was in my menu.lst, it had set up Ubuntu under (hd0,0), when in fact, it is (hd0,4). Easy enough to fix.

Thanks for putting this post up, without it, there is no way I would have been able to do this on my own.

[ashakeandfrys]

Grub install worked for me. But as long as it works for you, that's all that matters. Interesting how different methods lead to the same result.

[[Neurotic]]

Yup too true.

Maybe in the final guide it should have the steps for using grub-install, and then if that fails, use the copy method instead.

[DavidEllis2]

I'm still confused, probably because I'm extremely new to Linux. Steps 1 through 6 worked without a flaw. Steps 7 and 8 seemed to have a very similar problem as that posted by Neurotic. The deinstall included error "Can not write log, openpty() failed (/dev/pts not mounted?)" but otherwise seemed to have worked. The install gave the same error.

root@ubuntu:/# sudo apt-get install grub
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Suggested packages:
  grub-doc mdadm
The following NEW packages will be installed:
  grub
0 upgraded, 1 newly installed, 0 to remove and 159 not upgraded.
Need to get 407kB of archives.
After this operation, 946kB of additional disk space will be used.
Get:1 http://us.archive.ubuntu.com karmic/main grub 0.97-29ubuntu59 [407kB]
Fetched 407kB in 1s (358kB/s)
Preconfiguring packages ...
Can not write log, openpty() failed (/dev/pts not mounted?)
Selecting previously deselected package grub.
(Reading database ... 116959 files and directories currently installed.)
Unpacking grub (from .../grub_0.97-29ubuntu59_i386.deb) ...
Processing triggers for man-db ...
Can not write log, openpty() failed (/dev/pts not mounted?)
Setting up grub (0.97-29ubuntu59) ...

root@ubuntu:/#

There is nothing in /mnt - its an empty directory. Hence commands at step 9 are not working.

Is the missing /dev/pts only an error concerning in writing the log that can be ignored or is it symptomatic of why grub did not install?

Neurotic says to copy the GRUB files from /usr/lib/grub/<your-cpu-arch>-pc/. Do they have to go into /boot/grub or /mnt/root/boot/grub? Sorry to ask the obvious but my UNIX background is limited and also 20 years out of date.

[[Neurotic]]

I just did re-install using the above steps (Alienware m17x), and found the following:

After you have installed grub, do a 'sudo update-grub' as per usual.

This will give you your menu.lst.

I didn't need to set a device map, so don't worry about editing it (and the path on tht step should be /boot/grub/, not /mnt/root/boot/grub, chroot sets /mnt/root/ as your root when you invoke it)

From the, copy the files from '/usr/lib/grub/<your-cpu-arch>-pc/' to /boot/grub

This will give you the stage1 and stge2 files, and some other pieces that are neccesary.

Once you have done that, then you can call the grub console (grub), and continue as per the walkthrough describes.

I've done this install twice now on my machine, and it has worked like a charm.

[DavidEllis2]

Well I ended up with an unbootable system! (No real problem as it is easily restored - hence this posting.)

I decided to try copying the Grub files into /boot/grub as that seemed the most logical. I then proceeded. First oddity I noticed was that device.map had four hard drives showing (hd0 to hd3). This system has four physical disks but the first two are the SATA fakeraid set so I would have expected to see only three entries in device.map. I looked at the system with gparted and it only showed the single SATA fakeraid set - i.e. only one hard drive. The fact that the last two are missing is not a problem at this point. They are two old SCSI disks and I do not need to worry about them or the SCSI controller at this time.

Anyway, I modified the device.map so that hd0 was identified according to what I saw in gparted. (That was also in agreement with what I saw with ls /dev/mapper so I figured hd0 was correct.) I ran the "update-grub" and "grub-install" commands posted by Neurotic a little earlier. Then I proceeded onto step 10 from the initial post in this thread. That seemed to work but with the following surprise. I setup "device (hd0)" as that is what was configured in device.map. Then "find /boot/grub/stage1" came back with (hd1, 7). The partition is correct but I was expecting to see hd0 as that is the configured device. Not being sure what to do I tried doing a "root (hd1,7)" and "setup (hd1)".

Step 13 just gave an error but that is not critical at this point.

When I rebooted, the BIOS found Grub OK but GRUB was unable to find the Linux system to boot. All I got was the Grub menu and a file not found message.

The foregoing looks to me like the Grub is not correctly recognising the fakeraid. Ubuntu seems to interpret it correctly. Any ideas would be welcome.

[[Neurotic]]

What's the exact error that grub is returning to you when it attempts to load?

Also, can you post your menu.lst?

I know that when I did my install, the menu.lst that was generated wasn't correct, and I had to adjust where the root () calls where going to, as they were wrong.

[DavidEllis2]

What's the exact error that grub is returning to you when it attempts to load?

I had posted a lengthy response earlier today but as I have since resolved the problem I have "edited" this reply to remove that post and replace it with "what went wrong". Put simply, I had not noticed and had overlooked your earlier comment about fixing the partition in menu.lst - in my case GRUB was looking at the wrong partition for vmlinuz.

Summary of what I ended up doing:

Follow steps 1 through 8 from the initial posting. (I ignored the errors about not being able to create the log files in steps 7 and 8.)

Then "sudo update-grub" as suggested by Neurotic. After that my attempt to get "grub-install" to work failed and, as suggested by Neurotic I just copied the files over.

Then step 9 required the edit to device.map being careful to remove references to the RAID disks as individual disks. i.e. My initial device map included four physical drives, each of which is found in /dev/ as an "sd" device. The first two of these are in fact the RAID discs which are found in /dev/mapper/. Hence I replaced (hd0) with the /dev/mapper/ value and deleted (hd1) which was the second disk in the RAID set leaving only the other two non-RAID disks.

Then in step 10, GRUB "find" command returned both (hd0,7) and (hd1,7) - my system is installed in partition 7. I set root to (hd0,7) and setup GRUB on hd0. (NOTE: If I set "root" to (hd1,7) GRUB setup failed saying it could not find the partition. This still looks to me as though GRUB doesn't understand fakeraid correctly)

Finally I had to edit menu.lst to change the vmlinuz partion from 0 to 7 and, in my case, to add in the section to dual boot to Windows ntldr.


I still am unable to lock down GRUB from updating and would welcome any explanantion:

root@ubuntu:/# echo "grub-hold" | sudo dpkg -set-selections
dpkg: conflicting actions -e (--control) and -s (--status)

Type dpkg --help for help about installing and deinstalling packages [*];
Use `dselect' or `aptitude' for user-friendly package management;
Type dpkg -Dhelp for a list of dpkg debug flag values;
Type dpkg --force-help for a list of forcing options;
Type dpkg-deb --help for help about manipulating *.deb files;
Type dpkg --license for copyright license and lack of warranty (GNU GPL) [*].

Options marked [*] produce a lot of output - pipe it through `less' or `more' !