Overclock.net › Forums › Software, Programming and Coding › Operating Systems › Linux, Unix › Arch Linux Grub (Legacy?) Installation and'Foldix' Display Issues
New Posts  All Forums:Forum Nav:

Arch Linux Grub (Legacy?) Installation and'Foldix' Display Issues - Page 2  

post #11 of 77
I think you need to use GPT which only GRUB2 supports. GRUB2 is not that bad ... i've been testing it in a VM and am about ready to make the jump. I may be wrong but i don't think GRUB1 can do anything with a GPT table. And I know you cannot use a DOS table on a 2TB+ disk.

Quote:
GRUB is horrible. I absolutely hate it.

really? i've had my fights with it (and so has _everyone) but once you understand why you are having the fight with it (user error), it is a pretty nice piece of software. Are there any alternatives that you might suggest instead?
stable again
(25 items)
 
  
CPUCPUMotherboardGraphics
E5-2687W E5-2687W ASUS Z9PED8-WS EVGA GTX 570 (Linux host) 
GraphicsRAMHard DriveHard Drive
EVGA GTX 970 FTW (win7 guest) 64GB G.SKILL 2133 2x Crucial M4 256GB raid1 4x 3TB raid 10 
CoolingCoolingCoolingCooling
2x Apogee HD  2x RX 480 2x MCP 655 RP-452x2 rev2 (new) 
CoolingCoolingOSOS
16x Cougar Turbine CFT12SB4 (new) EK FC 580 Gentoo (host) Gentoo (x23 guests) 
OSMonitorMonitorPower
windows 7 (guest w/ vfio-pci) Viewsonic 23" 1080P Viewsonic 19" Antec HCP Platinum 1000 (new) 
CaseOtherOther
Case Labs TH10 (still the best ever) 2x Lamptron FC-5 IOGEAR 2 way DVI KVM Switch 
  hide details  
stable again
(25 items)
 
  
CPUCPUMotherboardGraphics
E5-2687W E5-2687W ASUS Z9PED8-WS EVGA GTX 570 (Linux host) 
GraphicsRAMHard DriveHard Drive
EVGA GTX 970 FTW (win7 guest) 64GB G.SKILL 2133 2x Crucial M4 256GB raid1 4x 3TB raid 10 
CoolingCoolingCoolingCooling
2x Apogee HD  2x RX 480 2x MCP 655 RP-452x2 rev2 (new) 
CoolingCoolingOSOS
16x Cougar Turbine CFT12SB4 (new) EK FC 580 Gentoo (host) Gentoo (x23 guests) 
OSMonitorMonitorPower
windows 7 (guest w/ vfio-pci) Viewsonic 23" 1080P Viewsonic 19" Antec HCP Platinum 1000 (new) 
CaseOtherOther
Case Labs TH10 (still the best ever) 2x Lamptron FC-5 IOGEAR 2 way DVI KVM Switch 
  hide details  
post #12 of 77
Thread Starter 

Yes but the question is how to install  grub 2 without doing an install of Ubuntu.

 

     
CPUGraphicsRAMHard Drive
Intel Core i7-3630QM NVIDIA GTX 670MX  DDR3 1600 MHz SDRAM 1TB 5400 RPM HGST Travelstar HDD 
Hard DriveOptical DriveOSMonitor
Corsair Neutron GTX 240GB Super-Multi DVD Writer Microsoft Windows 8 64-bit 17.3" HD LED-Backlit Display 
Mouse
Touchpad 
  hide details  
     
CPUGraphicsRAMHard Drive
Intel Core i7-3630QM NVIDIA GTX 670MX  DDR3 1600 MHz SDRAM 1TB 5400 RPM HGST Travelstar HDD 
Hard DriveOptical DriveOSMonitor
Corsair Neutron GTX 240GB Super-Multi DVD Writer Microsoft Windows 8 64-bit 17.3" HD LED-Backlit Display 
Mouse
Touchpad 
  hide details  
post #13 of 77
Quote:
Originally Posted by lloyd mcclendon View Post

really? i've had my fights with it (and so has _everyone) but once you understand why you are having the fight with it (user error), it is a pretty nice piece of software. Are there any alternatives that you might suggest instead?

Not really, that's why I'm stuck with it.
I used LILO for as long as I possibly could but these days it's so unsupported that running LILO takes more effort than GRUB. I really like FreeBSD's boot manager though.

I know with a little patence GRUB can be mastered, but it's so over-engineered and needlessly complicated - which is doubly infuriating as the only way to test if it's worked is to reboot and if that fails then it's a complete pain in the arse to get your original install back (live CD->chroot->blahblahblah).

