Hello,
thank you for the prompt answer!
Well, I agree that the messages are not exactly the same and that the inode (in my case) has a different value from the image on the link. I added the exact number to be precise. Good that you noticed this, as we (developers) really need to pay attention to the details.
Well, thanks for the provided link. Sorry for not including it before, but I had already found it. Actually, it was from this message that I learned about the chkdisk and shutdown procedure. Already did both of them before posting here, but forgot to mention. No, it didn’t solved the issue. Sorry, but I’m working on this for a lot of time. Was too tired when writing this. And yes, it was always complaining on the same inode number I wrote before. I also ran chkdisk and defrag, but nothing changed.
It is nice to hear that I have read and done the right things. Looks like I’m on the right track, which is encouraging.
Here is a picture of the problem.
And the second screen.
Tomorrow I will try the reboot test you mentioned. But before, there are new details I observed during my last tests.
First, it seems related to the way the disk is captured. This issue only happens when I select the first approach for disk capturing (whole disk, resizable image). I’m not at work now, so… can’t provide the exact option.
But When the second method is select, combined with “partClone (gzip)”, I was able to correctly capture a valid disk image. The folder was there, with all the files related to my seven partitions and with about 100GB of compressed files. Most probably there is a real issue here (somewhere), which was only circumvented by changing the cloning approach.
If you wish I can reproduce the problem, in order to help nail down the root cause. But before, I really need to prepare my labs.
Well, after getting the disk image, I took another machine with exactly the same hardware (brand, disk, ram, AMD cpu, devices, etc) and tested to deploy it. My test setup is currently very simple. Two machines connected only by a crossover cable. This is to test if everything will work. As soon as the image is deployed successfully, I will perform a full deploy.
The deploy test failed near the end. It started well and wrote one or two small partitions. On the windows partition, it failed. This area has aout 500gb of space, with about 130 being used. The procedure was going on just fine for about 25 minutes. After several GB being transferred, the client machine crashed with only about 8 minutes left to finish the partition. This is important to point out that the network card and cable were working ok during this time.
The failure was the tg3 timeout bug on the client machine. And now it became the (currently) most important bug for me to fix (or avoid, somehow). Unfortunately, today I could test it only once. I wonder if, by trying it a few more times, it manage to get to the end. If the problem is related to a concurrency problem, maybe I get lucky.
On the client, the last message was: “tg3_stop_block timed out, ofs=4c00 enable_bit=2”. This is from the tg3 kernel module, responsible for the Tigor3 wired network device.
On the server, the kernel log shows an ERROR related to a FIFO underrun. Here are the pictures.
Tomorrow I will run more tests and try to provide more information.
Best regards,
Paulo