Help with Windows XP dual boot

[oshunluvr]

Found your problem:

http://en.wikipedia.org/wiki/FlexNet_Publisher


Solution is ugly:

http://ubuntuforums.org/showthread.php?t=1661254


I would just wipe the drive, re-install XP, then re-install Kubuntu elsewhere.

This also covered here: https://www.kubuntuforums.net/showth...hlight=flexnet

[mr_raider]

This also covered here: https://www.kubuntuforums.net/showth...hlight=flexnet

A quick google reveals a ridiculous number of programs that try to insert themselves between the MBR and sector 63 like some pervert on the subway. Does this crap happen with EFI installs?

[SteveRiley]

A quick google reveals a ridiculous number of programs that try to insert themselves between the MBR and sector 63 like some pervert on the subway. Does this crap happen with EFI installs?

Nope. Those "subway pervert"-like things all tried, in one way or another, to work around inherent limitations in MBR. GPT -- especially when combined with UEFI -- eliminates the need to use any of them.

One minor nit: s/EFI/UEFI/ -- all modern x86 hardware is based on UEFI firmware. EFI is the older standard, the one that Apple made even worse on their Macs.

[olgarosh]

@mr_raider how do I burn EasyBCD.exe from inside linux? Ive installed wine and the ActiveISO recommended by their site. It crashes when I try to open through wine.

[mr_raider]

@mr_raider how do I burn EasyBCD.exe from inside linux? Ive installed wine and the ActiveISO recommended by their site. It crashes when I try to open through wine.

Forgot you can't boot windows. EasyBCD has to be installed in windows.


You can do it from the windows XP setup CD

https://kb.acronis.com/content/1507

[olgarosh]

Thank you for all your help.
I was actually able to boot into XP by using Rescatux (and manually unplugging all the other drives) but then it was so slow compared to Linux running on the same hardware that I decided to format my 250GB drive and install only Kubuntu. I followed your istructions and it works beautifully.
Again thanks for the help.

[GreyGeek]

... it was so slow compared to Linux running on the same hardware that I decided to format my 250GB drive and install only Kubuntu....

I have Win7 Home Premium in dual boot mode on this Acer V3-771G. Trusty runs noticeably faster than Win7. I usually booted into it about 3 or 4 times a year to let the updates come down and to let MS Security Essentials update. On the average that took about an hour, depending on the number of updates. After Steve Riley posted his advice about MS SE and his suggestion to replace it with MalwareBytes I booted into my Win7 partition to do that. I downloaded MalwareBytess, disconnected the Internet, removed MS SE, rebooted, installed MalwareBytes, reconnected the Internet, disabled Internet Explorer and let NVIDIA update the GFORCE GT650M secondary video chip. Working steadily it took nearly three hours and I lost count of the number of reboots requested. All this for an OS I haven't used since I bought this acer in 2010. Now that the Acer warranty has expired there is nothing really keeping Win7 around except my laziness.

[mr_raider]

I had a similar issue today when trying to install a dual boot Xp/Kubuntui386 system on a Lenovo. The installer ran fine but grub kept on failing the install at the last minute. I was able to install Mint 32 bit Mate however. turns out the issue may be btrfs.

When installing kubuntu I used btrfs for the system partition, and grub was unable to install before sector 63. Mint doesn't have btrfs tools installed on the LiveCD and I used ext4 which worked fine. My guess is grub is too big to fit with btrfs module loaded. A lesson to the wise about old school MBR installs.

What would have been the proper resolution here? A small ext4 /boot partition and then btrfs for the rest?

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

[oshunluvr]

I had a similar issue today when trying to install a dual boot Xp/Kubuntui386 system on a Lenovo. The installer ran fine but grub kept on failing the install at the last minute. I was able to install Mint 32 bit Mate however. turns out the issue may be btrfs.

When installing kubuntu I used btrfs for the system partition, and grub was unable to install before sector 63. Mint doesn't have btrfs tools installed on the LiveCD and I used ext4 which worked fine. My guess is grub is too big to fit with btrfs module loaded. A lesson to the wise about old school MBR installs.

What would have been the proper resolution here? A small ext4 /boot partition and then btrfs for the rest?

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

You've mixed up the causes and outcomes of two totally different things.

Grub needs sector 63 and some windows program used that sector for it's own (and undocumented usually) purposes. This results in the grub install failing - as it should. Grub does not know why the sector is in use, but does not overwrite it in case the data there is important. This error is usually unreported by Ubiquity so the install appears to have succeeded normally when in fact Grub has not installed. Subsequent reboots fail because Grub did not make it onto the hard drive. If the user then boots to a Live environment and attempts a manual grub-install within a terminal/console the error message is apparent. The solution here (as I documented elsewhere) is to erase the contents of the sector(s) that Grub needs and re-install.

None of this has anything to do with your chosen file system. If the Mint installer is failing to correctly install to btrfs, it's because the developers left btrfs support out of their install environment. Again; nothing to do with grub or sector 63. Since grub2 (or grub-pc more correctly) became the default, beginning the file systems at sector 2048 (as the Arch wiki you referenced states) also became the default to leave room for the new, larger version of grub. Evidence of this is the Kubuntu installer works perfectly with btrfs file system installs and a separate boot partition is no longer required or has any benefit.

Point being: the Kubuntu installer failing may be related to sector 63 being occupied, maybe not. There are other reasons why that might happen. I can't really speak to Mint and btrfs. I've never attempted to install it. However, I can state that a partition formatted with btrfs would not mysteriously grow and take over sector 63. It, just like ext4, would occupy only the partition it was assign too with one exception: If you attempted to use the whole device to hold your btrfs file system, rather than a partition. Then, btrfs may block the install of grub.

