I have tried to load this software as another to keep an eye on, but when I do load it it takes over Grub! I didn't see any way to stop it from doing this. Has anyone else had success? If so let me know what to do.
Karl
Karl Larsen escribió:
I have tried to load this software as another to keep an eye on, but when I do load it it takes over Grub! I didn't see any way to stop it from doing this. Has anyone else had success? If so let me know what to do.
You should ask in an Ubuntu list.
Martin Marques wrote:
Karl Larsen escribió:
I have tried to load this software as another to keep an eye on, but when I do load it it takes over Grub! I didn't see any way to stop it from doing this. Has anyone else had success? If so let me know what to do.
You should ask in an Ubuntu list.
I don't belong to any.
Karl
Karl Larsen wrote:
Martin Marques wrote:
Karl Larsen escribió:
I have tried to load this software as another to keep an eye on, but when I do load it it takes over Grub! I didn't see any way to stop it from doing this. Has anyone else had success? If so let me know what to do.
You should ask in an Ubuntu list.
I don't belong to any.
Karl
Not sure what your reply is about, but Martin is right. Ubuntu questions go into the Ubuntu mailing list.
On Sun, 2008-01-27 at 12:40 -0700, Karl Larsen wrote:
Martin Marques wrote:
Karl Larsen escribió:
I have tried to load this software as another to keep an eye on, but when I do load it it takes over Grub! I didn't see any way to stop it from doing this. Has anyone else had success? If so let me know what to do.
You should ask in an Ubuntu list.
I don't belong to any.Karl
--
Karl F. Larsen, AKA K5DI Linux User #450462 http://counter.li.org. PGP 4208 4D6E 595F 22B9 FF1C ECB6 4A3C 2C54 FE23 53A7
Ubuntu Forums site@ubuntuforums.org
On Sunday 27 January 2008 2:40:40 pm Karl Larsen wrote:
Martin Marques wrote:
Karl Larsen escribió:
I have tried to load this software as another to keep an eye on, but when I do load it it takes over Grub! I didn't see any way to stop it from doing this. Has anyone else had success? If so let me know what to do.
You should ask in an Ubuntu list.
I don't belong to any.Karl
Karl: Most of the *buntus do not make it easy to dual-boot with another Linux distrobution. First, as you've discovered, they will take over the MBR. There is fix for that -- use the "alternate" .iso (non-live). Then, during the install process you'll see an button labeled "Advanced" which will allow you to put Grub in *buntu's root partition. You'll then have to modify Fedora's grub.conf, adding a chainloader directive to the *buntu root partition and leaving Fedora in control the booting process. Alternatively, you could edit Fedora's grub.conf to include all of *buntu's kernel and initrd stuff.
Beware of another *buntu gotcha: If you have setup a separate /boot partition, don't tell *buntu about it because it will insist on formatting it, thereby erasing all of the good Fedora stuff. The workaround is to let *buntu have its own /boot partition under its / partition.
By the way: The *buntu guys have a ton of online information beyond mail lists -- wikis, forums and other stuff. Betcha this has all been covered there many times.
-- cmg
Carroll Grigsby wrote:
On Sunday 27 January 2008 2:40:40 pm Karl Larsen wrote:
Martin Marques wrote:
Karl Larsen escribió:
I have tried to load this software as another to keep an eye on, but when I do load it it takes over Grub! I didn't see any way to stop it from doing this. Has anyone else had success? If so let me know what to do.
You should ask in an Ubuntu list.
I don't belong to any.Karl
Karl: Most of the *buntus do not make it easy to dual-boot with another Linux distrobution. First, as you've discovered, they will take over the MBR. There is fix for that -- use the "alternate" .iso (non-live). Then, during the install process you'll see an button labeled "Advanced" which will allow you to put Grub in *buntu's root partition. You'll then have to modify Fedora's grub.conf, adding a chainloader directive to the *buntu root partition and leaving Fedora in control the booting process. Alternatively, you could edit Fedora's grub.conf to include all of *buntu's kernel and initrd stuff.
Beware of another *buntu gotcha: If you have setup a separate /boot partition, don't tell *buntu about it because it will insist on formatting it, thereby erasing all of the good Fedora stuff. The workaround is to let *buntu have its own /boot partition under its / partition.
By the way: The *buntu guys have a ton of online information beyond mail lists -- wikis, forums and other stuff. Betcha this has all been covered there many times.
-- cmg
Thanks a lot! Yes I tried moving the mess that Ubuntu has for a grub.conf but it didn't work. It comes up to about half way and just quits. I think chainload is the answer.
Karl
Karl Larsen escribió:
Martin Marques wrote:
Karl Larsen escribió:
I have tried to load this software as another to keep an eye on, but when I do load it it takes over Grub! I didn't see any way to stop it from doing this. Has anyone else had success? If so let me know what to do.
You should ask in an Ubuntu list.
I don't belong to any.
Bob Holtzman wrote:
On Sun, 27 Jan 2008, Karl Larsen wrote:
You should ask in an Ubuntu list.
I don't belong to any.Karl
Did you really type that with a stright face?
Yes because it is the fact. I have never belonged to one but I may join one now.
Karl
On Sun, 27 Jan 2008 11:48:16 -0700, Karl Larsen wrote:
I have tried to load this software as another to keep an eye on, but
^^^^^^^^^^^
when I do load it it takes over Grub! I didn't see any way to stop it from doing this. Has anyone else had success? If so let me know what to do.
I take that to mean what you really have is neither a straight Fedora problem, nor a straight Ubuntu problem, but a multi-boot problem involving both. Right?
After much effort and with lots of help online, I have just managed to make my testbed machine triple-boot, reliably, with Fedora 8, Ubuntu 7.10, and CentOS 5.1; I'm not quite sure what I did, nor how, but I can outline it.
First, back up your data; the next step will wipe *everything* -- leaving you with not even an OS.
Now download and burn a CD with DBAN, boot to it, and tell it autonuke. It will take several hours.
Then partition the hard drive; use knoppix, or gparted or qtparted on a live CD. I made a separate /boot partition first, then one for each OS, and a swap partition.
Boot from the install medium for the first OS; do the manual install, making sure you install only into the partition you want; let it build you a grubbery in /boot. I did CentOS first. Make a note of what in in any grub.conf a/o menu.lst you can find.
Install gparted or qtparted or both in each OS as you go -- not to partition with, but to look with. Keeping track of what's on which partition is going to grow into a major pain.
Now do the like with the second OS -- I used Fedora. It will probably wreck your ability to boot to the first one.
So boot to what you can, and command mkdir /TEST. Then start running "mount -t ext3 /dev/sdax /TEST" for x = 1 to whatever your last partition is. (In CentOS and Ubuntu, use hda, not sda.)
Whenever a partition does mount, do "cd /TEST," then ls, and drill down to find any grub.conf a/o menu.lst in any OS but the one you're running.
In another terminal or terminal tab, su to root, and do the same inside the one you're running.
Copy and paste, adding each OS's boot data to the boot record for the other. It should now boot to both.
If you add a third, as I did, expect it to wreck your ability to boot to at least one of the others. Apply a similar remedy.
As I said, I'm not sure; I *think* the above is what I did. But I notice that what's in /boot is *not* all the boot data, but that for one OS (the last, iirc), and some directions to chainload.
You may have to do something similar to all the above *again* whenever one OS updates its kernel. Or the chainloading from the dedicated /boot partition may spare you that. Be sure at least that you do save the boot data for the new kernel, where you can get to ti even if not to its OS.
It's not pretty; but if you put the testbed -- *after* all the installing -- behind a KVM switch along with your main machine, it's very convenient once it's running.
On Sun, 27 Jan 2008 21:29:24 +0000, I Beartooth wrote:
[....]
Then partition the hard drive; use knoppix, or gparted or qtparted on a live CD. I made a separate /boot partition first, then one for each OS, and a swap partition.
Boot from the install medium for the first OS; do the manual install, making sure you install only into the partition you want; let it build you a grubbery in /boot. I did CentOS first. Make a note of what in in any grub.conf a/o menu.lst you can find.
[...]
[....] I notice that what's in /boot is *not* all the boot data, but that for one OS (the last, iirc), and some directions to chainload.
Not quite right; here's the content of /boot on the testbed machine :
[root@localhost btth]# mount -t ext3 /dev/sda1 /TEST [root@localhost btth]# cd /TEST [root@localhost TEST]# ls config-2.6.18-53.1.4.el5.centos.plusxen config-2.6.18-53.1.4.el5xen config-2.6.18-53.1.6.el5xen config-2.6.18-53.el5xen grub Grubberies initrd-2.6.18-53.1.4.el5.centos.plusxen.img initrd-2.6.18-53.1.4.el5xen.img initrd-2.6.18-53.1.6.el5xen.img initrd-2.6.18-53.el5xen.img lost+found message symvers-2.6.18-53.1.4.el5.centos.plusxen.gz symvers-2.6.18-53.1.4.el5xen.gz symvers-2.6.18-53.1.6.el5xen.gz symvers-2.6.18-53.el5xen.gz System.map-2.6.18-53.1.4.el5.centos.plusxen System.map-2.6.18-53.1.4.el5xen System.map-2.6.18-53.1.6.el5xen System.map-2.6.18-53.el5xen vmlinuz-2.6.18-53.1.4.el5.centos.plusxen vmlinuz-2.6.18-53.1.4.el5xen vmlinuz-2.6.18-53.1.6.el5xen vmlinuz-2.6.18-53.el5xen xen.gz-2.6.18-53.1.4.el5 xen.gz-2.6.18-53.1.4.el5.centos.plus xen.gz-2.6.18-53.1.6.el5 xen.gz-2.6.18-53.el5 xen-syms-2.6.18-53.1.4.el5 xen-syms-2.6.18-53.1.4.el5.centos.plus xen-syms-2.6.18-53.1.6.el5 xen-syms-2.6.18-53.el5 [root@localhost TEST]#
Within that, it's CentOS that grub knows about -- but it does also know there's more :
[root@localhost TEST]# cd grub [root@localhost grub]# ls device.map grub.conf.save minix_stage1_5 ufs2_stage1_5 e2fs_stage1_5 grub.conf.save.1 reiserfs_stage1_5 vstafs_stage1_5 fat_stage1_5 iso9660_stage1_5 splash.xpm.gz xfs_stage1_5 ffs_stage1_5 jfs_stage1_5 stage1 grub.conf menu.lst stage2 [root@localhost grub]# file menu.lst menu.lst: symbolic link to `./grub.conf' [root@localhost grub]# cat grub.conf # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/hda2 # initrd /initrd-version.img #boot=/dev/hda default=0 timeout=20 #splashimage=(hd0,0)/grub/splash.xpm.gz #hiddenmenu title CentOS (2.6.18-53.1.6.el5xen) root (hd0,0) kernel /xen.gz-2.6.18-53.1.6.el5 module /vmlinuz-2.6.18-53.1.6.el5xen ro root=LABEL=/ module /initrd-2.6.18-53.1.6.el5xen.img title CentOS (2.6.18-53.1.4.el5.centos.plusxen) root (hd0,0) kernel /xen.gz-2.6.18-53.1.4.el5.centos.plus module /vmlinuz-2.6.18-53.1.4.el5.centos.plusxen ro root=LABEL=/ module /initrd-2.6.18-53.1.4.el5.centos.plusxen.img title CentOS (2.6.18-53.1.4.el5xen) root (hd0,0) kernel /xen.gz-2.6.18-53.1.4.el5 module /vmlinuz-2.6.18-53.1.4.el5xen ro root=LABEL=/ module /initrd-2.6.18-53.1.4.el5xen.img title CentOS (2.6.18-53.el5xen) root (hd0,0) kernel /xen.gz-2.6.18-53.el5 module /vmlinuz-2.6.18-53.el5xen ro root=LABEL=/ module /initrd-2.6.18-53.el5xen.img title Fedora rootnoverify (hd0,2) chainloader +1 title Ubuntu rootnoverify (hd0,4) chainloader +1 [root@localhost grub]#
Beartooth wrote:
On Sun, 27 Jan 2008 11:48:16 -0700, Karl Larsen wrote:
I have tried to load this software as another to keep an eye on, but
^^^^^^^^^^^when I do load it it takes over Grub! I didn't see any way to stop it from doing this. Has anyone else had success? If so let me know what to do.
I take that to mean what you really have is neither a straight Fedora problem, nor a straight Ubuntu problem, but a multi-boot problem involving both. Right?
After much effort and with lots of help online, I have just managed to make my testbed machine triple-boot, reliably, with Fedora 8, Ubuntu 7.10, and CentOS 5.1; I'm not quite sure what I did, nor how, but I can outline it.
First, back up your data; the next step will wipe *everything* -- leaving you with not even an OS.
Now download and burn a CD with DBAN, boot to it, and tell it autonuke. It will take several hours.
Then partition the hard drive; use knoppix, or gparted or qtparted on a live CD. I made a separate /boot partition first, then one for each OS, and a swap partition.
Boot from the install medium for the first OS; do the manual install, making sure you install only into the partition you want; let it build you a grubbery in /boot. I did CentOS first. Make a note of what in in any grub.conf a/o menu.lst you can find.
Install gparted or qtparted or both in each OS as you go -- not to partition with, but to look with. Keeping track of what's on which partition is going to grow into a major pain.
Now do the like with the second OS -- I used Fedora. It will probably wreck your ability to boot to the first one.
So boot to what you can, and command mkdir /TEST. Then start running "mount -t ext3 /dev/sdax /TEST" for x = 1 to whatever your last partition is. (In CentOS and Ubuntu, use hda, not sda.)
Whenever a partition does mount, do "cd /TEST," then ls, and drill down to find any grub.conf a/o menu.lst in any OS but the one you're running.
In another terminal or terminal tab, su to root, and do the same inside the one you're running.
Copy and paste, adding each OS's boot data to the boot record for the other. It should now boot to both.
If you add a third, as I did, expect it to wreck your ability to boot to at least one of the others. Apply a similar remedy.
As I said, I'm not sure; I *think* the above is what I did. But I notice that what's in /boot is *not* all the boot data, but that for one OS (the last, iirc), and some directions to chainload.
You may have to do something similar to all the above *again* whenever one OS updates its kernel. Or the chainloading from the dedicated /boot partition may spare you that. Be sure at least that you do save the boot data for the new kernel, where you can get to ti even if not to its OS.
It's not pretty; but if you put the testbed -- *after* all the installing -- behind a KVM switch along with your main machine, it's very convenient once it's running.
Well, I follow almost everything but what you actually did. I do not plan to re-load F7 and F7-64 and F8 just to load Ubuntu. That is stupid. I think there might be a way to get Ubuntu to set up it's grub on it's partition. Then I can chainload it when I want.
If it takes over over (hd0) I can just re-direct it to it's partition.
Karl
Beartooth wrote:
I take that to mean what you really have is neither a straight Fedora problem, nor a straight Ubuntu problem, but a multi-boot problem involving both. Right?
After much effort and with lots of help online, I have just managed to make my testbed machine triple-boot, reliably, with Fedora 8, Ubuntu 7.10, and CentOS 5.1; I'm not quite sure what I did, nor how, but I can outline it.
First, back up your data; the next step will wipe *everything* -- leaving you with not even an OS.
Now download and burn a CD with DBAN, boot to it, and tell it autonuke. It will take several hours.
Somewhat overkill for what you are after. If you want to wipe the drive, but do not need a secure erase, then you can use something like "dd if=/dev/zero of=/dev/sda". You really should do it from after booting from a live CD. It is not normally needed it any case.
Then partition the hard drive; use knoppix, or gparted or qtparted on a live CD. I made a separate /boot partition first, then one for each OS, and a swap partition.
Boot from the install medium for the first OS; do the manual install, making sure you install only into the partition you want; let it build you a grubbery in /boot. I did CentOS first. Make a note of what in in any grub.conf a/o menu.lst you can find.
Install gparted or qtparted or both in each OS as you go -- not to partition with, but to look with. Keeping track of what's on which partition is going to grow into a major pain.
Now do the like with the second OS -- I used Fedora. It will probably wreck your ability to boot to the first one.
So boot to what you can, and command mkdir /TEST. Then start running "mount -t ext3 /dev/sdax /TEST" for x = 1 to whatever your last partition is. (In CentOS and Ubuntu, use hda, not sda.)
Whenever a partition does mount, do "cd /TEST," then ls, and drill down to find any grub.conf a/o menu.lst in any OS but the one you're running.
In another terminal or terminal tab, su to root, and do the same inside the one you're running.
Copy and paste, adding each OS's boot data to the boot record for the other. It should now boot to both.
If you add a third, as I did, expect it to wreck your ability to boot to at least one of the others. Apply a similar remedy.
As I said, I'm not sure; I *think* the above is what I did. But I notice that what's in /boot is *not* all the boot data, but that for one OS (the last, iirc), and some directions to chainload.
You may have to do something similar to all the above *again* whenever one OS updates its kernel. Or the chainloading from the dedicated /boot partition may spare you that. Be sure at least that you do save the boot data for the new kernel, where you can get to ti even if not to its OS.
It's not pretty; but if you put the testbed -- *after* all the installing -- behind a KVM switch along with your main machine, it's very convenient once it's running.
I love it. It is way too complicated for most uses, but it will work. I tend to prefer giving each OS its own /boot partition - it tends to keep things simple. Only one needs to be on a primary partition. It is possible to share a /home partition between distributions, but it is usually more work then it is worth unless you use a different window manager or user for each one. (different versions of KDE or Gnome do not always use compatible configuration files.)
One setup that I have always enjoyed is to make a small "master" partition a primary partition, and make it fairly small. (You could get by with 1Mb.) This is for the Grub setup you boot from. You install Grub here from a live CD with the Grub fist stage on the MBR. You also mark this partition as active. You will have to create the menu yourself, and all it will consist of is a list of the different distributions you want to be able to boot. You will chainload to each distribution's boot loader.
You then create a /boot partition for each distribution - they should be logical partitions in an extended partition. These partitions will be where you will chainload to from the main version of Grub. You can create the /root or LVM partitions and the swap partition at the same time, or leave it to the installer.
When you install each distribution, you tell it to use the /boot partition you created for it, and to install the boot loader to the partition boot record.
A couple of minor details. If you share the swap partition between distributions, you can only resume to the distribution you last hibernated from. If you try to resume to a different distribution, I am not sure what the results will be. I have not tested it, so I do not know what will happen if you hibernate from one distribution, and then boot another one.
You may be able to skip the separate /boot partition for each distribution, and make it part of the root partition. It depends on the drive size and your BIOS limits. You will also need a /boot partition if you your root partition is on a LVM partition.
If you label your /boot partitions, You should probably use something like master for the main Grub partition, and boot1 through boot# for the different distributions.
Your boot options would look something like this:
Master -----Distribution 1 +---Kernel 1 | | | +---Kernel 2 | +---distribution 2 +---Kernel 1 | | | +---Kernel 2 | +---distribution 3 +---Kernel 1 | +---Kernel 2
Your main grub.conf would look something like:
boot=/dev/sda default=0 timeout=30 title Fedora root (hd0,4) chainload +1 title CentOS root (hd0,5) chainload +1 title Ubuntu root (hd0,6) chainload +1
The rest would be the standard Grub configurations except that you would have "boot=/dev/sda5" through "boot=/dev/sda7" for the different distributions. If you want, you can also include a splash screen for the master Grub install.
Mikkel
Mikkel L. Ellertson wrote:
Beartooth wrote:
Well I decided to do it myself and with some help, to wit, if you can click on details do so. Here is what I did to this point.
I know the non-working Ubuntu is at (hd0,7). So I put the cd-rom in and rebooted. It started the cd and Ubuntu came up in it's cd-rom mode. It takes care of Nvidia very well!
So I then said to install. I watched close and when it wanted to make a partition I said Manual. It showed me all the existing stuff and there was (hd0,7) so I told it to formate and put it there.
Later it wanted a name which I gave it and password. Then below that it had a tab saying "Details" so I clicked that. Up came a panel saying it was going to install Grub in (hd0). I erased that and put in (hd0,7) and it took off and loaded a bunch of stuff off the internet and then wanted to reboot. Did that and here I am back on F8 without doing a thing.
I will put in the F8 grub.conf a chainload for Umbutu and that will be that. Get used again to apt-get ...
Karl
Karl Larsen wrote:
Mikkel L. Ellertson wrote:
Beartooth wrote:
Well I decided to do it myself and with some help, to wit, if you can click on details do so. Here is what I did to this point.
I know the non-working Ubuntu is at (hd0,7). So I put the cd-rom in and rebooted. It started the cd and Ubuntu came up in it's cd-rom mode. It takes care of Nvidia very well!
So I then said to install. I watched close and when it wanted to make a partition I said Manual. It showed me all the existing stuff and there was (hd0,7) so I told it to formate and put it there.
Later it wanted a name which I gave it and password. Then below that it had a tab saying "Details" so I clicked that. Up came a panel saying it was going to install Grub in (hd0). I erased that and put in (hd0,7) and it took off and loaded a bunch of stuff off the internet and then wanted to reboot. Did that and here I am back on F8 without doing a thing.
I will put in the F8 grub.conf a chainload for Umbutu and that will be that. Get used again to apt-get ...
Karl
OK. I put in a device in my F8 grub.config that was exactly:
title Ubunto root (hd0,7) Chainloader +1
Now I can boot Ubuntu any time I care to. It takes care of the Nvidia all by itself and I was able to apt-get install gmfsk and xlog which takes care of my Ham Radio on the computer things and they work.
There are things which are odd but most are real nice. It needs updating 188 files so will do that when I turn off this computer around 7pm local and let Ubuntu get up-to-date while I sleep.
Karl
Now, keep in mind, I'm not a software guy. My area is hardware, mainly storage. The only time that I've been able to load two different linux distros on the same machine was when I loaded Ubuntu on a separate hard drive in a machine that was at the time running Mandriva 2007, and it was the last powerpack edition that was available for download as multiple cd iso images. It might have even been the 2006 edition. I really don't remember. Anyway, Once both distros were installed, upon boot up, I was given a choice on which distro I wanted to load. I need to mention that was with Ubuntu 6.10. That's around 2 or 3 versions ago, so I don't know if I would have the same luck now. Mandriva started playing with 3d graphics and some other stuff with their 2007 spring edition. Since then, it hasn't been a very stable distro. In fact, alot of the same problems that I saw in F8, I've seen in the newer releases of Mandriva. In the case of my Dell poweredge server, Mandriva says my video controller sucks too, just like F8 did. I'm no programmer, but I think it has to do with the X.org release that's the heart of the problem. The best I can tell, I'm going to have to put a better video card in the machine, and disable the on-board video controller in order to run the newer release of most of the linux distros. I had been running F7 on it with no trouble, but F8 wouldn't load, so I've tried other distros, and most of them have given me the same video issues as F8. So far, the only distros that I've been able to get to run on the machine are the Red hat EL clones except Cent OS 5.1. Desktop BSD 6.3 runs on it as well. I know some of you are probably going to respond back saying "What does this have to do with Fedora." The reason I brought it up is alot of the problems that have been seen in Fedora, I've noticed in other distros too. Especially, the problem with system stability, and the freezing up issue, and it seems to be worse when running the Gnome enviroment. It's a problem under KDE too, but not as bad
Jim
On Sun, 2008-01-27 at 11:48 -0700, Karl Larsen wrote:
I have tried to load this software as another to keep an eye on, butwhen I do load it it takes over Grub! I didn't see any way to stop it from doing this. Has anyone else had success? If so let me know what to do.
Karl
--
Karl F. Larsen, AKA K5DI Linux User #450462 http://counter.li.org. PGP 4208 4D6E 595F 22B9 FF1C ECB6 4A3C 2C54 FE23 53A7
Jimmy Bradley wrote:
Now, keep in mind, I'm not a software guy. My area is hardware,mainly storage. The only time that I've been able to load two different linux distros on the same machine was when I loaded Ubuntu on a separate hard drive in a machine that was at the time running Mandriva 2007, and it was the last powerpack edition that was available for download as multiple cd iso images. It might have even been the 2006 edition. I really don't remember. Anyway, Once both distros were installed, upon boot up, I was given a choice on which distro I wanted to load. I need to mention that was with Ubuntu 6.10. That's around 2 or 3 versions ago, so I don't know if I would have the same luck now. Mandriva started playing with 3d graphics and some other stuff with their 2007 spring edition. Since then, it hasn't been a very stable distro. In fact, alot of the same problems that I saw in F8, I've seen in the newer releases of Mandriva. In the case of my Dell poweredge server, Mandriva says my video controller sucks too, just like F8 did. I'm no programmer, but I think it has to do with the X.org release that's the heart of the problem. The best I can tell, I'm going to have to put a better video card in the machine, and disable the on-board video controller in order to run the newer release of most of the linux distros. I had been running F7 on it with no trouble, but F8 wouldn't load, so I've tried other distros, and most of them have given me the same video issues as F8. So far, the only distros that I've been able to get to run on the machine are the Red hat EL clones except Cent OS 5.1. Desktop BSD 6.3 runs on it as well. I know some of you are probably going to respond back saying "What does this have to do with Fedora." The reason I brought it up is alot of the problems that have been seen in Fedora, I've noticed in other distros too. Especially, the problem with system stability, and the freezing up issue, and it seems to be worse when running the Gnome enviroment. It's a problem under KDE too, but not as bad
Jim
On Sun, 2008-01-27 at 11:48 -0700, Karl Larsen wrote:
I have tried to load this software as another to keep an eye on, butwhen I do load it it takes over Grub! I didn't see any way to stop it from doing this. Has anyone else had success? If so let me know what to do.
Karl
--
Karl F. Larsen, AKA K5DI Linux User #450462 http://counter.li.org. PGP 4208 4D6E 595F 22B9 FF1C ECB6 4A3C 2C54 FE23 53A7
I have Ubuntu loaded and updated and it co-exists with F7 F7-68 and F8 on 2 hard drives. You just have to do it right.
Karl
-
Beartooth -
Bob Holtzman -
Carroll Grigsby -
Gijs -
Jimmy Bradley -
Karl Hakmiller -
Karl Larsen -
Martin Marques -
Mikkel