Then you have GRUB1, GRUB2, GRUB-GFX and some weird hacky stuff that RHEL and SLES ship. All of them behave slightly differently from the others so you have to be on your guard when switching between distros.

Worst of all, most of the added complexity end up just being bloat. I remember one install, GRUB took longer to load than the menu was on screen for (loading from GRUB1->GRUB1.5 then 2 second time out)

I know this isn't the fault of GRUB but rather package maintainers, but some distros put some real pointless crap in GRUB too. Like on OpenSuse, randomly (roughly 1 in 10 boots IIRC) you'd get a snow-scape scene with little Tux's falling down the side of the screen. I mean what the hell is all that about?

So yeah, if you can't tell already, I have a mild dislike of GRUB laugher.gif
post #14 of 77
Thread Starter 

Well I also dislike Grub 1 which is what Arch seems to come with; however the way Ubuntu does it (not to mention Grub2) is a much better method IMO.

     
CPUGraphicsRAMHard Drive
Intel Core i7-3630QM NVIDIA GTX 670MX  DDR3 1600 MHz SDRAM 1TB 5400 RPM HGST Travelstar HDD 
Hard DriveOptical DriveOSMonitor
Corsair Neutron GTX 240GB Super-Multi DVD Writer Microsoft Windows 8 64-bit 17.3" HD LED-Backlit Display 
Mouse
Touchpad 
  hide details  
     
CPUGraphicsRAMHard Drive
Intel Core i7-3630QM NVIDIA GTX 670MX  DDR3 1600 MHz SDRAM 1TB 5400 RPM HGST Travelstar HDD 
Hard DriveOptical DriveOSMonitor
Corsair Neutron GTX 240GB Super-Multi DVD Writer Microsoft Windows 8 64-bit 17.3" HD LED-Backlit Display 
Mouse
Touchpad 
  hide details  
post #15 of 77
Have a look at arch linux's grub2 guide.

I noticed you were talking about using GPT, so that right there might be your issue, as i don't think grub legacy supports GPT tables.

https://wiki.archlinux.org/index.php/GRUB2

It tells you how to chroot into your install to install grub2 instead of grub legacy, and tells you how to install for an EFI/GPT system and how to install for a regular mbr system.
Router
(12 items)
 
  
Router
(12 items)
 
  
post #16 of 77
Quote:
Originally Posted by Plan9 View Post

I wouldn't recommend that as any time mkinitcpio is called you're potentially going to brick your brick your install.
@OP: It sounds to me like the partition table. Are you installing to MBR? I suspect you're not and if that's the case then that might be a workable solution for you
[edit]
oops, just read on and you've already found the cause. I still think installing to MBR might work though (rather than destroying your install completely)

What on earth are you talking about? I've done that countless times, without ANY problems. Brick isn't really appropriate for this. The worst thing you do is have a bad kernel, which the #1 rule is to always have a backup. Also, while MBR would work he would have to re-install for that to work anyways. You don't really change GPT to MBR, so there is no installing to MBR.

[edit] After thinking about it, I can't really see how mkinitcpio would even get messed up. None of the grub packages should handle that command. [looking]

http://www.archlinux.org/packages/core/any/mkinitcpio/
Code:
bash
coreutils
file
filesystem>=2011.10-1
findutils
grep
gzip
kmod>=3
libarchive
mkinitcpio-busybox>=1.19.4-2
sed
util-linux>=2.21
bzip2 (optional) - Use bzip2 compression for the initramfs image
lzop (optional) - Use lzo compression for the initramfs image
mkinitcpio-nfs-utils (optional) - Support for root filesystem on NFS
xz (optional) - Use lzma or xz compression for the initramfs image

I know Arch isn't every distro but I'm going to go out on a limb and say those dependencies won't change much. Do you see grub? I don't. Oh, wait, if mkinitcpio isn't at all related to grub how on earth are you going to break it? You won't. Grub has very few dependencies and very few reverse dependencies.

[from gentoo reverse dependencies]
Code:

app-admin/qgrubeditor
app-emulation/xen
app-misc/anaconda-runtime
app-misc/cl-base-meta
kde-misc/kgrubeditor
media-gfx/grub-splashes
pentoo/pentoo
pentoo/pentoo-installer
sys-apps/calculate
sys-apps/calculate-install
sys-apps/memtest86+
sys-boot/boot-update
sys-kernel/linux-sabayon
sys-kernel/linux-sabayon-sources
sys-meta/sys-base
x11-themes/sabayon-artwork-core

