Well,I was going to shop for a backup external drive today (HDD failure yesterday that fsck cannot repair in busybox this time)

Once again, second time, out of nowhere, the main drive where 20.04.5 LTS was, which I knew
was on its last leg what with its one broken sector and having saved it from total disaster with
a well timed busybox fsck /dev/sdx/ -y after the loading icon of UM itself went to busybox when the forced fsck it was doing in the background failed and asked me to do it manually.

It didn't look good from what I was seeing, hours of I/O errors and failing to correct inodes etc....things looked pretty much like this except for different ATA and drives

I was going to go buy a usb 3.0 drive to perform a backup tomorrow (saturday morning), as I knew I was going to need to do this. But I didn't expect yesterday's huge upgrade of packages I was pretty unfamiliar with, a lot of it dealing with x86 packages, which unfortunately I had updates for since I installed WINE a week before WINE 7 was released, which doesn't need the i386 architecture, here's the list of unfamiliar (mostly) package updates where the Read-Only issue showed up very soon after, seemingly destroying the drive and a few files in the root folder when taking a look from a usb live session

Start-Date: 2022-10-13  20:56:01
Commandline: aptdaemon role='role-commit-packages' sender=':1.5712'
Upgrade: libgssapi3-heimdal:amd64 (7.7.0+dfsg-1ubuntu1, 7.7.0+dfsg-1ubuntu1.1), libgssapi3-heimdal:i386 (7.7.0+dfsg-1ubuntu1, 7.7.0+dfsg-1ubuntu1.1), libwind0-heimdal:amd64 (7.7.0+dfsg-1ubuntu1, 7.7.0+dfsg-1ubuntu1.1), libwind0-heimdal:i386 (7.7.0+dfsg-1ubuntu1, 7.7.0+dfsg-1ubuntu1.1), libheimntlm0-heimdal:amd64 (7.7.0+dfsg-1ubuntu1, 7.7.0+dfsg-1ubuntu1.1), libheimntlm0-heimdal:i386 (7.7.0+dfsg-1ubuntu1, 7.7.0+dfsg-1ubuntu1.1), libgmp10:amd64 (2:6.2.0+dfsg-4, 2:6.2.0+dfsg-4ubuntu0.1), libgmp10:i386 (2:6.2.0+dfsg-4, 2:6.2.0+dfsg-4ubuntu0.1), libheimbase1-heimdal:amd64 (7.7.0+dfsg-1ubuntu1, 7.7.0+dfsg-1ubuntu1.1), libheimbase1-heimdal:i386 (7.7.0+dfsg-1ubuntu1, 7.7.0+dfsg-1ubuntu1.1), libgmp-dev:amd64 (2:6.2.0+dfsg-4, 2:6.2.0+dfsg-4ubuntu0.1), libgmpxx4ldbl:amd64 (2:6.2.0+dfsg-4, 2:6.2.0+dfsg-4ubuntu0.1), libhcrypto4-heimdal:amd64 (7.7.0+dfsg-1ubuntu1, 7.7.0+dfsg-1ubuntu1.1), libhcrypto4-heimdal:i386 (7.7.0+dfsg-1ubuntu1, 7.7.0+dfsg-1ubuntu1.1), unzip:amd64 (6.0-25ubuntu1, 6.0-25ubuntu1.1), libroken18-heimdal:amd64 (7.7.0+dfsg-1ubuntu1, 7.7.0+dfsg-1ubuntu1.1), libroken18-heimdal:i386 (7.7.0+dfsg-1ubuntu1, 7.7.0+dfsg-1ubuntu1.1), libasn1-8-heimdal:amd64 (7.7.0+dfsg-1ubuntu1, 7.7.0+dfsg-1ubuntu1.1), libasn1-8-heimdal:i386 (7.7.0+dfsg-1ubuntu1, 7.7.0+dfsg-1ubuntu1.1), libkrb5-26-heimdal:amd64 (7.7.0+dfsg-1ubuntu1, 7.7.0+dfsg-1ubuntu1.1), libkrb5-26-heimdal:i386 (7.7.0+dfsg-1ubuntu1, 7.7.0+dfsg-1ubuntu1.1), libhx509-5-heimdal:amd64 (7.7.0+dfsg-1ubuntu1, 7.7.0+dfsg-1ubuntu1.1), libhx509-5-heimdal:i386 (7.7.0+dfsg-1ubuntu1, 7.7.0+dfsg-1ubuntu1.1)

I did lose some data in root directories making the system now-unusable, but I didn't lose the very little data on it that wasn't system related at all except for a very few files in /Documents....apparently I could have avoided this...

