[conspire] Pancake story: Xubuntu multi boot custom partition install

Sean sean.channel at pacbell.net
Fri Jan 27 13:15:10 PST 2012


I am full of tinier typos. Also; the link I sent was for ancient old
grub, but you get the idea: "chainloader +1".

On 01/27/2012 12:52 PM, Sean wrote:
> Hi folks. ( I also made a typo and replied just directly at the time.):
>> Regarding partitions, anything higher than sda4 is most certainly an
>> "extended partition", which will be tricky to boot from.  Generally
>> speaking you want any bootable OS to be installed on a "primary
>> partition" (usu. 1 thru 4) for most any multi-boot environment. Extended
>> partitions are a way of having more than 4 "cakes on your stack" by
>> sub-dividing a primary partition.
>>
>> _S
> There is a Master Boot Record (MBR) at the start of the disk, plus each
> partition may have a boot loader at the start of that partition. In
> these cases, to preserve each OS's bootloader and still have a
> multi-boot option, you may need to employ the GRUB technique of
> "chainloading", in which GRUB (installed in the MBR) is directed to load
> the bootloader from the chosen partition (instead of, say, trying to
> load a linux kernel directly). The bootloader on each partition could
> even be another GRUB instance, or lilo, or something else. There is a
> short example on this page:
> http://brunolinux.com/05-Configuring_Your_System/Multiboot_grub.html
>
> I also try to Keep It Super Simple and cheat by using installer GUI's
> that automagically detect all this for me as much as possible, but
> _when_ something goes wrong (e.g. Windows over-writes the MBR) you can
> use the Ubuntu CD to boot the linux partition again, then edit grub.cfg
> or /etc/grub.d/* files for your configuration and run update-grub to
> restore the GRUB MBR.
> _S
>
> On 01/26/2012 08:49 PM, Rick Moen wrote:
>> Quoting Roger Chrisman (roger at rogerchrisman.com):
>>
>>> In which *Ubuntu custom partitioning installer flips but fails to
>>> serve pancakes.
>>  
>> Roger -- 
>>
>> I loved the pancake recipe you included.
>>
>> At the time you posted that query to the mailing list, I was on a trip
>> out of two (to the SCALE conference) and skimmed it but didn't have time
>> to do it justice.  I'm still trying to parse what you posted on the fly,
>> so pardon me if this post ends up missing a target or two.
>>
>> [You were trying to do custom partitioning from an Ubuntu installer
>> on your multiboot laptop.]
>>
>>> error: incompatible license.
>>> grub rescue>
>> Well, that's a bit unsettling, isn't it?
>>
>> This page explains the licence angle, more or less.  The core of GRUB
>> now issues that error if an action causes GRUB to try to load a GRUB
>> module (say, a boot module residing in the superblock of one of your
>> filesystems, or living as a file in the /boot/grub/ directory in 
>> such a filesystem) that upon examination has a licence incompatible with
>> GRUB's GPLv3 licence.  So, if one of your filesystems has some very old
>> boot code in it, GRUB might be refusing to chain-boot to it. 
>>
>>> However, I don't know how to tell Grub2 where boot is, nor do I know
>>> for sure where it is, although I think it may be at the beginning of
>>> the sda drive.
>> Hmm, not quite.
>>
>> The thing is, by going into 'grub rescue>' aka Rescue Mode, GRUB is 
>> trying to be helpful by giving you a chance to tell it where to find the
>> /boot/grub (normal location, though it doesn't actually need to be
>> under /boot) folder, the grub.cfg aka menu.lst file, and the modules that
>> are supposed to live in (I'm pretty sure) /boot/grub.  There's a whole
>> GRUB-specific lingo you can use to talk to it at the 'grub rescue>'
>> command prompt, to tell it where things are and that it should then 
>> attempt to boot again.  The page you cited
>> (https://help.ubuntu.com/community/Grub2#Rescue_Mode_.28.27.27grub_rescue.3E.27.27.29_Booting)
>> has a decent rundown on how to talk to the GRUB command interpreter.
>>
>> Your problem, though, is that you seemingly didn't really know where
>> things were, so your problem was less how to talk to GRUB than what to
>> say to it.
>>
>> Here's an exhaustive rundown on how to talk to GRUB, by the way
>> (the GRUB2 versions fashionable these days):
>> http://dedoimedo.com/computers/grub-2.html .  You can always find 
>> it linked from http://linuxmafia.com/kb/Kernel as recommended docs.
>>
>> Anyway, your core problem was that, after the Ubuntu custom installer
>> got through washing, drying, folding, and starching your filesystems,
>> you really hadn't a clue where you needed to point GRUB towards.
>> To solve that, gosh, I guess I recommend just writing on a paper what
>> your filesystems are at the start, and jot down your changes as you go
>> -- _and_ you should have some idea of how (using what boot components,
>> located where) your system has been booting until then, so you can if 
>> necessary whack GRUB upside the head and say 'Here, and here, and here.'
>>
>> Personally, I like to keep my booting simple.  Here's how things are on
>> my workstation:
>>
>>
>> root at borgia:~# fdisk -l /dev/sda
>>
>> Disk /dev/sda: 80.0 GB, 80000000000 bytes
>> 255 heads, 63 sectors/track, 9726 cylinders
>> Units = cylinders of 16065 * 512 = 8225280 bytes
>> Sector size (logical/physical): 512 bytes / 512 bytes
>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>> Disk identifier: 0xbb59bb59
>>
>>    Device Boot      Start         End      Blocks   Id  System
>> /dev/sda1   *           1        1216     9767488+  83  Linux
>> /dev/sda2            1217        1459     1951897+  82  Linux swap /
>> Solaris
>> /dev/sda3            1460        8510    56637157+  83  Linux
>> /dev/sda4            8511        9726     9767489+   5  Extended
>> /dev/sda5            8511        9726     9767488+  83  Linux
>> root at borgia:~#
>>
>> root at borgia:~# cat /etc/fstab
>> /dev/sda1   /           ext3 defaults,relatime,errors=remount-ro  0    1   
>> /dev/sda2   none        swap sw                                   0    0   
>> /dev/sda3   /usr        ext3 defaults,relatime,errors=remount-ro  0    2   
>> /dev/sda5    /mnt/stuff ext3 defaults,relatime,errors=remount-ro  0    2   
>> root at borgia:~#
>>
>> Three data-bearing partitions, plus a swap partition.  GRUB launches
>> from the MBR (master boot record), finds the intended root filesystem 
>> on /dev/sda1 (which it thinks of as '(hd0,1)'), digs through that
>> filesystem's tree to find /boot/grub, and finds grub.conf and the
>> modules there, which in turn permit it to do the rest of the boot steps
>> -- finding a kernel and initrd, and so on.
>>
>> If you have MS-Windows in the picture, it's common to concede the MBR to
>> Microsoft, make the Microsoft MBR loader branch first to a filesystem
>> where GRUB lurks in the filesystem superblock, and let GRUB give you
>> your boot choices from there. 
>>
>>
>>> So I decided to redo the install, this time without
>>> checking the "[  ] install proprietary software and drivers" box.
>>> However, I still used the custom partitioning option to install
>>> between existing partitions. After this re-install, at reboot I again
>>> got:
>>>
>>> error: incompatible license.
>>> grub rescue>
>> Conclusion:  Your problem didn't lie in the software you installed from
>> the Ubuntu CD at all, but rather in the fact that the controlling GRUB
>> instance was still looking somewhere inappropriate for GRUB modules, 
>> probably on the wrong filesystem, where you had some ancient GRUB files
>> it didn't like.
>>
>>> I had been trying to pancake a new install between existing partitions
>>> using the installer's custom partitioning option.  Installer didn't
>>> like that and tried to pancake down the other partitions, sda6 to
>>> sda5, sda7 to sda6, etc. and put my install above them, on sda10,
>>> instead of on sda5 where I had told it to.
>> Annoyingly, a lot of distro installers' partitioning steps persist in
>> believing they're wiser than you and rearrange things you tell them to
>> do into something different you didn't ask for.  I remember the first
>> time the Red Hat Linux (this is ages ago) 'anaconda' installer attempted
>> that sort of malarky on me.  I just backed out of the graphical
>> partitioning screen, hit Ctrl-Alt-F1 to open a text console, and ran
>> good ol' /sbin/fdisk, which is user-hostile as all hell but puts you
>> completely in charge.  I completed my partitioning, saved to disk,
>> did Ctrl-Alt-F7 to switch back into the graphical installer, and 
>> continued _without_ using Red Hat's partitioner.
>>
>> I'm not saying you need to share my love for a cranky old user-hostile
>> partitioning program, but there's something to be said for using a
>> partitioning tool _you_ like.  E.g., find a live-CD disk with a
>> partitioner you like, and use that rather than the distro installer's
>> custom partitioning screens to set things up.  Some folks like
>> PartedMagic (PMagic).  I burn new CDs for the CABAL collection as new
>> versions come out, and you're most welcome to try them.  (If you're
>> desperate, you can talk me into giving you my disk, and I'll download
>> and burn a replacment for myself.)
>>
>>
>>
>>
>>> So I gave the install one last try using the installer's custom
>>> partitioning option. _But_, this time instead of trying to pancake my
>>> fresh install into /dev/sda5, between other existing partitions, I
>>> told the installer to delete all partitions above sda3 (sda1-3 are my
>>> Windows 7 stuff), create a swap partition at sda5 (sda4 is of course
>>> used for the magic that does logical partitions), install Xubuntu
>>> 11.10 on sda6 and leave only free disk space above that.
>>>
>>> That worked!
>> Well, I'm glad you got there, anyway.
>>
>>
>> _______________________________________________
>> conspire mailing list
>> conspire at linuxmafia.com
>> http://linuxmafia.com/mailman/listinfo/conspire
>>




More information about the conspire mailing list