I have a computer with Windows 10 and I was also running OpenSuse 41.2 (I can’t edit the title of the thread).
I decided to upgrade OpenSuse to 42.3 and I created a bootable flash disk.
I booted from flash disk by selecting UEFI BOOT. The upgrade went smoothly, but after that, the computer could not boot in OpenSuse 42.3.
I was still able to select the previous version of OpenSuse and Windows and they were both working fine.
I attempted to reconfigure grub from YAST and it went from bad to worse. At one stage it was showing errors “can’t find linuxefi” and “can’t find initrdefi”.
When I try to check the integrity of the medium, it shows a red message “This is not a openSuse Leap 42.3 medium”.
At the moment, when I start the computer, it goes to Welcome to Grub! followed by “error: file /normal.mod not found” and the grub rescue prompt.
I don’t care too much about the OpenSuse installation, I only care not to destroy the Windows installation.
If I try to install OpenSuse 42.3, the suggested partitioning it offers to delete the Windows partition. Really??? The edit proposals don’t seem to offer a way to spare Windows. It’s a confusing system…
The hard disk has the following partitions:
/dev/sda 931 GB ST1000DX001 - 1NS1
/dev/sda1 156 MB EFI boot FAT
/dev/sda2 2GB Linux Swap Swap
/dev/sda3 40 GB Linux Native BtrFS
/dev/sda4 889 GB Linux Native XFS
If I go through the instructions for grub rescue, I performed
set boot=(hd0,msdos6)
set prefix=(hd0,msdos6)/boot/grub2
insmod normal
normal
it raises error “/normal.mod” not found.
If I try set prefix=(hd0,msdos6)/boot/grub and the rest, it raises error “boot/grub/i386-pc/normal.mod not found”
It is not clear to me what you actually did to “upgrade” the 41.2 OS: did you choose “Upgrade System” and selected the proper 41.2 system to upgrade after booting the flash disk?
How can you assure that “the upgrade went smoothly”? If afterwards you were able to select and boot the previous 41.2 system, the upgrade was actually NOT smooth at all.
Please be aware that an upgrade from 41.2 to 42.3 is not guaranteed to work, even if it might work with some configurations. Only an upgrade from a fully updated 4**2.2 **to 42.3 is guaranteed to work (and indeed it worked here).
At this point I would suggest a fresh installation of 42.3 on top of the existing openSuse system; you should be able to do that by selecting the “Expert partitioner” when asked to review the default partitioning (which with an already full disk would indeed suggest to wipe the Win* system).
Feel free to ask here if you need further advice.
GRUB itself does not use “boot” variable. Where have you got instructions to set it?
set prefix=(hd0,msdos6)/boot/grub2
Your listing above shows only 4 partitions. Partition msdos6 simply does not exist. Why you think you should use this partition?
If I try set prefix=(hd0,msdos6)/boot/grub and the rest, it raises error “boot/grub/i386-pc/normal.mod not found”
This implies that you have booted in legacy BIOS mode. May be this is the reason? EFI bootloader was updated but you now boot using some leftover from legacy BIOS bootloader? Check your BIOS settings, make sure you do use EFI.
Yes, I booted from the flash disk and I selected to upgrade the Operating System. When I said the upgrade went smoothly I meant that I selected the default options recommended by installation and all the packages were installed, without any errors. I use a wifi USB network and I could not get that to work (it does not find any networks). It happened in the past as well. I usually take care of network after the system installs.
From the fact that I was not able to boot after upgrade, indeed the update was not smooth. But it appeared so during the installation.
I would not mind losing the previous OpenSuse installation. The more serious matter is that it altered grub in a way that did not allow the system to boot correctly. It is my fault for not understanding the difference between legacy booting and efi booting. My computer was configured in bios with legacy settings, and when I booted the flash disk it was using EFI settings.
The good part was that in the beginning I was still able to boot in Windows and previous version of OpenSuse, but I did not have enough knowledge to reconfigure grub2. What is worse is that I thought grub is something decently simple, that can be fixed quite easily. It may be the case, after one gets a PhD in grub theory
The expert partitioner is terribly confusing. In the suggested partitioning, it offers to delete the Window partition at /dev/sda2 (500 GB). When I go in Expert Partitioner, it shows partition /dev/sda2 as Linux swap with a size of 2 GB. And the Windows partition is not even listed. The more I dig into Expert partitioner, the more confusing is getting. At least the name for it is properly chosen - to be used by experts…
I wish there were a simple alternative such as “do whatever you wish to any linux partitions, but spare the Windows partition”…
I am sorry, it was a typo in my post (should have been root, not boot). I used the instructions from here: https://askubuntu.com/questions/119597/grub-rescue-error-unknown-filesystem. It happened that on my system (hd0, msdos6) is the contains the linux directories.
I don’t know what’s the difference between /dev/sda and (hd0, msdos6). All I know is that I’ve seen both /dev/sda, /dev/sda1, …, /dev/sda4 but also (hd0, msdos6) and (hd0, msdos7) and when I run ls (hd0, msdos6) I could see the Linux directories.
My computer was set in legacy BIOS mode. When after upgrade the computer failed to boot and I went to reconfigure grub in YAST, I tried all kind of things and eventually I selected EFI. I can’t remember much of what it was in there, except that it went from bad to worse. I did not touch the BIOS settings until today,when I changed from legacy to EFI - but it didn’t help, the grub is compromised.
Because of this, probably my best best chance now (suitable to my knowledge) is to reinstall Windows and then do a clean installation of Linux on it. Or install Linux on a separate external hard drive, where it can’t cause damage to Windows…
ls
ls (hd0,msdos6)/
set root=(hd0,msdos6)
ls /
set prefix=(hd0,msdos6)/boot/grub
insmod /boot/grub/linux.mod
normal
Yes, that would be best. But, come back here for more instructions or help to get you through the install process without disaster.
Or install Linux on a separate external hard drive, where it can’t cause damage to Windows…
It won’t cause damage to Windows if you make sure, in the expert partitioner, to not let the install touch your Windows partition(s). But, you need to get more specific instructions when you proceed.
So, start out by re-installing your Windows, then come back here for more instructions before installing openSUSE.
Can someone confirm that if we create a bootable flash disk, the integrity test fails?
I downloaded the ISO file and I run the SHA256 checksum and it matches the expected value (195baca6c5f3b7f3ad4d7984a7f7bd5c4a37be2eb67e58b65d07ac3a2b599e83).
After using Rufus to create the bootable flash, when I test it, it shows the message: “This is not a OpenSuse Leap 42.3 medium”
I recreated the flash disk two times and both times it shows the same warning.
I reinstalled an older version of OpenSuse (13.1) because that was the only DVD I had around. I could not find a more recent one. That version did not offer to wipe out my Windows 10 partition and after installation, I was able to view the files from Windows partition. I still could not boot in Windows. I downloaded the installation kit OpenSuse 42.1 and I burnt a DVD. I installed OpenSuse v42.1 (which also spared my Windows) and I did all the system updates. Now Grub2 is working, I am allowed to choose between Linux and Windows. The problem I have is that although I can see all the folders from Windows, when I try to start Windows, it fails with the error “inaccessible boot device”.
Grub offers me the following boot choices:
OpenSUSE Leap 42.1
Advanced options for openSUSE Leap 42.1
Windows 10 (loader) (on /dev/sda1)
Windows 10 (loader) (on /dev/sda2)
Start bootloader from a read-only snapshot.
If I start Windows from /dev/sda1, it indicated “Preparing Automatic repair” and I am offered the options to
Troubleshoot (reset your PC or see advanced options).
Turn Off your PC
If I start Windows from /dev/sda2, it also fails the booting.
I selected to boot from /dev/sda1 and I chose a System Restore. It found a restore point from a few days ago. After system restoration, the computer shows “BOOTMGR is missing. Press Ctrl+Alt+Del to restart”. Nothing works anymore, now I have no Linux and no Windows… It’s like trying to fit in the same cage a tiger and a lion, they try to kill each other.
It looks like every step ahead is followed by three steps back…
Don’t rush to the Win* installer, if you are still able to boot your existing Win* (maybe by the leftover Grub from 41.2…) the Win* install was left untouched by the failed upgrade process (as expected by any “smooth” upgrade).
Likely, you only need to overwrite the 41.2 openSUSE install or redo the upgrade the proper way.
But, as arvidjaar already pointed out…
so please make sure to use for the installer the same boot process (EFI or legacy) that the existing Win uses*: that will choose which type of GRUB (legacy or GRUB for EFI) the installer is going to install or upgrade, since apparently at the moment you have both on your disk.
It would also help to see the output of fdisk and/or gdisk (to be run as superuser) to see if you are mixing MBR and GPT partition tables (might explain why you see no Win* partition with your current GRUB and the expert partitioner looks confused):
OOOPS… too late, I see you already did three steps ahead.
It would still help to see the output of fdisk and/or gdisk since you should not see Win* on sda1 AND sda2, then make sure any openSUSE upgrade/install is done with the same boot process as the current (likely still undamaged) Win*.
And yes, it is like putting a lion and a tiger, but while Win* tries to kill any Linux on disk, openSUSE doesn’t try to kill any other operating system unless instructed to do so.
openSUSE 13.1 only booted in legacy, non EFI mode if I remember correctly ant that would explain why it didn’t offer to wipe the (apparently legacy MBR) Win*
You should be able to do the same with Leap 42.3 once the proper boot options are set up.
I am confused about the boot processes - legacy or EFI. When I purchased the computer (refurbished Dell Optiplex 9010), it had Windows 7 and it was working fine. I did not touch the BIOS - whatever it had, that’s what I left.
Later I upgraded to Windows 10 and I installed OpenSuse and it was still fine. I am not aware if it was EFI or legacy, I suspect it was legacy. I haven’t visited the BIOS of this computer in a few years. Now it is set in Legacy mode.
If I switch to UEFI, all I get is a lot of nonsense ****, so I would have not chosen it. In UEFI mode, all I see is the CD/DVD and no hard disk or other devices, plus it asks me to add boot options without providing any suggestions.
I really hate UEFI.
After I run the System Restore from Windows (described in my previous post), I attempted to reinstall OpenSuse 42.1. After completion of the installation, I still get BOOTMGR is missing. Now the whole computer is messed up.
PS - I visited the BIOS again and I found out the RAID was turned on. I never used RAID, but I think at one stage I attempted to load the BIOS defaults and this is the default option in BIOS. I was under impression that I did not load the defaults, because of a warning that my computer may not boot. It looks like I loaded the defaults after all. After disabling Raid, now OpenSUSE 42.1 is back live and Windows partition is still accessible from Linux. But still no luck booting in Windows.
I am back - Linux is working again after disabling Raid and now I am posting from this very computer. I will run the commands now:
linux-myhb:~ # fdisk -l /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: dos
Disk identifier: 0x7e3e6371
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 64 1953520064 1953520001 931.5G 7 HPFS/NTFS/exFAT
linux-myhb:~ # gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.8
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
Disk /dev/sda: 1953525168 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): AB7982D8-9973-4FA7-B4B6-0923B13BA6D4
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 64-sector boundaries
Total free space is 5100 sectors (2.5 MiB)
Number Start (sector) End (sector) Size Code Name
1 64 1953520064 931.5 GiB 0700 Microsoft basic data
MMMhhh… so you have TWO disks on this box and maybe which is /sda and which is /sdb is randomly chosen depending on the BIOS scan of devices?
I cannot guess what is on this /sda, apparently a data swap portable disk? If possible, I would disconnect it while we sort out this situation, just to avoid unnecessary confusion…
Please note the boot flag, you have another set at /dev/sdb4 and this might confuse the boot process.
Model: ATA ST1000DX001-1NS1 (scsi)
Disk /dev/sdb: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:
Apparently this is the disk holding the real Win* (at /dev/sdb2) and openSUSE (at /dev/sdb6 root, at /dev/sdb7 apparently a separate /home).
Additional boot and diagnostic Win* partitions at /dev/sdb1 and /dev/sdb3 respectively.
Please note the boot flag at /dev/sdb4, which is a legacy (dos partition table written to MBR) extended partition. Likely the GRUB (legacy) code is written here, but this depends on the options chosen during openSUSE install or upgrade.
Anyway, this is definitely a legacy, dos partition table, MBR boot setup and the BIOS settings should disable any EFI/UEFI and RAID as well as you already pointed out.
With a setup like that, any openSUSE installer should boot in legacy mode: to confirm that, you should see a row of option “buttons” on the bottom of the boot menu; if not you are using the installer in EFI mode and that is likely to mess up things.
As said, disconnecting the “portable” disk during install/upgrade might help, if possible: maybe some sort of Win* BOOTMGR code is also written to that “portable” disk and this is confusing Win* as well?
PS: please enclose command output in “CODE” tags (the # button in the web interface) to avoid losing the original formatting.
****, I got tired. When I restored Windows, I thought the restoration will ask for my latest backup so I connected the external drive and after that, I forgot to disconnect it. In fact, the restoration used a previous resoration point from the computer hard drive. I am not sure how was Windows able to read the restore point during the restoration, but unable to boot. I removed it now. Now, I am still able to start OpenSuse, but when I go into Boot Loader, it reports “internal error. Please report a bug with logs” during the Load boot loader settings.
OK, that might happen with a compromised bootloader. Let’s try to restore it from the installation disk; I would try the 42.3 installer at this point, but the 42.1 should do as well.
Boot the installer disk, check that it is in “legacy” mode (option keys appearing at the bottom of the screen).
Choose “Upgrade”, go ahead to selecting the existing openSUSE install.
When at the “Installation Settings” screen click on “Booting”
Check in “Boot Code Options”:
Boot Loader: GRUB2 (not GRUB2 for EFI)
Tick “Boot from Extended Partition” (that is /dev/sda4 now that you have only one disk connected)
Tick “Set active flag in Partition Table for Boot Partition”
Tick “Write generic Boot Code to MBR”
Click the “Edit Disk Boot Order”: it should show only /dev/sda now.
Check in “Boot Loader Options” that “Probe Foreign OS” is ticked (to setup the bootloader chain for Windows"
Click “OK” to return to Installation Settings.
Click “Update” to update or repair the installed system; if you used the 42.3 installer on a 42.1 system a full update will follow; if you used the 42.1 installer I expect only the bootloader (and possibly a handful of config files) to be updated.
Please be aware that if you use the 42.1 installer on a 42.1 system you receive a warning that “The system to upgrade is not supported” (strictly speaking you are expected to upgrade from a previous version): ignore that warning.
After reboot, Win* should be recognized and it should be possible to start to boot it; whether it goes through to actually booting Win* I can’t tell at this stage.
Yes, I saw something similar about “disappeared device”, as might be the case with the now disconnected portable drive https://bugzilla.opensuse.org/show_bug.cgi?id=949796
But TBH mine was just a wild guess and what we witness here might be completely unrelated.
OK, I will upgrade to OpenSuse Leap 42.3. I first used the DVD and it reported it is corrupted, so I am now trying with the flash drive (which appears as /dev/sda).
I booted in legacy mode and selected Upgrade. Now, the Linux native OpenSuse 42.1 appears as /dev/sdb6 and there are two HPFS/NTFS partitions (/dev/sdb1 and /dev/sdb2). I will proceed with updating the Linux native (btrfs) at /dev/sdb6
I have no option “Boot from Extended Partition”, perhaps you refer to “Custom Boot Partition”? The three options are “Boot from Root Partition”, “Boot from Master Boot Record” and “Custom Boot Partition”.
In the Edit Disk Boot Order, it shows /dev/sdb and /dev/sda. Maybe it is because of the flash disk where I am installing from? Should I delete /dev/sda and leave just /dev/sdb (which is the actual hard drive)?
Anyway, I will do the following: Tick Custom Boot Partition - /dev/sdb4 (even if I could not see a /dev/sdb4!) , Disk Order Settings - I will only leave /dev/sdb. I ticked Set active Flag and Write Generic Boot Code to MBR.
Strangely enough, after I switched through the tabs, the “Boot from Extended Partition” option appeared in the menu, so now I can follow your instructions (except that I forgot to check the tick Probe for Foreign OS) . We’ll see what happens.
