First of all this seems to be  generic issue, this means it shouldn't be assigned to the LXDE livecd but to anaconda, the installer. But before I reassign this bug, I first need to fully understand it.

(In reply to Fred J. Tydeman from comment #0)
> Boot Live system. During install to hard disk in existing partition (which is
> reformatted by the install), pick the option to not write the MBR (Master
> Boot Record).

What option do you mean exactly? Do not "initialize" the disk or do not install the boot loader to the MBR? If you choose to install the boot manager to the first secotors of the boot partition, was this partition marked bootable in the partition table?

> Reboot and select that partition from the IBM OS/2 boot manager. 
> That gets an error message (something like partition not formatted).

I have no idea about the OS/2 boot manager (isn't that dead for years?). What exactly does this message say?

> Reinstalled a second time, this time I picked the option to write the MBR.
> Afer install and shutdown, the system booted to the GRUB2 menu on the FC19 
> partition and would boot FC 19.

As expected.

> I then booted Windows from the FC 19 GRUB2 menu and used DFSEE to rewrite the
> MBR back to the IBM OS/2 boot manager.
> 
> Everything would then boot (Windows, OS/2, Linux FC 15, 16, 17, 18), except
> that FC 19 would no longer boot - 

As expected. You installed the F19 boot loader to the MBR but overwrote it.

> same error message about an unformatted
> partition (if I remember correctly).

Again, please give me the exact wording. Was the partition really not formatted or was the error complaining it was not bootable? 

> I then booted FC 15 and added FC 19 entry to the FC 15 GRUB menu.  After a
> reboot of FC 15 GRUB, I picked FC 19 and it booted (not sure if I got the
> FC 19 GRUB2 memu at this point).
> 
> I then did (in FC 19) as su:
>   GRUB_DEFAULT=saved
>   grub2-mkconfig -o /boot/grub2/grub.cfg
>   grub2-install --force --boot-directory=/boot /dev/sda10

And this was the partition you selected for grub install in the first (failed) installation?

> I rebooted the system and picked FC 19 from the IBM OS/2 bootmanager menu
> and it worked (got the FC 19 GRUB2 menu, picked FC 19, and it booted).

So where is the OS/2 boot manager installed after all? MBR?

I did another install (to a different partition today).

Boot Live system off of USB memory stick
Install to Hard Drive
  Install Destination: One local standard disk
    Full Disk Summary and bootloader
      Do NOT install bootloader == I assume this is talking about MBR
      [I did not see any option about "initialize" the disk]
  Modify my disk partitions
    Pick sda25
    Reformat as: ext4
    Mount point: /
    Label: FC19test
    [I never saw an option about grub2 boot menu]
    [I never saw an option about first sectors of boot partition]
After install, shutdown and reboot (via the IBM OS/2 boot manager).
That got me a blank screen with this message:
  Selected partition is not formatted, hit any key.
I hit a key which took me back to the IBM OS/2 boot manager selection screen.

So, booted Fedora Core 15 and added sda25 to its list of partitions to mount.
Looked at sda25 and it is formatted and has most of Linux installed to it.
So, the 'Selected partition is not formatted' error message is a lie.
But, /boot/grub2 only has 'themes' in it (no grub.cfg).
Added FC19 on sda25 to the FC15 grub config file, shutdown reboot FC15 grub,
pick FC19 on sda25 from that menu and FC19 booted (without going thru the FC19 grub2 menu).

So, it looks like anaconda did NOT do:
  grub2-mkconfig  == since /boot/grub2/grub.cfg is missing
  grub2-install   == since that partition is not bootable by IBM bootmngr.

On my system, the MBR points to sda4 (one cylinger primary partition at end of
disk that has IBM OS/2 boot manager).  That boot manager allows me to select
which partition to boot (Windows, Solaris, eCS (aka OS/2), FC 15, 16, 17, 18,
19, 19test).  All of those partitions are marked Bootable.  The boot manager
is marked Active/Startable.

I think that there needs to be two independent options during install:
  MBR:  Leave alone or rewrite with Linux code pointing to /boot
  /boot: Install or not the grub2 boot menu
In addition, /boot should be made bootable; in previous FC versions, I recall
seeing an option about writing the boot record to either MBR or /boot partition.

Yesterday, when I manually re-installed grub2, sda10 was the partition of the 
various FC19 installs.  Since I have done massive updates and installs of
programs to that partition, I have left sda10 alone and picked sda25 today to
experiment with.
[I am glad we are no longer limited to 16 partitions for FC installs.]

(In reply to Fred J. Tydeman from comment #2)
>       Do NOT install bootloader == I assume this is talking about MBR

it's talking about installing the MBR, you can select where to install it to later.

>       [I did not see any option about "initialize" the disk]

You are only asked if the installer cannot find a valid partition table.

> After install, shutdown and reboot (via the IBM OS/2 boot manager).
> That got me a blank screen with this message:
>   Selected partition is not formatted, hit any key.

I guess the message from the OS/2 boot loader is just misleading. The partition is formatted, I mean you did not reformat it, right?

> So, it looks like anaconda did NOT do:
>   grub2-mkconfig  == since /boot/grub2/grub.cfg is missing
>   grub2-install   == since that partition is not bootable by IBM bootmngr.

You choose to *not* install a boot loader, so anaconda is not expected to do any of this. Why do you think there is an error here?

I tried an experiment.  I added an existing  Linux data partition as bootable to the IBM OS/2 boot manager.  I then tried to boot it and got:
  Selected partition is not formatted, hit any key
So, it is a misleading message.

I tried again, installing to sda25.  This time I took the default of install a
bootloader.  I never got the option you mentioned as to where to install the 
bootloader (either MBR or /boot partition).  I consider that a bug.  
So, it destroyed my MBR and booted up the FC19 grub2 menu.

Once I reset the MBR back to booting the IBM OS/2 boot manager (I used DFSee to
do that under windows), it would not boot FC 19 on sda25.  It appears that /boot
is missing the partition boot record.  I consider that a bug.

I can boot FC 19 on sda25 if I use GRUB under FC 15 (except I never get the GRUB2 menu on sda25).  So, the FC 19 partition is OK except for the boot records

I really don't know the OS/2 boot manager and I have no idea what it does when you mark a partition bootable. Can you give me the output of 'fdisk -l' for the device?

[root@localhost ~]# fdisk -l

Disk /dev/sda: 250.1 GB, 250059350016 bytes, 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0xdf5ee900

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63     4112639     2056288+   7  HPFS/NTFS/exFAT
/dev/sda2         4112640    37013759    16450560   bf  Solaris
/dev/sda3        37013760   488375999   225681120    5  Extended
/dev/sda4   *   488376000   488391119        7560    a  OS/2 Boot Manager
/dev/sda5        37013823    45753119     4369648+  83  Linux
/dev/sda6        45753183    49865759     2056288+  82  Linux swap / Solaris
/dev/sda7        49865823    58605119     4369648+  83  Linux
/dev/sda8        58605183    67344479     4369648+  83  Linux
/dev/sda9        67344543    75569759     4112608+  83  Linux
/dev/sda10       76083903    84823199     4369648+  83  Linux
/dev/sda11       84823263   117724319    16450528+  83  Linux
/dev/sda12      117724383   119780639     1028128+   e  W95 FAT16 (LBA)
/dev/sda13      119780703   121836959     1028128+   e  W95 FAT16 (LBA)
/dev/sda14      121837023   125949599     2056288+   e  W95 FAT16 (LBA)
/dev/sda15      125949663   134174879     4112608+   c  W95 FAT32 (LBA)
/dev/sda16      134174943   138287519     2056288+   7  HPFS/NTFS/exFAT
/dev/sda17      138287583   146512799     4112608+   7  HPFS/NTFS/exFAT
/dev/sda18      146512863   150625439     2056288+   7  HPFS/NTFS/exFAT
/dev/sda19      150625503   154738079     2056288+   7  HPFS/NTFS/exFAT
/dev/sda20      154738143   236990879    41126368+   7  HPFS/NTFS/exFAT
/dev/sda21      236990943   269891999    16450528+   7  HPFS/NTFS/exFAT
/dev/sda22      294053823   296110079     1028128+   7  HPFS/NTFS/exFAT
/dev/sda23      296110143   312560639     8225248+   7  HPFS/NTFS/exFAT
/dev/sda24      312560703   394813439    41126368+   7  HPFS/NTFS/exFAT
/dev/sda25      479636703   488375999     4369648+  83  Linux
[root@localhost ~]#

I have added these to FC15 GRUB config:

title FC19 via chain
  rootnoverify (hd0,9)
  chainloader +1
  boot
title FC19Test via chain
  rootnoverify (hd0,24)
  chainloader +1
  boot

When I try to boot FC19test (sda25) from FC15 via the above chain, I get:
 Error 13: Invalid or unsupported executable format
 Press any key to continue...

When I try to boot FC19 (sda10) from FC 15 via the above chain, I get:
 GRUB2 menu of FC 19

So, if I manually do grub2 commands to install a partition boot loader,
(what I did to sda10) then I can boot that Linux.

We need a way to choose where anaconda will put the boot loader:  either
MBR or partition boot record.

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.