1

I made a live Linux system on a USB pen drive using Rufus (MBR partition scheme) and everything was working fine except for a large number of warnings and critical error messages I got from dmesg. There where some security warnings regarding a CPU vulnerability and many ACPI-related errors which appear to be related to some toxic Microsoft hardware driver politics. But among them, there was also a message

There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)
<...long list of entries...>
1) Copy original to backup
2) Copy backup to original
3) No action

with roughly 30-40 lines of entries. If I remember correctly, Linux systems create a working boot sector at the beginning of a disk as well as a backup copy at the end of the disk. After reading the few discussions I could find on this somewhat elusive error, I decided to choose the option of replacing the original with its backup.

Unfortunately, this appears to have been a grave mistake as I'm now getting a

Invalid system disk. Replace disk and strike any key

and the system won't boot. Question:

  • What exactly causes such a high number of offsets within the boot sector, especially on a virtually plain-vanilla installation, and what would have been the correct action?
  • How can it possibly be, if not for a serious bug, that restoring a proper, system-generated backup - following a system message asserting This is mostly harmless - bricks the system?
  • Most importantly: How to solve this issue so the system will boot again?

Note: I did not get any error referring to a "dirty bit" that appears to get set when a drive is not properly unmounted as discussed here. Also, the USB drive itself is virtually new.

Note 2: Boot sector corruptions are NOT harmless, despite what some here are claiming. This "option" for triggering a zero-warning, one-click irrecoverable hard brick during boot is a catastrophic design flaw!

srhslvmn
  • 111
  • 2
    BIOS/MBR has no backups. NTFS has as backup boot sector. And perhaps if using syslinux you may have boot unfo in the partition boot sector. Old versions of Ubuntu used syslinux for BIOS and grub for UEFI. Newer versions use grub for both. With gpt you have partition table, partition & backup partition table, but those are separate entries, not boot sectors. If just USB drive and not your install, I would recreate flash drive, but first verify ISO downloaded correctly. What version of Ubuntu? – oldfred Jun 29 '22 at 20:44
  • That's strange - then where is this "backup" located? – srhslvmn Jun 29 '22 at 20:59
  • It's Ubuntu 22.04 LTS – srhslvmn Jun 29 '22 at 20:59
  • 1
    You probably should just create new flash drive. LInk is more for Windows NTFS issues. If you have already sync'd the BS & backup BS, you can use testdisk to build a new BS. But it may be the old XP type and you need the newer version if any current version of Windows. You then have to run Windows chkdsk to update it. If FAT32 you can run dosfsck from Linux. https://askubuntu.com/questions/655290/grub-is-not-letting-me-switch-to-windows-8-dual-boot-process-ubuntu-15-04/655486#655486 – oldfred Jun 30 '22 at 03:40
  • @oldfred Are you aware that the question is not referring to a Windows issue? :) – srhslvmn Jun 30 '22 at 18:58
  • dmesg is a Linux command/program – srhslvmn Jun 30 '22 at 18:58
  • 1
    The boot sector error message reported was output from dosfsck. I recently had a microsd which stopped booting successfully, and fixed it with dosfsck -- which reported only one bit different in the boot/backup, and many other file name errors. Probably the card is pretty worn out, but after dosfsck repairs, it did boot and run again (on a Chumby). – ubfan1 Jul 01 '22 at 19:24
  • You mean that I should run dosfsck over the USB drive from another system? – srhslvmn Jul 01 '22 at 20:05
  • Also...could it be that this whole problem was caused by selecting the ISO mode in Rufus instead of the DD mode? The former creates a FAT32 file system while the latter just writes bit by bit – srhslvmn Jul 01 '22 at 20:16
  • No, the dosfsck was already run, and changes made which I don't know how you could undo, so as oldfred said, just create a new flash drive. Maybe format it first and see if that even works if the usb is dying. – ubfan1 Jul 01 '22 at 21:16
  • The USB stick is brand new! – srhslvmn Jul 01 '22 at 23:43

1 Answers1

3
  • How can it possibly be, if not for a serious bug, that restoring a proper, system-generated backup - following a system message asserting This is mostly harmless - bricks the system?

Because I'm afraid that you are misinterpreting what the message was telling you.

