Re: Can you help me figure out why I can't get Grub to install from a standard CD .iso?
On Thursday 14 April 2016 15:26:11 Brian wrote:
> On Thu 14 Apr 2016 at 12:57:19 -0400, EGO-II.1 wrote:
> > I've been trying for about a week now to get Debian with the MATE
> > desktop installed on my PC. For some reason it runs the CD fine,
> > then when it gets
>
> Everything is OK up to installing Grub, then.
>
> > to the grub install part? it fails. I have tried by burning the .iso
> > file to
>
> It fails? Presumably there is some feedback? "Fails" is a little
> general as an error message.
>
> > both DVD and CD and it keeps failing on either one. Can anyone shed
> > some light on this matter for me? I have installed Debian from CD's
> > / DVD's in
>
> You are the only one who can bring some light to the issue, including
> where GRUB was installed to and how you partitioned. What does the
> syslog say? That's really your primary source of informaton.
>
> > the past and never experienced this problem. I there something the
> > devs have removed from a standard .iso file? I mean if push comes to
> > shove I'll most likely just have to go the Ubuntu route, but I was
> > trying to deal directly with the "superior server" distro. Any help
> > anyone can provide would be greatly appreciated.
>
> Alternative routes are always interesting.
>
> > Many Thanks!
> >
> > Oh! Here's some "specs" for y'all!
> >
> > MACHINE FOR INSTALL: Dell Inspiron 3650 Desktop/i5/32GB RAM/1TB HDD
> > USED: Debian 8.x .ISO Image w/ The MATE Desktop Environment -DVD
> > USED: Debian 8.x .ISO Image w/ The MATE Desktop Environment - CD
> >
> > FIts just strange that it stops immediately after trying to install
> > grub. What's changed with the .ISO's on the Debian homepage? Is this
> > because if the whole "Systemd" issue?...or is this something they've
> > implemented in order to improve some other feature?
> > AAAArrrrrgggghjhhh!!!
> > (And although this is might seem like a simple
> > "desktop-in-the-backroom-office" type of thing. This is in all
> > actuality the beginning stages of "testing" for the company I work
> > for!!)
>
> Speculation.
I'd be carefull of calling any theory about these failures 'speculation'.
What is a known fact at this location is that the last 4 wheezy installs
I did, failed on the first pass because I allowed the installer to use
a /boot DIRECTORY on the / of the disk. The reboot failed because the
bios could not reach far enough into a big disk that was being filled
from the outside in by the installer, and by the time it got around to
writing the grub stuff, it was too far into the disk for the bios to
find it.
On the 2nd pass at a workable install, I beat the installer into allowing
me to add a 1Gb boot partition as the FIRST partition on the disk. That
can also be fun as I had it overwrite my location choice at least once,
putting the boot partition as the inside partition on the disk.
Obviously that would never work, so I restarted the install with a
fresh, empty partition map, several times until it actually accepted
what I wanted.
I finally did get it to work, and it works very well indeed, even on a 4k
sectored disk. The secret is of course the /boot as the first
partition, guaranteeing that a dumb bios CAN reach far enough into the
disk to find the grub stuff.
Things would be so much simpler if the debian partitioner would recognize
a gparted prepared disk, needing only the partitions name to be
associated with it, but despite my efforts to prepare the disks with
gparted, including a power down and reboot to the gparted cd to verify
that the partitions had indeed been written to the disk, not once did
the wheezy installer recognize such a prepared disk as anything but a
blank slate.
I have not made the jump to jessie yet because the most important app I
run is still based on a 32 bit wheezy install. I hope and pray for the
installer to be fixed to make it compatible with other well known and
standardized partitioners such as gparted by the time I have to enter
that battlefield again.
As it works now, I consider that its broken for 2 reasons, 1st being its
inability to recognize another partitioners perfectly valid partition
table setup already written and mke2fs'd to ext4 on the disk, and its
penchant for moving a partition setup to be used for /boot, to any free
space available on the inside of the disc, beyond the / partition.
Those are not excusable bugs to be blamed on PEBKAC as you've done to me
on many occasions.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: