I have an hp computer 64 bits with efi boot and Windows 7. I have installed OpenSuse successfully in a 300 GB partition. After installed OpenSuse, when I tried to access to Windows partition, I become following error message
I don’t know whether I can help. I have Win8 and opensuse in efi boot, but I don’t know about Win7.
We are going to need more information.
(a) provide the output from
# efibootmgr -v
That needs to be run in a terminal window as root. Please use code tags around the output. Clicking the “#” button in the forum edit window will do that. If you paste in the output, then select what you just pasted in with the mouse and click that “#”.
(b) provide the output from
# parted -l
Also do as root from a terminal window, and also use code tags.
The first of those commands gives us information about your efi setup. The second gives us the disk partitioning information.
I think your only choice is to enter the PC UEFI setup and select Windows to boot. Its due to these oddities that I have stuck with MBR formatted boot disks where the grub 2 menu still works, including with Windows 8.1.
If I am reading that correctly, then you are using two EFI partitions, probably “/dev/sda1” used for booting Windows and “/dev/sda5” for booting opensuse.
That did not work for me with Windows 8, but has since been fixed. But possibly, Windows7 is a bit more fussy.
I think you should be able to boot Windows, after running opensuse, by using the command:
# efibootmgr -n 0
That tells your BIOS to boot from entry 0, which is Windows, on the next boot. After that, it will go back to booting opensuse until you repeat that command.
Maybe you can try that. If it doesn’t work, then there is something more seriously wrong with your Windows installation. If it does work, we can probably find ways to set it up so you won’t have to do that every time.
Unfortunately, that indicates that there is something broken in your Windows installation. You’ll need to do a Window repair. And I’m not a Windows expert, so I don’t know how to advise you on that.
You could perhaps try
# efibootmgr -n 7
That boots directly from the disk, rather than the Windows nvram entry. My guess is that this won’t work either, but there’s an outside chance that Windows tries to do some repairing when you boot that way.
x1-6-80-c1-6e-f3-6a-19:~ # parted -l
Model: ATA Hitachi HDS72101 (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt_sync_mbr
Number Start End Size File system Name Flags
1 1049kB 106MB 105MB fat32 EFI system partition boot
2 106MB 240MB 134MB Microsoft reserved partition msftres
3 240MB 666GB 665GB ntfs Basic data partition
5 666GB 666GB 172MB fat16 primary boot
6 666GB 668GB 2155MB linux-swap(v1) primary
7 668GB 689GB 21.5GB ext4 primary
8 689GB 988GB 298GB ext4 primary
4 988GB 1000GB 12.5GB ntfs Basic data partition
Your second ESP/EFI partition is FAT16, and that is where Grub2 is installed and where you are booting from, if I understand things correctly. Windows would never create that partition. Windows (8 in particular, and if memory serves me right, that goes for W7 and Vista as well) doesn’t like anything but FAT32 when it comes to ESP partitions. That’s the first thing you need to fix if you want Windows to go with you. That may even be all you need to get things going.
Boot from an openSUSE live DVD and start gparted. Point it to your second ESP partition and convert it from FAT16 to FAT32. (You may even be able to do it from inside your already installed openSUSE, but you will need to dismount the ESP partition prior to converting its file system and that may pose a problem. I am a little unsure, but I don’t think you will need the ESP partition once booted except for maintenance and modifications. Which also means you can safely discard it after booting. The mount point is /EFI).
The EFI partition is normally mounted at “/boot/efi”. You are right, that it is not needed after booting. Actually, it is not needed during booting either. It is only needed when grub or grub.cfg is being updated.
I’m not sure that the FAT16 or FAT32 actually matters. Windows uses FAT32, but it seems able to read the FAT16 EFI partition on my second disk. Okay, that’s Win8, not Win7.
Reformatting to FAT16 might cause problems if it changes the UUID of the partition. There’s a reference to the UUID in “grub.cfg”. There’s a reference to the GUID of the partition (from the partition table) in NVRAM, and I’m not sure if gparted would change that on a reformat.
**@**valentz: Stop! Read this before you continue according to my instructions!
I am truly embarrased! Here are several mistakes on my part.
I stand corrected. My mounting of the ESP partition under /EFI remains from my previous testing.
I must admit I haven’t tested that myself, but according to Booting from GPT (the maker of gdisk): “Windows 7 insists that its ESP use the FAT32 filesystem. If a disk has a FAT16 ESP, Windows will try to create a new FAT32 ESP. If it can do so, installation will proceed to a point but then fail. Unfortunately, many Linux installers create FAT16 ESPs by default, so you may need to back it up, create a new FAT32 filesystem, and restore the files if you install Linux first.”.
But, ok, he is talking about installing W7. Not booting afterwards, like we have here. That may be the difference needed in this case, so you may be right and my suggestion may not be needed. However, doing disk/partition checks from within W7 using MS tools is not a good approach when W7’s surroundings are out-of-spec, so to say.
You are absolutely right. I made a test on my own computer. Worse, gparted will not CONVERT file systems and keep existing data as Partition Magic (which I recommend against using for other reasons) could do. Since I have found gparted otherwise to be equal to or superseed Partition Magic, I didn’t mentally note the full meaning of the word FORMAT when selecting file system in gparted until you wrote the word - and that made me jump in my chair. gparted cannot convert file systems - only reformat. That is data destructive - which means you need to back up before reformatting to FAT32 AND gparted will set a new UUID! I have confirmed the UUID part now. gparted allows you to set a new UUID by itself, but only a random one - it will not allow you to edit the value to your own taste.
I also did inspect the partitions made by gparted during my test by using gdisk, and some of the status-es given confuses me. I need to read up on the very tiny details of MBR/GPT/FAT/UUID and how the things are held together as a whole, to digest that. If gdisk is right, this seems to involve more than just the layouts of the MBR table/protective MBR table and GPT table. It appears to involve how that works within each partition as well as the full, physical storage medium. I didn’t think the two latter mattered, but gdisk seem to indicate otherwise. I’ll be back with more info on that.
We learn by experience, which includes trying stuff and making mistakes.
I’m still learning, which implies that I still make mistakes.
To slightly change topics, the really big problem that I see for GPT partitioned disks, is the sector size.
I have a 1T disk. According to “gdisk” it has a physical sector size of 4K and a logical sector size of 512 bytes. The GPT partition table is based on that 512 byte logical sector size.
If I take that same disk out of my computer, and mount in a USB connected hard drive enclosure, then it shows as having a logical sector size of 4K. This means that the partition table is incompatible between those two ways of accessing the disk. This was a terrible design decision. The partition table structure should have been based on the more reliable physical sector size instead of the unreliable logical sector size. I see problems down the road because of this.
If you do it with two ESPs on the same hard disk, you will damage Windows bootloader beyond repair. You should delete (change type of) partition created by openSUSE to something else so it is not treated as ESP by Windows. Then you could use Windows recovery.
Are you sure it is GPT that is doing that to you? Isn’t Advanced Format (or, rather, Advanced Format 512e, to be precise) the real culprit (Advanced Format - Wikipedia, the free encyclopedia) - and gdisk/GPT just reporting what the disk says? If connecting through USB does hide the effect of Advanced Format, I would think Advanced Format would hamper more than GPT partitioning alone?
It may be the advanced format. Still, the disk looks different via USB than when installed as a hard drive.
I originally partitioned as a USB drive, using “gdisk”. Fortunately, the only partition created was the protective partition used to simulate an MBR. When looked at, with the disk properly mounted as a hard drive, the protective partition covers only 1/8 of the drive capacity. When orginally looked at via a USB enclosure, it was the whole drive.
Yes, that disk has Seagate’s variant of Advanced Format; they (did?) call it SmartAlign. BTW I found they announced a firmware upgrade for it: Barracuda (1TB/disk platform) Firmware Update. There’s no date on the page though, so I don’t know how old it is. One of the documentation pages linked from that page, displays a ReadMe-file dated March 2008 (this date is why I said “(did?)” above, SmartAlign may already be outdated, replaced or improved upon. I haven’t checked that now) - but again, I don’t know if that is just an example or a part of the true file being displayed.
But what you describe is still puzzling. I’ll continue to read up on partitioning and have that in mind too. It could be that the various disk-manufacturers ways of implementing Advanced Format may be a factor to take into account (they all seem to have different names for it, but that may just be marketing, though). Maybe some answers can be found. I’ll be back in another thread when I have found anything of interest.