You got a message telling you that something and its backup differed, which means that you have three possibilities (that you cannot guess without understanding the binary data and its differences):

  • Either the main boot sector is fine and the backup is corrupted
  • Or the main boot sector is corrupted and the backup is fine
  • Or both the main boot sector and the backup boot sector are corrupted (but if you are able to boot even after you get the message, then the main boot sector is probably okay).

All the message is telling you is that the main and the backup no longer match, and the only conclusion you can draw for this is that one of them, or possibly both, is corrupted. But, and this is the most important point, you can not tell which one unless you know how to analyse the differences.

I believe your problem stems from assuming that, because a backup is called a "backup", it should always contain the correct data. That is not a proper assumption to make. And as a matter of fact, the problems you encountered after you took a chance to replace the main bootloader with the backup bootloader seem to indicate that it was most likely the backup version of the bootloader that got corrupted, whereas the main bootloader was fine.

So, what you were prompted with is 100% correct:

  1. If you could boot the system (before you replaced the main bootloader with the backup), then it means that the problem is mostly harmless, because then it's only the unused backup bootloader that appears to be corrupted
  2. In case you want to attempt to fix the corruption, and because it's not possible to formally determine which of the main or the backup is correct, you are being asked which of main or backup you want to declare as the "proper" bootloader. Unfortunately, this is not something you should choose at random, and that is why you get the list of differences, that you are supposed to study first before you decide which one looks like the "right" version.

Thus, if you can't analyse the differences, and especially if the main bootloader appears to work fine (outside of the message you get), you most certainly should not overwrite it with the backup, because the most probable conclusion is that it is the main bootloader that is fine and that it is the backup bootloader that is corrupted.

Unfortunately, you did choose to replace your (most likely) working main bootloader with your (most likely) corrupted backup bootloader, thereby bricking your system. But unlike what you are asserting, the bricking of the system does not come from a bug of the software, but from your erroneous assertion that a backup must always be good, which is not something you can assert.

Akeo
  • 1,455
  • Cool, aren't you the Rufus creator? Anyway...I got your point, and it's good to put emphasis on the fact that the error message might be pointing to a corrupted backup boot sector. HOWEVER. You need to see this in context: This is not what this error message is suggesting to the average user. At the very least, it's missing a warning. Linux distros are starting to brick waaay to easy (that includes Android). Accessibility ("With great power comes...") + stability isn't a zero sum. If that error message is everything between the user and a hard brick - the blame is not on the user. – srhslvmn Jul 03 '22 at 16:24
  • Secondly, I ran a SMART check and the USB stick is fine (also, it's brand new). Furthermore, the system was just freshly installed. And it's based on Debian, which is marketed as a comparatively stable system. Which brings us to the more interesting question: Isn't the backup boot sector usually write-protected?? What on earth would cause a corruption of a protected disk sector with 30-40 diffs to the working version (which we're sort of of assuming here as the healthy version)?? – srhslvmn Jul 03 '22 at 16:28
  • I'm afraid I'm just relating what the message explicitly told you, no matter how you want to look at it. I have no problem with you trying to justify why you happened to misinterpret the message, but I can't follow you with blaming the developers for failing to take into account that some users may misinterpret the message based on incorrect assumptions... which you are still putting forward with the idea that a new drive can't fail, or that backup boot sectors should be write protected, or that third party software (you seem to hint at using Windows alongside Debian) can not alter data. – Akeo Jul 04 '22 at 00:11
  • (Btw, your assumption is wrong: There is no Windows involved here, except for using Rufus once at the beginning. No dual boot or mounting under Windows.) – srhslvmn Jul 04 '22 at 01:54
  • So, what you are saying is that, since you used Windows to create your live media, and as I tentatively suggested (rather than assumed), Windows did have a chance to potentially alter your backup boot record before you ejected the drive? – Akeo Jul 04 '22 at 13:11
  • Frankly, I'm not even sure what you are talking about as Windows has - as far as I know - nothing whatsoever to do with the problem. Not sure why you keep mentioning Windows here, this is a Linux issue. PLEASE READ THE QUESTION. Thank you – srhslvmn Jul 04 '22 at 15:48
  • Also, if you happen to be personally involved in developing dosfsck, feel free to "come out of the closet" and have a discussion on possible solutions – srhslvmn Jul 04 '22 at 15:50