I screwed up my SSD badly (Bad magic number in super-block issue)

ARM General system
1

I was really hoping that my small problem earlier was the last time I’d have to ask for help here. Not only is this one worse, I can’t find a single suggestion online that works.

So I bought a RPi 500+ with the help of some friends to replace my laptop that broke. From the start I knew I wanted to run Arch on it since I don’t like RpiOS and I’ve long loved Arch-based Linux, and saw good things about Endeavour. My experience so far with enOS has been amazing.

Here’s the catch: I’ve been running the computer off a microSD card that came with an older Rpi kit I partially cannibalized for a little under a month. This is obviously not optimal, for both the computer and the card, especially when the 500+ comes with a nifty 16GB of RAM and 256GB SSD. I decided to dedicate this weekend to transferring all of my stuff off the microSD card to the SSD so I can actually use this thing’s full power. I formatted the SSD what I thought was correctly (spoiler alert: it was not) and used rpi-clone to do this.

I immediately knew something was wrong when rpi-clone gave me messages that it couldn’t find the UUID of the SSD or the disk name, but said that it had been partitioned after all. I then booted the computer from SSD but with the microSD still in it; despite theoretically being booted from the SSD, it was actually running from the microSD, as evidenced by me trying to eject the card and the operation being rejected because it was in use.

I shut the computer down, pulled out the microSD card, and tried booting from SSD again. Partial boot before freezing for an hour. Shut it down again, tried again, black screen. Tried again twice to see if anything different happened, nope. Black screen.

I then plugged the Rpi itself into an ethernet cable to see if I could network install. I could not. A few minutes into the process, it hit me with a fatal error.

Then, I put the microSD card back into the computer, ran fsck, and it gave me this:

fsck from util-linux 2.41.2
e2fsck 1.47.3 (8-Jul-2025)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/nvme0n1

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

/dev/nvme0n1 contains `DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 500118191 sectors, extended partition table (last)' data

And that’s where things stand right now. A microSD card running Endeavour, which I am typing here from right now, and an SSD that is seemingly cooked.

I’m sorry for taking so long, I just wanted to document every step of what happened because I know details matter when it comes to this.

I would, very obviously, like help.

2

Well it is always hard to answer to a topic when someone writes that no solution online could be found.
But I am going to try anyway by giving you this link

1 Like
3

Okay, things are getting kinda funky.

Ran fsck on the partitions individually, nothing wrong showed up. Ran smartctl, it said nothing was wrong with the drive.

4

can you report

sudo parted -l
5

Well you mentioned cloning the drive, and that the UUID couldn’t be found , but the partition of the drive you are cloning to would have another UUID than the source drive had in the case the SSD has been partitioned before the cloning action. Maybe that would be something to look at. Also run something like gparted and/or partitionmanager or something like that (I am not familiar with Arm , and what partitionmanager is used).

6

Sure.

Model: XP1000F256G (nvme)
Disk /dev/nvme0n1: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End    Size   File system  Name     Flags
 1      2097kB  539MB  537MB  fat32        primary  msftdata
 2      539MB   256GB  256GB  ext4         primary
7

Slight update, it is listing UUIDs now. There is a possibility that rpi-clone copied these over from the microSD.

/dev/nvme0n1p1: LABEL_FATBOOT="BOOT_ENOS" LABEL="BOOT_ENOS" UUID="74DB-B4E4" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="primary" PARTUUID="c5163558-138f-4ba3-92a9-ca8a09835b04"
/dev/nvme0n1p2: LABEL="ROOT_ENOS" UUID="bdf25a60-f050-4c97-a265-10afd5fcd67e" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="primary" PARTUUID="4dbc8347-dcda-4585-a4cf-15ee00264391"
8

It is rather likely I guess that the rpi-clone copied the UUID because I can remember to try to put back a backup with timeshift and ran into a problem to put it back on a prepartitioned drive.
Maybe this topic might be of some use.

9

Personally, in this situation, I would use my currently running system and create a new partition table on the SSD.

Then I would download an image of EOS ARM and flash it into the disk. A fresh install.

https://endeavouros.com/endeavouros-arm-install/

3 Likes
10

if clone uSD install on to nvme it no boot…
if you cat “/boot/cmdline.txt” + “/etc/fstab “

all so might need look at “/boot/config.txt” for nvme boot

you will see why

EDit..arch chroot while boot from uSD install to change what needed

11

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.