Hmmm, me thinks your very wrong.
Edited by mushroomboy - 3/21/12 at 4:45pm
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
post #17 of 77
Thread Starter 

I finally got it installed; Dad had an extra HDD so I installed Ubuntu.

 

Now I need help with the bugs listed here at the bottom namely the display problems.

 

http://www.overclock.net/attachments/1484

 

The text file is for this version of Arch http://www.overclock.net/t/1156650/foldix-an-smp-and-nvidia-gpu3-folding-linux-distro-released

     
CPUGraphicsRAMHard Drive
Intel Core i7-3630QM NVIDIA GTX 670MX  DDR3 1600 MHz SDRAM 1TB 5400 RPM HGST Travelstar HDD 
Hard DriveOptical DriveOSMonitor
Corsair Neutron GTX 240GB Super-Multi DVD Writer Microsoft Windows 8 64-bit 17.3" HD LED-Backlit Display 
Mouse
Touchpad 
  hide details  
     
CPUGraphicsRAMHard Drive
Intel Core i7-3630QM NVIDIA GTX 670MX  DDR3 1600 MHz SDRAM 1TB 5400 RPM HGST Travelstar HDD 
Hard DriveOptical DriveOSMonitor
Corsair Neutron GTX 240GB Super-Multi DVD Writer Microsoft Windows 8 64-bit 17.3" HD LED-Backlit Display 
Mouse
Touchpad 
  hide details  
post #18 of 77
Quote:
Originally Posted by mushroomboy View Post

What on earth are you talking about? I've done that countless times, without ANY problems.
Fair enough in this instance then. But if you try to update your GRUB menu where the installed tools are different to the installed menu, you can cause problems. So I was just warning about the potential as it's better to be safe than sorry.
Quote:
Originally Posted by mushroomboy View Post

Brick isn't really appropriate for this. The worst thing you do is have a bad kernel, which the #1 rule is to always have a backup.
Brick was just a lazy term but you'd still have an unbootable install. Also you wouldn't have a bad kernel, you'd have a bad boot menu. The kernel would be fine as that's an entirely separate entity from GRUB - so backing up the kernel wouldn't make any difference in this particular case study.
Quote:
Originally Posted by mushroomboy View Post