I've tried to constrain the starting sector of a whole-device btrfs file system to allow room for grub, but I was unsuccessful figuring out the proper format command. I even contacted the btrfs developers and tried to get help on doing that but, like typical software engineers the only response I got was "Why do you want to do that? Just use a partition." So I gave up.

[mr_raider]

I have successfully installed Mint with btrfs in the past. It uses Ubiquity also. The problem is that you have to load btrfs-tools in the live environment. In this case I did not have network access.

The first partition was NTFS for windows starting at sector 63. I did not want to move the partition. Kubuntu was unable to install grub. It failed at the end of the install with a message that grub could not install to /dev/sda. From what I read, when grub loads btrfs modules, it doesn't always fit before sector 63.

I will try to reproduce the error in virtualbox.

[mr_raider]

Didn't have a Kubuntu ISO handy, but Mint throws the same error. Ubiquity should check the space before the 1st partition before installing. Here is the log

Jun  5 02:51:47 mint grub-installer: info: Identified partition label for /dev/sda3: msdos
Jun  5 02:51:49 mint grub-installer: dpkg: warning: ignoring request to remove grub which isn't installed
Jun  5 02:51:49 mint grub-installer: dpkg: warning: ignoring request to remove grub-legacy which isn't installed
Jun  5 02:51:49 mint grub-installer: dpkg: warning: ignoring request to remove grub-efi which isn't installed
Jun  5 02:51:49 mint grub-installer: dpkg: warning: ignoring request to remove grub-efi-amd64-bin which isn't installed
Jun  5 02:51:49 mint grub-installer: dpkg: warning: ignoring request to remove grub-efi-amd64 which isn't installed
Jun  5 02:51:49 mint grub-installer: dpkg: warning: ignoring request to remove grub-efi-amd64-signed which isn't installed
Jun  5 02:51:49 mint grub-installer: dpkg: warning: ignoring request to remove grub-efi-ia32-bin which isn't installed
Jun  5 02:51:49 mint grub-installer: dpkg: warning: ignoring request to remove grub-efi-ia32 which isn't installed
Jun  5 02:51:49 mint grub-installer: info: Installing grub on '/dev/sda'
Jun  5 02:51:50 mint grub-installer: info: grub-install does not support --no-floppy
Jun  5 02:51:50 mint grub-installer: info: Running chroot /target grub-install  --force "/dev/sda"
Jun  5 02:51:50 mint grub-installer: Installing for i386-pc platform.
Jun  5 02:51:52 mint grub-installer: grub-install.real: warning: your core.img is unusually large.  It won't fit in the embedding area.
Jun  5 02:51:52 mint grub-installer: grub-install.real: error: filesystem `btrfs' doesn't support blocklists.
Jun  5 02:51:52 mint grub-installer: error: Running 'grub-install  --force "/dev/sda"' failed.
Jun  5 02:51:56 mint ubiquity[3743]: Reverting lockdown of the desktop environment.

[oshunluvr]

The first partition was NTFS for windows starting at sector 63. I did not want to move the partition. Kubuntu was unable to install grub. It failed at the end of the install with a message that grub could not install to /dev/sda. From what I read, when grub loads btrfs modules, it doesn't always fit before sector 63.

You could be right. That would certainly explain why Mint worked and Kubuntu didn't. In that case, I suppose your proposed solution might be your only course, other than moving the windows partition. I believe moving it can be done without problems, but it does seem safer to leave it alone if all you have to do is use ext4 or a boot partition. Of course, not fixing the issue could lead to having to deal with it again down the road. BTW; if it were me I'd use ext2 for a boot partition. No need for ext4 features or overhead if you're just using it for /boot.

[oshunluvr]

Ubiquity should check the space before the 1st partition before installing.

IME, Ubiquity has never been a very well thought out or featured piece of software. For me, there were three whole versions (10.10, 11.04, 11.10) that I couldn't use Ubiquity at all. It simply wouldn't recognize my partitions. At least they made it use subvolumes for btrfs with a default @home. That's a great feature. Too bad it won't let you edit the subvolume names at install. I have 4 different installs to a single btrfs subvolume which I do by installing, then renaming the subvolumes to unique names.

[mr_raider]

IME, Ubiquity has never been a very well thought out or featured piece of software. For me, there were three whole versions (10.10, 11.04, 11.10) that I couldn't use Ubiquity at all. It simply wouldn't recognize my partitions. At least they made it use subvolumes for btrfs with a default @home. That's a great feature. Too bad it won't let you edit the subvolume names at install. I have 4 different installs to a single btrfs subvolume which I do by installing, then renaming the subvolumes to unique names.

What do you use? Thé mini.iso doesn't do 64 bit installs. There is no alternate CD anymore?

[oshunluvr]

You can use the server edition 64bit iso (text installer) and add the desktop. But back when Ubiquity wasn't working for me (it has since 12.04) I did a fresh 10.04 install and upgraded all the way to 11.04. I just skipped 11.10 all together. I don't have windows on my desktop or server so the sector 63 barrier never came up there. I have a work laptop where I ran into it and had to solve it there. My issue was caused by Adobe.

I've been using btrfs since before it was in the kernel by default (version 0.18 or something like that). I've written a thread about how I do my multiple installs to a single btrfs file system. It's cool to have all the free space available to all my installs and home subvolumes. I use a 2x256GB ssd array for my primary OS device. AKAIK, you still can't boot directly to a multi-device btrfs file system. I use a dedicated grub install on a hard drive anyway, so that's not a problem for me.