The tool you used dd
isn't a file copy tool, it's a disk copy tool and it copies byte for byte. This means that every piece of information, including meta data about the amount of space in the partition on the drive, has been copied.
You need to do a full backup of your files, format the drive (including a full parition format) create a new ext4 root parition and swap drive and then copy the files over.
Once you've copied the files, you need to chroot
over to the new system and run the update-grub
command to install the boot system on the new drive.
Or you could just run a new install of Ubuntu and put your files back.
What Oli did to fix this
- Booted to a LiveCD and selected "Try Ubuntu"
- Mounted my SSD and also another disk (to copy to)
Ran
sudo rsync -ax /media/ssd /media/backup-drive/ssd-backup
This takes a long time. I did some cleaning up before copying but still had 35GB and while I was getting write bursts of ~120MB/s, it took a while. rsync won't give you output by default but you can add --progress
if you want a perverse amount of detail (although it moved too fast for me to really read it -- and probably just slowed things down).
- I tried to nuke the drive but was getting "device busy" issues from palimpsest (Disk Utility) so I ran the installer! In the installer I just told it to create a nice filesystem using the whole SSD drive and then ran
killall ubiquity
after it had started copying files.
Then I nuked all the files that the installer had copied in, then I copied back the backup files:
sudo rm -rf /media/ssd/*
sudo rsync -ax /media/backup-drive/ssd-backup /media/ssd
- Then I rebooted and found my UUID had changed (obvious when you think about it) so grub2 had no idea where to boot from and blew up so I headed back into the LiveCD. If you're following this as a guide, I suggest you skip this step ;)
- Reinstall grub! I followed the help docs and followed the chroot option. You might find you need to edit your
/etc/fstab
while you're in there.
- Reboot and you should be done. I'm back, I've got a metric "oodle" of free space. Huzzah.
You are absolutely right. The according fstab entry would look like this:
tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777,size=512M 0 0
Please note:
As tmpfs
gets filled up, it will behave as any physical hard drive by giving an "not enough space" error. While rebooting (and thus emptying the cache) will fix this, you may run into trouble when a single operation consumes more space to begin with than there's space on tmpfs
. In this case your computer will start to swap from ram to disk, which will make your system crawl to a halt, given you've got a swap partition to begin with, of course.
Considering this, a size of 512MB might be far too less nowadays, since much more ram is in existence in modern machines and it has become much cheaper. Since you've already got 16GB of ram, using the default value of half your ram for tmpfs
should more than suffice for almost all scenarios. To use the default value, simply leave out the size=512M
entry in your /etc/fstab
file.
Another note:
You can quite as easily mount other system folders into ramdisk as well, such as
/var/cache
/var/games
/var/log/apt
(use only defaults,noatime
without mode=
or nosuid
)
But beware: the same rules apply as above, running out of space might cause major trouble. E.g. imagine running out of space for /var/log/apt will render you unable to install any programs!
Furthermore, loading /var/log
folders into ramdisk will delete all your log files upon reboot, so you won't be able to debug your system if anything unexpected happens.
So use these settings at your own risk!
Editorial note:
I removed the /run
in tmpfs
mount option since this folder and its subfolders are already mounted in tmpfs
by default.
Best Answer
cp
copies files. If you specify a directory (I've never tested this) it would probably copy the contents of this directory, and place them all (including the original folder) into the destination directory. Yes, it will create two copies of the target file(s) and yes, it will probably disturb a number of things like that.You can drag and drop files easily in Nautilus to move them naturally, without the negative effects on hard drive optimization. The
mv
command in terminal will do the same thing. It's similar in usability to the cp command:Where the target is a file, or a directory, and the destination is a directory.
NOTE: If you use
mv </location/filenameA> <location/filenameB>
it will rename the file. For example,will rename the
xorg.conf
text file toxorg.conf.backup
. Try doing a google search of useful linux command line tools.Another neat trick in command line is using the 'man' option. For example
or
The 'man' stands for manual. Every terminal application has a manual detailing the nature of the application, all of it's options, and definitions for everything. You can run the man option with any terminal command you install.