Also, while MBR would work he would have to re-install for that to work anyways.
No he wouldn't.
1. Boot an Arch CD
2. mount /dev/sda1 /mnt (or whatever his root partition is)
3. mount the boot partition to /mnt/boot (if he has a separate boot volume - if not skip this step)
4. do a virtual mount for proc and dev to /mnt/*
5. chroot /mnt
6. now you're effectively booted into your installed copy of Linux, so just run the CLI GRUB tools.
Quote:
Originally Posted by mushroomboy View Post

You don't really change GPT to MBR, so there is no installing to MBR.
I don't follow. An MBR will exist regardless of the partitioning of the disk as it's sector 0.
Quote:
Originally Posted by mushroomboy View Post

[edit] After thinking about it, I can't really see how mkinitcpio would even get messed up. None of the grub packages should handle that command.
Fair question. The reason it would is because mkinitcpio builds the init kernels (which are different from the main Linux kernel you'd be running at the moment) and so on. This it needs to update your boot menu to reflect the new builds. GRUB itself isn't a dependency of mkinitcpio as it can run against other boot menus (with varying degrees of success) but it does need to call and update your boot menu config otherwise your system will try to boot from the old (and now defunct) init blobs.
Quote:
Originally Posted by mushroomboy View Post

I know Arch isn't every distro but I'm going to go out on a limb and say those dependencies won't change much. Do you see grub? I don't. Oh, wait, if mkinitcpio isn't at all related to grub how on earth are you going to break it? You won't. Grub has very few dependencies and very few reverse dependencies.

Hmmm, me thinks your very wrong.
I'd suggest you trying being polite before jumping on a superiority complex because there's a number of users on here with a great deal more expertise than yourself. So make assumptions before giving them the benefit to explain the system better will only blow up in your face. (and I say this as a polite warning because I've been there, done that and thus made myself look foolish in the past too)
Edited by Plan9 - 3/22/12 at 2:21am
post #19 of 77
Quote:
Originally Posted by Plan9 View Post

Fair enough in this instance then. But if you try to update your GRUB menu where the installed tools are different to the installed menu, you can cause problems. So I was just warning about the potential as it's better to be safe than sorry.
Brick was just a lazy term but you'd still have an unbootable install. Also you wouldn't have a bad kernel, you'd have a bad boot menu. The kernel would be fine as that's an entirely separate entity from GRUB - so backing up the kernel wouldn't make any difference in this particular case study.
No he wouldn't.
1. Boot an Arch CD
2. mount /dev/sda1 /mnt (or whatever his root partition is)
3. mount the boot partition to /mnt/boot (if he has a separate boot volume - if not skip this step)
4. do a virtual mount for proc and dev to /mnt/*
5. chroot /mnt
6. now you're effectively booted into your installed copy of Linux, so just run the CLI GRUB tools.
I don't follow. An MBR will exist regardless of the partitioning of the disk as it's sector 0.
Fair question. The reason it would is because mkinitcpio builds the init kernels (which are different from the main Linux kernel you'd be running at the moment) and so on. This it needs to update your boot menu to reflect the new builds. GRUB itself isn't a dependency of mkinitcpio as it can run against other boot menus (with varying degrees of success) but it does need to call and update your boot menu config otherwise your system will try to boot from the old (and now defunct) init blobs.
I'd suggest you trying being polite before jumping on a superiority complex because there's a number of users on here with a great deal more expertise than yourself. So make assumptions before giving them the benefit to explain the system better will only blow up in your face. (and I say this as a polite warning because I've been there, done that and thus made myself look foolish in the past too)

1) Boot menu won't ever go bad. there is an argument for that, don't remember what it is but you pass it to grub and it's explicitly for installing grub to discs from anther system. If you just use the mounted /boot it makes things easier. I tend to pass the argument and mount the old /boot so when I pass it the argument is still --switch=/boot (--switch is obviously not the command).

2) If you have /boot right and you installed it properly grub2-mkconfig -o /boot/grub/grub.cfg should work the same EVERY time. You should still have grub2 on this system, so it's going to still have the scripts. Yeah not binaries, scripts that output to /boot/grub/grub.cfg so the grub menu would still work.

3)http://www.rodsbooks.com/gdisk/mbr2gpt.html

You would have to do a tricky conversion that doesn't fully work. From what I read (brisk) you would get a working system and should be able to convert.

So i still don't see how grub.cfg (menu) would fail, nor do I see the other program failing.
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
post #20 of 77
Quote:
Originally Posted by mushroomboy View Post

1) Boot menu won't ever go bad. there is an argument for that, don't remember what it is but you pass it to grub and it's explicitly for installing grub to discs from anther system. If you just use the mounted /boot it makes things easier. I tend to pass the argument and mount the old /boot so when I pass it the argument is still --switch=/boot (--switch is obviously not the command).
2) If you have /boot right and you installed it properly grub2-mkconfig -o /boot/grub/grub.cfg should work the same EVERY time. You should still have grub2 on this system, so it's going to still have the scripts. Yeah not binaries, scripts that output to /boot/grub/grub.cfg so the grub menu would still work.
3)http://www.rodsbooks.com/gdisk/mbr2gpt.html
You would have to do a tricky conversion that doesn't fully work. From what I read (brisk) you would get a working system and should be able to convert.
So i still don't see how grub.cfg (menu) would fail, nor do I see the other program failing.

1. boot menu updates can break previously working installs depending on how the updates are being pushed. Some are loaded entirely into the MBR. Some are loaded on the partition table. Some are loaded on the disk itself with only a chainloader installed on the MBR. If you've got an install that's entirely in MBR and then move to a file system based one, the latter might assume that the MBR is already correct and thus not update that and then you end up with a mismatched install. I'm not saying that would happen in this instance (nor in most case studies), but what you're recommending is a nasty work around so I'm just saying you should be careful when mix and matching boot menus - which is all I was expressing previously.

It's one thing to say "yeah it can be done in theory" however it's an entirely different thing to support users doing a nasty kludge that could potentially break and thus prevent them from booting their OS. A much saner solution is to address the issues with Arch's install of GRUB.

2. you're still missing the point of what I'm saying. Plus your own post is missing the point of your original comment as you recommended creating an Archline boot menu in Ubuntu. So Archlinux wouldn't have Ubuntu's config files. So the whole point of the cfg files still being around is moot.

3. Ahh excellent. I'll have a read of this later. Thank you smile.gif
Edited by Plan9 - 3/22/12 at 6:13am
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Linux, Unix
This thread is locked  
Overclock.net › Forums › Software, Programming and Coding › Operating Systems › Linux, Unix › Arch Linux Grub (Legacy?) Installation and'Foldix' Display Issues