I am not sure why all the attention on trying to recover data from a corrupted partition. If fsck doesn’t work properly then the corruption is severe.
At that point the best thing with IPFire is to get a new drive, do a fresh installation and then do a restore from the latest regular backups that have been stored off of IPFire.
it could also be that /boot is corrupted. @jon probably just wanted a command to fix it and being done. My posts were written with the intent to inform the community. From the practical point of view, of course your suggestion is the most logical and from what I understood @jon is waiting for a new disk to arrive next week. In the mean time I assume he wanted to see if there was a command to launch to fix the broken system. From this perspective, I am afraid that failing fsck, there is not much to be done.
Yes, I too see what @bonnietwin said as the only solution.
If you really want to patch for urgency, you can try anything. But I see it almost impossible to solve the problem any other way, If the SSD is broken.
But if you have the previous backup, what is the problem?
I would format the machine and reinstall IPFire.
If it is a software problem, everything will run again.
If it was broken SSD, it will probably fail to install IPFire.
Addressing the issue of a failing IPFire requires a strategy that minimizes downtime, given its critical role as the firewall and router of our network. Drawing from personal experience, I devised two solutions to ensure minimal intervention and low downtime, one for myself and another for a friend.
My approach: I maintain a ready-to-use replacement disk, which is a clone of the original. Utilizing an eSATA-USB adapter, I synchronize the two disks with every IPFire update. This strategy not only prepares me for disk failures but also allows for a quick rollback in the event of bugs introduced through updates; I simply swap the disks to revert to the backup.
My friend’s solution: He modified the APU case to access the SATA interface and connected the SATA disk using an mSATA to SATA adapter and cables available from PCENGINES. This setup keeps a replacement disk online at all times. The boot sequence prioritizes the SATA disk, followed by the mSATA. In case of a failure, he can swiftly switch to the emergency hard disk and reboot the system by just plugging it in.
Both strategies aim to reduce downtime significantly and ensure a smoother recovery process during IPFire failures.
Yes. I recognize that a very good strategy. I too follow a similar scheme, not only for IPFIre, but for important servers. Having a cloned disk is the best way to solve it permanently and quickly. I always ask myself the question: If this machine was destroyed, would I be able to redo it quickly? I have to answer YES. Then I am comfortable.
I use DD to clone. Only it has to be done before breaking.
Perhaps it could be problematic for large disks (over 1T). But at least save a backup. Also come to a compromise between cloning and backup data.
I got the recovery tool I has looking for and I am back up and running (except for some testing to make sure.)
The boot directory went bad and could not be repaired by fsck.
I had good backups except for a few hours of work.
Lessons Learned:
A million thanks to all those that provided ideas and support!
I am going to close this topic as solved!
Jon