"Have tried everything but Ubuntu keeps giving an error" Part 2. It doesn't work AGAIN.

Hey there,
This is kind of a follow up to a previous post of mine.


I advice you to read that post before reading this one.

We’ll call that post Part 1 one and this post Part 2.

So after installing Ubuntu with my usbstick (written in DD-image-mode) everything worked fine as I mentioned in that previous post.

Two days ago I did some sudo apt update/upgrade. It was quite a big list of things that it updated.
I noticed in the list of things “kernel” something. It was probably updating the kernel or something. After everything was done, it said it needed to reboot, probably because it had updated the kernel, so I clicked OK (I was using the gui version of update/upgrade).

It shutdown and when it booted up, I couldn’t ssh into it, so I shut it down again. I hooked up a monitor to the server and started it up. I got the following on startup (I dont know it word for word):

invalid magic number
press enter to continue
[can’t remember what it exactly said, had something to do with failing to boot both two options]
can’t boot in normal mode and recovery mode
press enter to continue
you need to load the kernel first
press enter to continue

And then automatically went into gnu grub 2.04, getting the options to boot ubuntu, go into recovery mode, do a memory test or do a memory test with [someting, i think terminal].
It doesn’t matter which option I choose, I get back to the “invalid magic number bla bla bla” screen. It shows to whole thing which you saw above and then get loaded in the gnu grub again. It’s a loop, every option brings me to that screen and back to gnu grub.

I wanted to compare the sha245sum, and found the following link: Link

I compared the sha265sum of the iso file that I used, with the sum on ubuntu’s website. Using the following command in my (correctly working haha) ubuntu vm (I’m more comfortable with linux terminal than with Win10 terminal):

cd /media/cas/[usb-stick]/ubuntu-20.04.1-desktop-amd64.iso
sudo sha256sum ubuntu-20.04.1-desktop-amd64.iso

As a result I get:

b45165ed3cd437b9ffad02a2aad22a4ddc69162470e2622982889ce5826f6e3d *ubuntu-20.04.1-desktop-amd64.iso

Which, using the sha256sum’s on ubuntu’s website, compare correctly. So my ISO-file is correctly downloaded.

But when I do the following to check the live usb (that is the usb that was used to install ubuntu at the end of part 1, with exactly the same flash, so not a replaced/new flash on it), I get a different result.

cd
sudo sha256sum /dev/sdb

I checked that the live-usb was /dev/sdb using “sudo fdisk -l”
I get the following sha256sum back:

23d41850f0c0802eb3d5a869ffc486c4447f9df701e505302268c6e3e4a3049c

Which is a totaly different sum. Compare for yourself:

ISO file [correct]: b45165ed3cd437b9ffad02a2aad22a4ddc69162470e2622982889ce5826f6e3d
Live-USB [incorrect]: 23d41850f0c0802eb3d5a869ffc486c4447f9df701e505302268c6e3e4a3049c

But ofcourse we can’t forget about the fact that it worked for 30 days. It worked for 30 days, but when the kernel gets updated and needs to reboot, it doesn’t work any more.
For the people that forgot it:

I noticed in the list of things “kernel” something. It was probably updating the kernel or something.

It’s logical to say that the sudo apt update/upgrade crashed it. Which I agree on. But what crashed it? It updated the kernel, which crashed it. And the screen I got, which I also got in part 1, suggests a corrupted usb install.
What I said in part 1 btw:

It said that it (something like, can’t remember) couldn’t load kernel or something.

Conclusion:
The system updates the kernel and suddenly can’t boot. I get an error message that I had before and that suggests a corrupt usb install, as said by the following people:
Source 1 (reddit)

Your install USB is corrupted, […] all involving “rufus” or some similar installation utility.

Source 2 (linux.org)

It sounds like the transfer of the ISO to the USB drive wasn’t done successfully.

And isn’t it strange that the sha256sum of my live-usb (rufus, DD-image-mode) doesn’t match up with the sha256sum of ubuntu? Maybe it has something to do with it, don’t you think?

I have done a new flash with the ubuntu ISO-file to the usb-stick (which i tested with h2testw and ended up working correctly) with balenaetcher (AKA balenaetcher, normal), and at the end got the following message:

“Checksum does not match for range [0, 2785017855]: “518b67e0fd147506” != “30862bfab4641c2c””

When I go to my Ubuntu vm and do the following (AKA checking balenaetcher, normal instead of rufus, DD-image-mode):

