Language Selection

English French German Italian Portuguese Spanish

Four Tough Lessons of System Recovery

Last week, I received a brand new laptop with 1.5Gb RAM, a 100GB SATA HD, and a 15.4-inch wide screen, brightview display. It has basically all the technical gizmos that can spoil a new employee.

The computer came to me installed with Windows XP Pro. My game plan was to transfer my files via a USB disk to the NTFS partition and then transfer my second partition which is Debian Sarge (so-called) Unstable, and keep up with my regular business.

My weapon of choice, when I have to use Windows, is a VMware Workstation, configured to work with the real partitions--not the loop filesystem. This means that if I change anything, my files are still there when I boot Debian.

So, I started VMware as usual, configured it to use the physical hard disk, and began my operation.

I used a USB disk to transfer my old system. After that, I began to erase my old disk, which contained the NTFS system partition (C), an NTFS data partition (D), and the Debian partition.

While doing this I first erased my D and Debian partitions with fdisk and wrote the changes to the disk.

After I exited cfdisk, I caught a glimpse of hda1, which troubled me and left me staring at the empty black screen with the root cursor wondering what was wrong. The thing was, that device should have been sda, which was the mounted USB drive, not hda--the laptop's native disk.

I turned red. I had just wiped the partition that contained my backup data and the installation files of my laptop. Fortunately, my boot partition was still there, so I just had to collect my backup data (some 60GB) from different computers and copy them again, which looked like half a day or so of work.

My First Attempt

Full Story.

More in Tux Machines

Intel Cache Allocation Technology / RDT Still Baking For Linux

Not mentioned in my earlier features you won't find in the Linux 4.9 mainline kernel is support for Intel's Cache Allocation Technology (CAT) but at least it was revised this weekend in still working towards mainline integration. Read more Also: Intel Sandy Bridge Graphics Haven't Gotten Faster In Recent Years

Distributing encryption software may break the law

Developers, distributors, and users of Free and Open Source Software (FOSS) often face a host of legal issues which they need to keep in mind. Although areas of law such as copyright, trademark, and patents are frequently discussed, these are not the only legal concerns for FOSS. One area that often escapes notice is export controls. It may come as a surprise that sharing software that performs or uses cryptographic functions on a public website could be a violation of U.S. export control law. Export controls is a term for the various legal rules which together have the effect of placing restrictions, conditions, or even wholesale prohibitions on certain types of export as a means to promote national security interests and foreign policy objectives. Export control has a long history in the United States that goes back to the Revolutionary War with an embargo of trade with Great Britain by the First Continental Congress. The modern United States export control regime includes the Department of State's regulations covering export of munitions, the Treasury Department's enforcement of United States' foreign embargoes and sanctions regimes, and the Department of Commerce's regulations applying to exports of "dual-use" items, i.e. items which have civil applications as well as terrorism, military, or weapons of mass destruction-related applications. Read more

Linux Kernel News

Games for GNU/Linux