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 
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...