[YLUG] Boot issues - replying to Alex'es post

mike cloaked mike.cloaked at gmail.com
Tue Jul 24 10:00:57 UTC 2012


On Mon, Jul 23, 2012 at 10:54 PM, ALEX ARMANI <alex.armani at live.co.uk> wrote:
>
> Posted: Mon Jul 23, 2012 10:38 am    Post subject:
> Thanks for the advice guys. I've run gpart and only my Mint and Ubuntu
> Studio patrtitions are still there and there is no free space. I made sure I
> did everything right. Tried to resize my Ubuntu, created space on my
> hardrive, created a partition formatted it and tried to install Mint on it.
>
> What actually happened, was I removed the first partition with my windows
> restore partition and removed my windows partition and put Mint on the space
> that they occupied. I've got backup dvds for my windows (although I've never
> read how to do it) shortly after it was brand new with all my software
> installed on it. And all my pics and music and videos have been backed up.
>
> The irony now, is I have a perfect Mint install; it'll even play dvds! I
> believe though, that I need to install Windows onto the first partition on
> the drive, so I have to wipe Mint to get Windows back, and the only reason i
> need windows is to run Virtual Dj. oh well...
>

I am catching up late with this thread so I did not see the earlier
post that led to this - but I am guessing you had an issue with grub
or grub2 at the start of the drive - and were trying to fix it?  The
current advice for grub2 (which also applies to grub-legacy as it is
now called) is to have a post-MBR gap of 200MiB between the MBR and
the first partition if you are using BIOS with MBR partitioning.  I
have a laptop which I wanted to make room for this without messing up
my Windows partition on a dual boot machine - and used PartedMagic to
remove a Dell recovery partition - that led to some interesting
jigging about to get a bootable system due to the following:

The grub had already not properly been installed prior to removing
that partition - and once the Dell recovery partition was removed the
number order of the remaining partitions got messed up (well known
problem) - and so the boot files no longer referred to the correct
partitions - so the first step in getting the system working again was
to boot a rescue system (from a usb key in my case) and run fdisk
/dev/sda - followed by "x", "f" and "w" in that order - which fixes up
the partition numbering - of course then the partitions are still
differently numbered from what they were before removing the recovery
partition.

So next using the rescue system, chroot into the linux system on the
hard drive having mounted the /dev within a mount on the new root as
well as the /boot partition - then edit the grub files to properly
label where the root partition is for the linux system when it boots -
and then use grub-install or manual grub recovery by running grub
within the chroot to re-write the MBR on the hard drive.....

Then exit the chroot umount the mount points and reboot - the system
then is recovered to dual boot as before - bit of a long business with
plenty of nervous sweat - but it works.

If you are using GPT partitioning and/or UEFI then it is a whole
different ball game - but with UEFI coming to more and more hardware
this is something we will all have to get used to!

I hope this helps.

-- 
mike c



More information about the York mailing list