This morning when I just wanted to start a program by right clicking and select open on a desktop link to an app and suddenly a lock would appear on the icon, then it did on every icon...just like last time...I knew what was going on, the system drive (thankfully with no data I can't afford to lose other than my settings and themes for UM, would have been fine not long ago with Aptik but that app is no longer free as of ubuntu 19.x) became read-only out of nowhere (well, out of needing fsck, the first time I was able to fix things, but this time the errors trying to fix any inode being this critical indicates to me that the drive is done. DIsks cannot even get its S.M.A.R.T. attributes...

I couldn't have a proper backup, but with an USB boot of 20.04.3 LTS, I see that the data is fine and I can copy it around to other drives.

Tomorrow after I come back with the external and a new internal drive I already have here where I wanted UM 20.04.5 (and soon 22.04.x) to be going on soon since I knew the drive wouldn't last that much longer (not too bad, it lasted 3 more months but I have drives much older that still work and have no bad sectors than this, the only internal Seagate drive I have,experience tells me their externals are better than WD, but definitely not made as equals when it comes to internal HDD's. Anyways, I never backed up an install this way before and since the drive sizes will be different, how do I make an image of the "failing" drive..it fails to boot, but I can access all the data just fine, so I assume I'll be able to make an image. I've had failed installs (mostly of my own doing when learning debian back in the debian 6/ubuntu 11.04 era) and it wasn't the drive dying being at fault, so I just reinstalled on the same drive and there would be no issue, I would not format the system drive and copying the data to my new home directory was all I had to do.

Now the big question, how does one easily bring in an image of a UM/Debian system drive that's sitting on an external drive. Let's assume I will be doing this from a live usb session like I'm using now, 20.04.3 LTS. Do the options in Disks suffice? I'll want to be able to make the image to the external drive from the live session and then extract it back to a new internal drive of a different size (SSD @ 512gb), external will be 1TB, the stuff is already prepared for me at the local shop. I never did a linux backup, at least, not this way, I know it's feasible.
Some say it could just be a defective SATA 6 cable, but meh, it already had a broken sector and knew it was inevitable. Some weird things happened just before the fatal read only system drive and then failed reboot requiring a manual fsck, regarding to login windows when the system would lock out while the screen would shutdown after 30mins of inactivity but I'll only elaborate on that once I get replies.

Lastly, is that old install dead forever? I'm afraid repeated fsck -y on the drive that didn't act normal did break some system data, I gave up when I saw posts on stackexchange saying the drive was dying (I already knew that and I just go lucky the first time I was thrown into Busybox fsck world)

I never tried Rescue/Emergency mode, a bit too old school for that, that didn't exist when I had my crash course on GNU/Linux Debian and Ubuntu circa 2011-2012. It's too bad I had recently installed Aptik 19, despite being able to install it, since it became payware for version 20 and over, I didn't think it was gonna be of any help and would just be a waste of my time.Found a tutorial here, if I make an image of the drive, once it is cloned back to the new internal SSD, will Rescue/Emergency mode be of any use or I shall bite the bullet and start over (at least now I'll have an external drive dedicated to backups only).

I'll trim the post a bit later if necessary mods :slight_smile:

P.S. I know I'm at fault here, it's the ultimate irony I was going to buy an external drive on Saturday and the failure happened on Friday morning...but I have to mention I have a usb 3.0/eSATA dock with just one slot can take either HDD or SSD (regular)...should've bought the 2 slots one and use at least one as a mirror with RAID, but not sure it would work, I needed to format that drive in the dock to GPT format, UM 20.04.5 drive is just 1TB so regular formatting...anyways I forgot how RAID works a long while ago, when I learned about it, it demanded exactly same model HDD's and had maybe 4 modes, so it's been long while...

Now the big question, how does one easily bring in an image of a UM/Debian system drive that's sitting on an external drive. Let's assume I will be doing this from a live usb session like I'm using now, 20.04.3 LTS. Do the options in Disks suffice?

Yes :slight_smile:
In case that the stuff doesn't boot from the new drive, you can use boot-repair:
Boot-Repair - Community Help Wiki

It might be better (and probably much faster) to do a clean install on the new drive:
You never know what files or sectors will fail to copy and you might end up, in case of read errors, with a horribly limping system.

Ofcourse I assume you have your data saved.


Yes, there was little data on the system drive, I tend to keep my data on other drives than the one the OS is on.

Maybe it's because I'm on a live session, but Seagate's SeaTools 5 for Linux isn't able to do anything for the drive, not able to even fo a short scan on it. It made me realize the drive isn't updated to the latest firmware, I'd do it, but SeaTools asks for files with extensions that Seagate's website will not give me, to get those, I'd need to take it out my desktop and enter in the serial number. Because I realized it could be just a faulty SATA cable afterall and the only tool I know of that would tell me exactly that is a Windows only program...I'm not going to install WINE on a live session....so all they give me is a .iso file to put on a usb stick or burn to a disc where they Drive Detect software that works from boot.

I got a not-so cheap 1TB Verbatim external usb 3.2 (that apparently works fine with just 3.0) drive to use as backup, they were out of the usual SG and WD ones and the only other option was a Toshiba....I had a Toshiba laptop for a while, wonderful machine, was almost as strong as this desktop, might have had a better graphics adapter even, but it crapped out entirely (mobo) within 6 months, so I went with that Verbatim external and I made an image with Disks, it had tiny issues doing so, because of some unreadable data, but I had to tell it to ignore it. But that still doesn't confirm the drive is dead, I need to get unlazy and take it out to update it to a new firmware and also use of those brand new sata cables and see if it is really dead. I bought it in 2014, but I got 500gb drives from 2005 that still work fine and that I use on that usb dock, it's hot-swappable so I don't even have to turn it off, can just pull out any HDD or SDD from it.

Thanks for reassuring me, I never played with Disks' image options (I know it's just a gui for dd). I just think it could be the SATA cable, since that damn drive appears once out of every manual reboot at the boot screen where the drives are listed, sometimes even having to enter BIOS/UEFI to add it to the list of bootable internal drives and put it at the top of the list. It's been like this long since before it caused me problems. I'll have to pull it out anyway when I put in the 512gb WD Blue SSD since there's only so much space inside the desktop tower..