My ThinkPad had been configured to have the boot loader on sda3. In updating to 15.3, I accidentally put it on the master boot record on sda. This has created a problem with updates to Windows 10, which I also have on that computer. The major updates will choke if the computer doesn't boot from the Windows partition, so I'd use fdisk to change booting from sda3 to sda1. It would then boot directly into Windows, allowing he update to continue. After my mistake in updating, I can no longer do that. I have used the Yast Boot Loader to move the boot loader to sda3, but the problem continues, no matter which partition I choose to boot from. Any idea how to fix this? tnx jk
My ThinkPad had been configured to have the boot loader on sda3. In updating to 15.3, I accidentally put it on the master boot record on sda. This has created a problem with updates to Windows 10, which I also have on that computer. The major updates will choke if the computer doesn't boot from the Windows partition, so I'd use fdisk to change booting from sda3 to sda1. It would then boot directly into Windows, allowing he update to continue. After my mistake in updating, I can no longer do that. I have used the Yast Boot Loader to move
On 13/06/2021 21.57, James Knott wrote: the
boot loader to sda3, but the problem continues, no matter which partition I choose to boot from.
Any idea how to fix this?
with 15.3, I can not risk to offer a solution, too early to know. Run "bootinfoscript" and post the RESULTS.txt file on susepaste. download from https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 13.06.2021 22:57, James Knott wrote:
My ThinkPad had been configured to have the boot loader on sda3. In updating to 15.3, I accidentally put it on the master boot record on sda. This has created a problem with updates to Windows 10, which I also have on that computer. The major updates will choke if the computer doesn't boot from the Windows partition, so I'd use fdisk to change booting from sda3 to sda1. It would then boot directly into Windows, allowing he update to continue. After my mistake in updating, I can no longer do that. I have used the Yast Boot Loader to move the boot loader to sda3, but the problem continues, no matter which partition I choose to boot from.
Writing bootloader to another partition is not going to change what has already been written to MBR.
Any idea how to fix this?
Check "Write generic Boot Code to MBR"?
On 2021-06-14 1:14 p.m., Andrei Borzenkov wrote:
Writing bootloader to another partition is not going to change what has already been written to MBR.
Any idea how to fix this?
Check "Write generic Boot Code to MBR"?
I had considered that. I'll see what Carlos has to say about my RESULTS.txt first. tnx
James Knott composed on 2021-06-13 15:57 (UTC-0400):
My ThinkPad had been configured to have the boot loader on sda3. In updating to 15.3, I accidentally put it on the master boot record on sda. This has created a problem with updates to Windows 10, which I also have on that computer. The major updates will choke if the computer doesn't boot from the Windows partition, so I'd use fdisk to change booting from sda3 to sda1. It would then boot directly into Windows, allowing he update to continue. After my mistake in updating, I can no longer do that. I have used the Yast Boot Loader to move the boot loader to sda3, but the problem continues, no matter which partition I choose to boot from.
Any idea how to fix this?
Reinstall DOS/OS2/Windows-compatible MBR code on sda. Check in your /boot/ filesystem. YaST may have saved a copy of the previous MBR code there that can be restored. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2021-06-14 2:35 p.m., James Knott wrote:
On 2021-06-14 1:14 p.m., Felix Miata wrote:
Reinstall DOS/OS2/Windows-compatible MBR code on sda. Check in your/boot/ filesystem. YaST may have saved a copy of the previous MBR code there that can be restored.
I have BOOTSECT.BAK in sda1, dated Feb 10. I suspect this may be it.
tnx
Also, gparted shows sda1 as NTFS SYSTEM_DRV and has the boot flag set.
James Knott composed on 2021-06-14 14:35 (UTC-0400):
Felix Miata wrote:
Reinstall DOS/OS2/Windows-compatible MBR code on sda. Check in your/boot/ filesystem. YaST may have saved a copy of the previous MBR code there that can be restored.
I have BOOTSECT.BAK in sda1, dated Feb 10. I suspect this may be it.
That's her. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2021-06-14 3:29 p.m., Felix Miata wrote:
I have BOOTSECT.BAK in sda1, dated Feb 10. I suspect this may be it.
That's her.
Now to figure out how to put it back. It's been about 25 years since I did anything with boot sectors and that was only in a class room. I suppose dd could be used. The file is 8K.
James Knott composed on 2021-06-14 15:39 (UTC-0400):
Felix Miata wrote:
I have BOOTSECT.BAK in sda1, dated Feb 10. I suspect this may be it.
That's her.
Now to figure out how to put it back. It's been about 25 years since I did anything with boot sectors and that was only in a class room. I suppose dd could be used. The file is 8K.
8k is 16 sectors. What I expected would be only 446 bytes (or less). Were it that, this would fix it: dd if=/boot/BOOTSECT.BAK of=/dev/sda It still might, but there's copious risk. /usr/lib/boot/master-boot-code contains the code required, but it's 512 bytes, with no man or info page to explain how to install it. dd'ing it I expect would destroy the partition table. Better look through official docs to find out how to use it!!! I looked in yast partitioner and recognized nothing related. # apropos mbr Bootloader::MBRTools (3pm) - set of low-level functions for mbr manipulation is as much as I could find quickly about openSUSE tools possibly suited for the purpose. Disk partitioning tools should all be able to write generic code that Windows requires. That includes using Windows to repair boot. You'd follow that with simply moving the boot flag back from sda1 to sda3. OK, in YaST Bootloader there is an option to write generic code to MBR. Check that, and check boot from partition, and check set active flag in partition table for boot partition, then uncheck other boxes there before saving should do it. I used to do this at installation when necessary, until support for Grub 0.97 was dropped. I use DFSee for everything disk/partition related. http://www.dfsee.com/ . -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
James Knott composed on 2021-06-14 19:13 (UTC-0400):
Felix Miata wrote:
dd if=/boot/BOOTSECT.BAK of=/dev/sda
It still might, but there's copious risk.
I can give that a try. I have already backed up the entire partition.
It's the partition table at risk, not the first partition. Overwriting the last 66 bytes of the first sector destroys the entire table for an MBR disk. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2021-06-14 8:44 p.m., Felix Miata wrote:
dd if=/boot/BOOTSECT.BAK of=/dev/sda It still might, but there's copious risk. I can give that a try. I have already backed up the entire partition.
It's the partition table at risk, not the first partition. Overwriting the last 66 bytes of the first sector destroys the entire table for an MBR disk.
There is also this method using a W10 ISO. https://www.youtube.com/watch?v=eowkfBCDxvI
On 14/06/2021 23.17, Felix Miata wrote:
James Knott composed on 2021-06-14 15:39 (UTC-0400):
Felix Miata wrote:
I have BOOTSECT.BAK in sda1, dated Feb 10. I suspect this may be it.
That's her.
Now to figure out how to put it back. It's been about 25 years since I did anything with boot sectors and that was only in a class room. I suppose dd could be used. The file is 8K.
8k is 16 sectors. What I expected would be only 446 bytes (or less). Were it that, this would fix it:
dd if=/boot/BOOTSECT.BAK of=/dev/sda
Warning! That may overwrite the partition table. It is: dd if=backup of=/dev/sda bs=446 count=1 There is a trick for an MBR to be used with Windows. From my archive: https://nwrickert2.wordpress.com/2015/06/15/generic-boot-code/ Seek this post in the mail list archive: Date: Thu, 21 Apr 2016 08:42:55 -0500 From: Neil Rickert <nrickert@ameritech.net> Reply-To: OS-en <opensuse@opensuse.org> To: opensuse@opensuse.org Subject: Re: [opensuse] A small nuisance I'm seeing with double boot of Windows 10 and openSUSE 13.1. Message-ID: <5718D8DF.1050702@ameritech.net> <https://lists.opensuse.org/archives/list/users@lists.opensuse.org/message/544UKVYIGZDYKPODJ65FUTCVX6SZHIO7/> This method works perfectly. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Carlos E. R. composed on 2021-06-15 09:12 (UTC+0200):
Felix Miata wrote:
James Knott composed on 2021-06-14 15:39 (UTC-0400):
Felix Miata wrote:
I have BOOTSECT.BAK in sda1, dated Feb 10. I suspect this may be it.
That's her.
Now to figure out how to put it back. It's been about 25 years since I did anything with boot sectors and that was only in a class room. I suppose dd could be used. The file is 8K.
8k is 16 sectors. What I expected would be only 446 bytes (or less). Were it that, this would fix it:
dd if=/boot/BOOTSECT.BAK of=/dev/sda
Warning! That may overwrite the partition table.
That's the reason for "Were it that".
It is:
dd if=backup of=/dev/sda bs=446 count=1
Limiting to bs=446 is what I forgot about. :p
There is a trick for an MBR to be used with Windows. From my archive:
https://nwrickert2.wordpress.com/2015/06/15/generic-boot-code/
Seek this post in the mail list archive:
Date: Thu, 21 Apr 2016 08:42:55 -0500 From: Neil Rickert <nrickert@ameritech.net> Reply-To: OS-en <opensuse@opensuse.org> To: opensuse@opensuse.org Subject: Re: [opensuse] A small nuisance I'm seeing with double boot of Windows 10 and openSUSE 13.1. Message-ID: <5718D8DF.1050702@ameritech.net>
This method works perfectly.
As I always have generic MBR code anyway, I just move the flag where Windows needs it when it absolutely must have it, then move it back afterwards. I don't boot Windows anywhere near once a month. Usually it's just to catch up on a zillion updates when I have nothing better to do. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 15/06/2021 09.32, Felix Miata wrote:
Carlos E. R. composed on 2021-06-15 09:12 (UTC+0200):
Felix Miata wrote:
There is a trick for an MBR to be used with Windows. From my archive:
https://nwrickert2.wordpress.com/2015/06/15/generic-boot-code/
Seek this post in the mail list archive:
Date: Thu, 21 Apr 2016 08:42:55 -0500 From: Neil Rickert <nrickert@ameritech.net> Reply-To: OS-en <opensuse@opensuse.org> To: opensuse@opensuse.org Subject: Re: [opensuse] A small nuisance I'm seeing with double boot of Windows 10 and openSUSE 13.1. Message-ID: <5718D8DF.1050702@ameritech.net>
This method works perfectly.
As I always have generic MBR code anyway, I just move the flag where Windows needs it when it absolutely must have it, then move it back afterwards. I don't boot Windows anywhere near once a month. Usually it's just to catch up on a zillion updates when I have nothing better to do.
With the above trick, Windows updates work perfectly, and Linux updates also work perfectly. Nothing to ever change or move, for years and years. Of course, you can not allow yast to overwrite the mbr with generic code or anything at all, but in case it happens I have a text file with exact instructions for myself on the /boot directory. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-06-15 9:15 a.m., James Knott wrote:
On 2021-06-15 3:12 a.m., Carlos E. R. wrote:
Warning! That may overwrite the partition table. It is:
dd if=backup of=/dev/sda bs=446 count=1
I was wondering about that. I'll back up the MBR first.
tnx
After doing that, I was left with a bad MBR. I then put the original MBR back and was back in the state where I couldn't boot right into Windows. I then created a new MBR with Yast Boot Loader and that worked, so everything is back to normal. tnx jk
On 2021-06-15 3:12 a.m., Carlos E. R. wrote:
On 14/06/2021 23.17, Felix Miata wrote:
James Knott composed on 2021-06-14 15:39 (UTC-0400):
Felix Miata wrote:
I have BOOTSECT.BAK in sda1, dated Feb 10. I suspect this may be it.
That's her.
Now to figure out how to put it back. It's been about 25 years since I did anything with boot sectors and that was only in a class room. I suppose dd could be used. The file is 8K.
8k is 16 sectors. What I expected would be only 446 bytes (or less). Were it that, this would fix it:
dd if=/boot/BOOTSECT.BAK of=/dev/sda
Warning! That may overwrite the partition table. It is:
dd if=backup of=/dev/sda bs=446 count=1
There is a trick for an MBR to be used with Windows. From my archive:
https://nwrickert2.wordpress.com/2015/06/15/generic-boot-code/
Seek this post in the mail list archive:
Date: Thu, 21 Apr 2016 08:42:55 -0500 From: Neil Rickert <nrickert@ameritech.net> Reply-To: OS-en <opensuse@opensuse.org> To: opensuse@opensuse.org Subject: Re: [opensuse] A small nuisance I'm seeing with double boot of Windows 10 and openSUSE 13.1. Message-ID: <5718D8DF.1050702@ameritech.net>
This method works perfectly.
That link appears to be broken. I get a server error.
On 15/06/2021 19.13, James Knott wrote:
On 2021-06-15 3:12 a.m., Carlos E. R. wrote:
On 14/06/2021 23.17, Felix Miata wrote:
James Knott composed on 2021-06-14 15:39 (UTC-0400):
There is a trick for an MBR to be used with Windows. From my archive:
https://nwrickert2.wordpress.com/2015/06/15/generic-boot-code/
Seek this post in the mail list archive:
Date: Thu, 21 Apr 2016 08:42:55 -0500 From: Neil Rickert <nrickert@ameritech.net> Reply-To: OS-en <opensuse@opensuse.org> To: opensuse@opensuse.org Subject: Re: [opensuse] A small nuisance I'm seeing with double boot of Windows 10 and openSUSE 13.1. Message-ID: <5718D8DF.1050702@ameritech.net>
This method works perfectly.
That link appears to be broken. I get a server error.
Both links work here. Maybe you tried the mail list in the hours that it was indeed down. Please try again. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
participants (4)
-
Andrei Borzenkov -
Carlos E. R. -
Felix Miata -
James Knott