Salix Forums

There is a nasty issue on a laptop that runs Salix 14.1 (Xfce version). Salix was installed a few months now, and worked perfectly... until I tried to hibernate the system. Once I tried to reboot after that, I got this error message: /dev/sda5 is my root directory. I booted from Salix's CD and tried but I get a message telling me the filesystem has valuable metadata changes in a log which needs to be replayed. It also suggests I should mount the filesystem to replay the log before repairing. So I did (I made a directory and tried to mount the partition there), but I get the same error as above. Now, xfs_repair can ignore the log, if I add the -L flag, but it warns me I may corrupt the disk that way.
Before proceeding, I thought I should ask here, as I am not even sure xfs_repair is the way to go. I am just sure the computer worked without any issue before I tried to hibernate it.

Weird. How large is your swap partition? And how much is your RAM? Also, how old is the HD? I'm thinking it's not impossible this is a hardware problem with the HD.

Since nothing else seems to work, I guess your only choice at this point is to run xfs_repair with the -L flag. And cross your fingers...

Try to log everything to a file, so you can post any results here. will write a LOG file with all output.

gapan wrote:Weird. How large is your swap partition? And how much is your RAM? Also, how old is the HD? I'm thinking it's not impossible this is a hardware problem with the HD.

I would think the same, but it seems extremely unlikely the supposed damaged disk crashed right at the moment I tried to hibernate it. That particular laptop is about 5 years old, has 4 Gb RAM, and swap partition is 6Gb. I know normally swap should be 2 x RAM size, but I think that's a rather old rule, coming from the era RAM was usually much less than the typical nowadays. Besides, the usual memory footprint of this laptop in every day's use is less than 2Gb, so swap memory is never needed.

Anyway, the / partition seems to be ok now, after a xfs_repair -L /dev/sda5. I could not log its output to a file, because the tee command was not available in Salix's disk, at least not in the normal (not live cd) version. However, xfs_repair complained about a unlinked "bucket" and put something in the lost+found directory. After normal reboot, system seems ok, except that a directory called CMakeFiles and a file called CMakeCache.txt are present in my root directory, and they definitely don't belong there. Inspecting said file and directory, i found out they are about the ar command (which I don't remember installing explicitly or implicitly), and they should be located in /usr/src/slapt-src/libraries/, not in /. I'm not sure which package compiled such a command, but I installed several packages from SBo, so it should be one of them.

Marked as "solved".

OK, good, at least there is nothing unrecoverable.

The RAM/swap sizes are fine. You should be able to hibernate with no problems if swap is the same size of your RAM (or just a bit larger to be on the safe side).

About the files in lost+found, you can use the file command on them to try to find what they are. Could the CMake* files you found be from something you were compiling at the time you hibernated? I'm thinking maybe there was something accessing the HD heavily at the time the HD was shut down for hibernation, but I'm not really sure how possible this is. Maybe try to hibernate again and see what happens?

The ar command is from the binutils package and it is included in all installations by default. There was also no update of the binutils package lately, so it is very unlikely something was being altered in your system with respect to it.

The file in lost+found seems to be a useless relic of whatever happened: And indeed, it's empty, 0 kb.

It is true I had a batch-compiling session earlier, running scripts that compile all my own libs and stuff. But that was one hour earlier and should be done well before the hibernation (I admit I didn't check for disk activity when I tried to hibernate, but there is no way computer was still compiling my libs).
Anyway, I tried to hibernate again - no issues at all; it did exactly what I asked. Not that I will do it again anytime soon. Salix boots and shuts down so fast that hibernation makes little sense. When I'm thinking of people praising that intrusive "init service" called systemd for fast booting, I can't help it but smiling.