Fortunately, every piece of data was recovered successfully. My initial decision to experiment with bootrec.exe at the most critical moment of this incident instead of using a tool I have used in the past and trust (Testdisk) made me very skeptical about how I handle situations like this. Also, I should have followed some standard procedures like creating an image of the whole disk before trying any kind of data recovery.

As for skipping daily backups without reason, I can assure you that this is an unexplained behavior of mine too! During the last years, I’ve written numerous backup scripts, but I always focused on some machines I used as servers. Backing up my desktop or laptop had always been a low priority task. But, I’ll set some new priorities from now on.

Also, I think I will have to reduce the number of computers that lay around at home to the absolute minimum. That should make things more clear regarding which kind of data is important and which is not.

I try to keep daily backups of my laptop (pretty much the only machine left around here). But I’m also guilty of often skipping the daily backups for 5-6 days in a row. I know that this is a silly thing to do, but I still do it. To make things ‘easier’ I have scripted my backup process, so all it takes is a daily run of:

sudo /root/backup.sh 1

for a full level 1 dump of all my partitions, and

sudo /root/backup.sh 2

for a level 2 incremental dump of all the files modified since the last level 1 dump.

Yet, I still skip some backups. Go figure…

http://tech.shantanugoel.com/2009/07/07/virtualbox-high-cpu-usage-problem-solved.html

I created a dummy windows guest vbox and gave it 4 MB disk and 4 MB ram. I boot it from an empty CD and let it sit at the “FATAL: No bootable medium found! System halted.” screen.

As soon as I run this, my VirtualBox.exe process goes down 0% CPU. Whenever I don’t have it running, it hovers around 40% on my E6700.

Easy solution. Not sure why it works, but hope it helps!

-rwsr-xr-x 1 root root 35108 Jun 15 2004 /bin/ping

Note the s in the permissions. Ping is setUID root. This allows unprivileged users the ability to use ping. Why this is done is because ping (ICMP) require that the interface be placed into a listening mode, which requires root privileges to do. Additionally ICMP itself is a low level protocol requiring root privilege. With ping you are working at the hardware level. With something like a web browser you are working much higher in the food chain.

Is this a security problem, yes, which is why your python ping requires root. This is also why systems using busybox usually don’t allow normal users to do ping as setting ping setUID root can set all of the busybox commands setUID root.

Thanks for letting me know.

I understand the change, however I don’t understand how it corrected operation of the program. Initially, tcpdump showed packets were being sent but no responses were received and the resulting RTT was 0.0ms. Now, I see requests, responses and accurate RTT. How did your change correct all this?