sudo sha256sum /dev/sdb

I get the following sha256sum

1c8dd4ab049ba5cb1970dd0f62dfb572ad82b9d627716192502773aa934fe69b

Which does not compare to any:

Original Ubuntu sha256sum [original]: b45165ed3cd437b9ffad02a2aad22a4ddc69162470e2622982889ce5826f6e3d
ISO file [correct]: b45165ed3cd437b9ffad02a2aad22a4ddc69162470e2622982889ce5826f6e3d
Live-USB [rufus, DD-image-mode]: 23d41850f0c0802eb3d5a869ffc486c4447f9df701e505302268c6e3e4a3049c
Live-USB [balenaetcher]: 1c8dd4ab049ba5cb1970dd0f62dfb572ad82b9d627716192502773aa934fe69b

Now in part 1, I mentioned the following:

When i choose the iso file and the drive and balena starts doing it’s thing, at the end I get an (NTFS) ‘1 failed target’ message. But with exfat I get an (exfat) ‘1 successful target’.

A little explanation is that when I format the usb-stick to ntfs, and then flash it with the ISO-file, I get an error message. But when I format the drive in exfat, and then flash it with the ISO-file, I get no error message.
In part 1, someone mentioned that balenaetcher formats drives before it starts flashing, but it’s still a fact that, when it’s formatted exfat, it works and when it is formatted ntfs, I get an error. So I don’t care that balenaetcher formats a drive before flashing, because when I format it ntfs, I get an error, and when I format it exfat, I don’t.

So I formatted the drive to exfat, flashed it again with the ISO-file, checked the sha256sum and got the following:

c30f4abe3cbec12fbe35a6492f0b21247d563ad83c0413e4e05b8159443aeb2f

A last comparison:

Original Ubuntu sha256sum [original]: b45165ed3cd437b9ffad02a2aad22a4ddc69162470e2622982889ce5826f6e3d
ISO file [correct]:
b45165ed3cd437b9ffad02a2aad22a4ddc69162470e2622982889ce5826f6e3d
Live-USB [rufus, DD-image-mode]: 23d41850f0c0802eb3d5a869ffc486c4447f9df701e505302268c6e3e4a3049c
Live-USB [balenaetcher, normal]: 1c8dd4ab049ba5cb1970dd0f62dfb572ad82b9d627716192502773aa934fe69b
Live-USB [balenaetcher, exfat]:
c30f4abe3cbec12fbe35a6492f0b21247d563ad83c0413e4e05b8159443aeb2f

Different again. They’re all different (aside from the original ISO-file).

This explains why my vm works but my server not. The ISO-file works, so the vm works. But when I flash it to a USB-stick, it goes wrong.

So now I really need your help. That’s it. Help.

P.S. I don’t know why but I find it kind of fun to fix things like this. I’m just a 15 year old boy but I’m learning a lot from this, and I find it kinda entertaining. Only thing that’s not entertaining is that I’m probably gonna lose 1.5TB of plex media because of this thing but ok. I can re-download that haha.

Thanks for the details Cas. So, just to clarify, the failed Ubuntu at this point in time was actually flashed by Rufus, not Etcher, is that correct?

And like in your “Part 1” post, you ran some Ubuntu updates/upgrades, and the system failed to boot, again? Thus, you have used Etcher the first time, and Rufus the second time, and in each case your Ubuntu update results in a system that won’t boot?

I have to lean towards this being a bad update, not an image flashing issue.

Hello @Cas

You can’t compare the hash of your disk image and the hash of your drive. Their sizes are different.
You need to get the md5sum of the X first bytes of the drive where X is the size of the disk image.

Something like head -c $(stat -c %s /path/to/your/disk/image.iso) /dev/sdb | md5sum

Yes. The ubuntu that’s on my server atm, was flashed by Rufus in DD-image-mode. When I flash it in normal mode instead of DD-image-mode, I get the ‘filesystem checked: 1 error found’ message. But in DD-image-mode, I dont get that error.
The only time that I don’t get that error, is in Rufus, DD-image-mode. With Rufus normal or balena, I get an error.

Yes, the first ubuntu (original) on my server was flashed using balena. After the problems in part 1, I installed ubuntu for the second time but then being flashed by Rufus in DD-image-mode.

Both crashes happened after an update/upgrade. Update/upgrade probably (I’m certain of the second ubuntu, probably the first one also) updated the kernel. After that the system doesn’t boot. So it has probably something to do with the system not being able to load/apply the new kernel at startup after the kernel has been updated.

