You are not logged in.
I just want to make sure this gets through because this thread is confusing as f*ck.
The OP has windows installed on a GPT partition table, meaning that it must be UEFI!
Offline
Good point, I'd completely forgotten about that; Windows won't do GPT on BIOS.
Offline
So syslinux is successfully chainloading Windows, it's Windows throwing the error. Did you do any resizing or moving of partitions?
I first installed Windows and then Arch. I have never even touched the windows partitions which are sda1, sda2, sda3, so i don't know how they could be corrupted... But i know that if Linux caused this mess (windows worked fine before Arch install) it can fix it too.
Last edited by 71GA (2013-08-26 00:21:40)
C, ARM, ARM assembly, HTML, CSS, JS, Linux
Offline
I'm scared that it is now going to be necessary to get this thread to a working UEFI state…
Offline
I'm not scared, I'd just leave it to you since I don't have much UEFI experience
71GA, did you change anything in the firmware setup?
Offline
I'm scared that it is now going to be necessary to get this thread to a working UEFI state…
Don't scare me Oh well do it!
How can i check if this is really UEFI? What then?
C, ARM, ARM assembly, HTML, CSS, JS, Linux
Offline
71GA, did you change anything in the firmware setup?
Nope never touched firmware...
EDIT - I have to go to sleep - will continue tomorrow.
Last edited by 71GA (2013-08-26 00:30:31)
C, ARM, ARM assembly, HTML, CSS, JS, Linux
Offline
You really need to spend some time reading up on your setup and what it is you are trying to achieve...
Offline
How did you partition the disk for Linux? Are you absolutely sure it was GPT before you partitioned it? If you partitioned it with gdisk/sgdisk/cgdisk, they will automatically convert an MBR disk to GPT, rendering Windows completely unusable.
Last edited by Scimmia (2013-08-26 00:30:00)
Offline
How did you partition the disk for Linux? Are you absolutely sure it was GPT before you partitioned it? If you partitioned it with gdisk/sgdisk/cgdisk, they will automatically convert an MBR disk to GPT, rendering Windows completely unusable.
I used gdisk to partition yes.
C, ARM, ARM assembly, HTML, CSS, JS, Linux
Offline
Also, what are you installing it onto? That is, is it a pre-built laptop/PC off the shelf or is it custom build? (Why I didn't ask this question earlier, I have no idea)
Last edited by clfarron4 (2013-08-26 00:37:36)
Claire is fine.
Problems? I have dysgraphia, so clear and concise please.
My public GPG key for package signing
My x86_64 package repository
Offline
And you used Windows setup to create it's partitions? If you're using syslinux from [core], not [testing] (which you should be, I seriously doubt you're using testing) you can't be running UEFI. That means Windows created an MBR disk layout, which you then converted to GPT. This will not work. I don't think there's a way to go back, your only options are to either convert to UEFI (if your motherboard will even do that) and reinstall Windows and configure a new Linux bootloader, or start completely over.
Last edited by Scimmia (2013-08-26 00:37:14)
Offline
Theoretically, if it is a UEFI windows installation, the OP should stilll be able to boot into it by turning UEFI back on, if it isn't already, then selecting the windows firmware entry.
But I am now having doubts as the layout of the OP's partitions does not include an ESP at all. But a "system partition" and two big NTFS partitions (presumable one for the system and one blank).
Offline
*If* it's a UEFI Windows installation, you're right. But he's running in BIOS mode right now and claims he didn't change anything in the firmware/BIOS setup, so I'd bet real money that it's a BIOS/MBR Windows installation.
Offline
And you used Windows setup to create it's partitions? If you're using syslinux from [core], not [testing] (which you should be, I seriously doubt you're using testing) you can't be running UEFI. That means Windows created an MBR disk layout, which you then converted to GPT. This will not work. I don't think there's a way to go back, your only options are to either convert to UEFI (if your motherboard will even do that) and reinstall Windows and configure a new Linux bootloader, or start completely over.
Well i found a topic in which a guy did it using syslinux. Topic is located here but it is short and not quite useful:"https://bbs.archlinux.org/viewtopic.php?id=168611". I am interested in using syslinux as i like its simplicity. I don't like the idea of having to reinstall the windows... But will do it if i have to...
I used Windows instalation procedure to create windows partitions sda1, sda2 and sda3 while i used gdisk to create linux partitions sda4, sda5, sda6. So where is the problem here? Should i use gdisk to specify windows partitions and after i wrote the table to disk i should install windows again?
Please tell me something about the basic philosophy on how to solve this so i can decide better.
Last edited by 71GA (2013-08-26 00:49:20)
C, ARM, ARM assembly, HTML, CSS, JS, Linux
Offline
*If* it's a UEFI Windows installation, you're right. But he's running in BIOS mode right now and claims he didn't change anything in the firmware/BIOS setup, so I'd bet real money that it's a BIOS/MBR Windows installation.
I'm thinking you're right here, and the partition map has now been converted to GPT. I know that gptfdisk has the capability of converting things back to MBR/ms-dos, but I'm wondering if windows will freak out that the partition map has "changed" on it even though it hasn't really changed at all. Windows can be so irritatingly picky about those things.
Offline
Well i found a topic in which a guy did it using syslinux. Topic is located here but it is short and not quite useful:"https://bbs.archlinux.org/viewtopic.php?id=168611". I am interested in using syslinux as i like its simplicity. I don't like the idea of having to reinstall the windows... But will do it if i have to...
As I've already set over in that one, the problem is that you've done something completely unrelated to the bootloader, so LinuxChick's solution won't work for you.
Claire is fine.
Problems? I have dysgraphia, so clear and concise please.
My public GPG key for package signing
My x86_64 package repository
Offline
Well i found a topic in which a guy did it using syslinux. Topic is located here but it is short and not quite useful:"https://bbs.archlinux.org/viewtopic.php?id=168611". I am interested in using szslinux as i like its simplicity. I don-t like the idea of having to reinstall the windows... But will do it if i have to...
That thread has absolutely nothing to do with your problem
I used Windows instalation procedurte to create windows partitions sda1, sda2 and sda3 while i used gdisk to create linux partitions sda4, sda5, sda6. So where is the problem here? Should i use gdisk to specify windows partitions and after i wrote this to disk i should install windows again?.
The problem is that you used gdisk instead of fdisk. In doing this you converted the entire partition layout of your disk to something that isn't compatible with your Windows installation. Just reinstalling Windows again won't work as Windows cannot use GPT on a BIOS system. You need either an MBR disk layout on a BIOS system or a GPT disk layout on a UEFI system.
Scimmia wrote:*If* it's a UEFI Windows installation, you're right. But he's running in BIOS mode right now and claims he didn't change anything in the firmware/BIOS setup, so I'd bet real money that it's a BIOS/MBR Windows installation.
I'm thinking you're right here, and the partition map has now been converted to GPT. I know that gptfdisk has the capability of converting things back to MBR/ms-dos, but I'm wondering if windows will freak out that the partition map has "changed" on it even though it hasn't really changed at all. Windows can be so irritatingly picky about those things.
Worth a shot, nothing to lose at this point. Do you have any info on how it's done?
Last edited by Scimmia (2013-08-26 00:58:44)
Offline
WonderWoofy wrote:Scimmia wrote:*If* it's a UEFI Windows installation, you're right. But he's running in BIOS mode right now and claims he didn't change anything in the firmware/BIOS setup, so I'd bet real money that it's a BIOS/MBR Windows installation.
I'm thinking you're right here, and the partition map has now been converted to GPT. I know that gptfdisk has the capability of converting things back to MBR/ms-dos, but I'm wondering if windows will freak out that the partition map has "changed" on it even though it hasn't really changed at all. Windows can be so irritatingly picky about those things.
Worth a shot, nothing to lose at this point. Do you have any info on how it's done?
There is this (found via the ArchWiki). You'll be looking about 3/4 the way down the page.
Just one thing. If you go ahead and do this GPT to MBR, isn't this going to cause problems for the Arch installation because of the way logical partitions work? (That said, if it does, he could just nuke what came out of the Arch installation and start again).
Last edited by clfarron4 (2013-08-26 01:01:03)
Claire is fine.
Problems? I have dysgraphia, so clear and concise please.
My public GPG key for package signing
My x86_64 package repository
Offline
You can do it interactively from gdisk. I forget what particular letters it takes, but the menus make it pretty apparent. It might be in the "recovery and transformation" section… or possibly the "experts" section.
Offline
Oh, and after you do it, make sure to check your partition layout and adjust syslinux.cfg, your partition numbers will change.
Offline
The OP has definitely installed Windows in BIOS-MBR mode and then converted the installation to GPT via gdisk. Windows stores its bootloader and config (BCD) files in its "SYSTEM" partition. In BIOS systems, the "SYSTEM" partition is always NTFS formatted (about 100-200 MB or MiB) and contains the Windows bootsector and the bootmgr file, one of which is chainloaded by linux bootloaders to boot Windows. Windows bootmgr in BIOS systems can work only with MBR partitions, so it is not possible to boot Windows in GPT with BIOS bootmgr.
In UEFI, EFI System Partition itself acts as the Windows "SYSTEM" partition, and UEFI Spec mandates ESP to be FAT32 formatted (some firmwares allow FAT16). So apart from the partition table, another indication of whether Windows boots in BIOS or UEFI mode is the filesystem used in Windows "SYSTEM" partition.
@71GA:
Now you have 2 options. You can either convert the disk back to MBR (gdisk supports this), but still you may have to reinstall Windows bootloader by running Rescue mode in Windows DVD/USB, because Windows BIOS bootmgr and BCD are heavily dependent on the partition location in the disk and/or order in the partition table. Even if you convert back to MBR, you should make sure the new MBR partition layout matches exactly with the old MBR partition layout when Windows was booting properly.
If your system supports UEFI boot and if you want to retain GPT (recommended over going back to MBR), you can install Windows UEFI bootloader (bootmgfw.efi) and the related config (UEFI-GPT specific BCD, BIOS-MBR based BCD cannot be used here), you need to format the existing "SYSTEM" partition as FAT32 and mark it as ESP (EF00 type code in gdisk). Then you need to boot Windows DVD/USB in UEFI mode and run its Rescue program which will then setup bootmgfw.efi and BCD in the new ESP. For more info - https://gitorious.org/tianocore_uefi_du … OS_to_UEFI .
In my experience with Windows, Windows in BIOS-MBR system freaks out on changes to partition layout, but does not do so in UEFI-GPT system. In the latter case, both the UEFI firmware and Windows BCD use Unique Partition GUID to reference partitions, so it is independent of partition layout in the disk or the table, as long as the Unique Partition GUIDs remain unaltered.
Last edited by the.ridikulus.rat (2013-08-26 11:41:38)
Offline
if you want to retain GPT (recommended over going back to MBR),
This looks like the way to go ATM to solve this problem. But what if i want to quit and reinstall both systems from scratch. How do i have to install both systems in order not to screw this up again? Please tell me some basic staps. I perfer to learn this (over that UEFI option) because i will use this procedure many times & UEFI looks kind of hard...
I can shange my mind if you convince me that UEFI way isn't that hard...
Last edited by 71GA (2013-08-26 09:38:24)
C, ARM, ARM assembly, HTML, CSS, JS, Linux
Offline
the.ridikulus.rat wrote:if you want to retain GPT (recommended over going back to MBR),
This looks like the way to go ATM to solve this problem. But what if i want to quit and reinstall both systems from scratch. How do i have to install both systems in order not to screw this up again? Please tell me some basic staps. I perfer to learn this (over that UEFI option) because i will use this procedure many times & UEFI looks kind of hard...
I can shange my mind if you convince me that UEFI way isn't that hard...
RTFM
https://wiki.archlinux.org/index.php/Un … _Interface
https://wiki.archlinux.org/index.php/UEFI_Bootloaders
https://wiki.archlinux.org/index.php/GU … tion_Table
https://wiki.archlinux.org/index.php/HCL/Firmwares/UEFI
For better or worse, uefi is the future. I suggest you learn it now rather than later.
Last edited by the.ridikulus.rat (2013-08-26 09:47:53)
Offline
@71GA:
Now you have 2 options. You can either convert the disk back to MBR (gdisk supports this), but still you may have to reinstall Windows bootloader by running Rescue mode in Windows DVD/USB, because Windows BIOS bootmgr and BCD are heavily dependent on the partition location in the disk and/or order in the partition table.If your system supports UEFI boot and if you want to retain GPT (recommended over going back to MBR), you can install Windows UEFI bootloader (bootmgfw.efi) and the related config (UEFI-GPT specific BCD, BIOS-MBR based BCD cannot be used here), you need to format the existing "SYSTEM" partition as FAT32 and mark it as ESP (EF00 type code in gdisk). Then you need to boot Windows DVD/USB in UEFI mode and run its Rescue program which will then setup bootmgfw.efi and BCD in the new ESP. For more info - https://gitorious.org/tianocore_uefi_du … OS_to_UEFI .
Between WonderWoofy and Scimmia (with a tiny bit of input from myself. They did most of the work.), we worked out that 71GA probably isn't running the MBR set-up and not UEFI hardware, so the first option is what we recommended.
But thanks for summarising the two options he has if he has access to UEFI hardware and just hasn't told us/doesn't know about it.
Claire is fine.
Problems? I have dysgraphia, so clear and concise please.
My public GPG key for package signing
My x86_64 package repository
Offline