Do you have an idea about what could cause this? Is it hardware maybe? The system is quite old…

But when I’m searching up the error, everyone suggests corrupted install usb…

I know this more and more becoming an Ubuntu topic than a balena topic, but maybe you could still help me?

Edit: I found the following page


Should I try this? Or do you think the problem is somewhere else?

In my VM I typed the following:
sdb: usb stick with ubuntu iso file on it.
sdc: the flashed usb stick (balena)

sudo head -c $(stat -c %s /media/cas/DC2B-FDA1/ubuntu-20.04.1-desktop-amd64.iso) /dev/sdc | md5sum

As a result I get:

0038b576845f45d049a839748b44b0f6 -

I dont really know what the output means…
Does “-” mean that it matches?

Is 0038b576845f45d049a839748b44b0f6 the md5sum of the iso file and “-” the md5sum of /dev/sdc, aka the md5sum of sdc is the same as the md5sum of the iso file?

Edit:
After doing a sudo fdisk -l, I saw the two partitions on sdc. The flash is on sdc2, and sdc1 is empty. So I ran the command again but now with “/dev/sdc2”, instead of “/dev/sdc”:

image

/dev/sdc1

sudo head -c $(stat -c %s /media/cas/DC2B-FDA1/ubuntu-20.04.1-desktop-amd64.iso) /dev/sdc1 | md5sum

Gives:

0038b576845f45d049a839748b44b0f6 -

/dev/sdc2

sudo head -c $(stat -c %s /media/cas/DC2B-FDA1/ubuntu-20.04.1-desktop-amd64.iso) /dev/sdc2 | md5sum

Now I get a different result ofcourse:

8d3db90329582b1a8a8822e6bffdd3a2 -

So typing “/dev/sdc” or “/dev/sdc1” gives the same result. “/dev/sdc2” gives a different result ofcourse. The md5sum of /dev/sdc(1) isn’t probably rellevant because that’s the sum of an empty partition. /dev/sdc2 will probably be more usefull.

MD5 of iso file (using “openssl md5 path/to/file.iso”):
77fc715a283e41d0ad33d6418a9ba128

MD5 of /dev/sdc(1):
0038b576845f45d049a839748b44b0f6 -

MD5 of /dev/sdc2:
8d3db90329582b1a8a8822e6bffdd3a2 -

In the image you see that the drive is 2.6G (and a bit) big in total, while the drive is actually 64GB. That’s kinda strange.
image

On my Win10 computer you can see that 4mb is used and 57,3GB is unallocated (It’s in dutch, but I think you can get the idea).
image

Does this effect the md5sum’s? As you said the following:

The iso file is 2.7GB, the partition is only 4mb… So I’m not able to match X. And that partition is not the 1st but the 2nd. Would this impact the md5sum’s?

md5sums outputs <md5sum> <filename>
The - just means that this is the md5sum of the standard input.

A disk image is the whole disk, it can contain multiple partitions.
/dev/sdc is the whole disk, /dev/sdc1 is the first partition.

When you flash with Etcher, you flash the whole disk. The md5sum you’re interested in is the one of the whole disk (but only up to the same size as the original disk image).

To make it more clear, let’s split it:
md5sum /media/cas/DC2B-FDA1/ubuntu-20.04.1-desktop-amd64.iso will output the md5sum of the disk image;
stat -c %s /media/cas/DC2B-FDA1/ubuntu-20.04.1-desktop-amd64.iso will output the size of the image;
head -c SIZE /dev/sdc will read the first SIZE bytes of your drive;
head -c SIZE /dev/sdc | md5sum will output the md5sum of the first SIZE bytes of your drive;

The following commands with their output:

sudo md5sum /media/cas/DC2B-FDA1/ubuntu-20.04.1-desktop-amd64.iso

77fc715a283e41d0ad33d6418a9ba128

.
.

stat -c %s /media/cas/DC2B-FDA1/ubuntu-20.04.1-desktop-amd64.iso

2785017856

.
.

sudo head -c 2785017856 /dev/sdc | md5sum

0038b576845f45d049a839748b44b0f6 -

And “sudo head -c 2785017856 /dev/sdc” gave me so much output that it crashed my terminal haha.

Do you have an idea of what could be the problem?

Hi there, it certainly feels like a hardware issue, possibly with the USB media, but could also be with the target machine generally.