Feeding Your Fish with Fake Food: Imitating a Wireless Network

Creating a dummy network may be useful at times where you want to replicate a local network at a different location. For example, the network configuration of one of my development set-ups is dependent on my workplace Wi-Fi network, and I wanted to use the same configuration at my residence as well (for working during out-of-office hours).

This is how I solved the issue on Ubuntu 16.04:

1. created a new Wi-Fi network (say Dummy)
2. configured settings of the new network to be identical to that of the workplace network config
(Now, although the config is present in /etc/NetworkManager/system-connections/Dummy, I cannot connect to it since there's no physical network.)
3. converted the network to a Wi-Fi hotspot by editing /etc/NetworkManager/system-connections/Dummy and replacing mode=infrastructure with mode=adhoc
(Initially creating a Wi-Fi hotspot and later changing its configuration (as suggested in some forums) did not work in my case, as the network kept on getting reverted back to infrastructure mode during the activation of the hotspot.)

Now, when I turn on my Wi-Fi adapter and connect to the Dummy network (usually via the "Connect to hidden Wi-Fi network" option on the NetworkManager applet menu, as the new network is not visible on the available networks list most of the time), my set-up works just as if it was connected to my workplace network.

Reincarnation of a Silicon Soul: Migrating a Physical System to a VM

If you have watched the movie Chappie, you would certainly remember how the self-conscious robot Chappie transferred his creator's consciousness—and ultimately his own—to another robot carcass. While such inception and transference of human consciousness may still seem far-fetched, trasferring the 'consciousness' (OS, applications and data) of a physical computer across is quite possible, at least into a target virtual machine.

Until recently I was using a fairly old HP430 laptop (Core i5, 4GB RAM, 500GB HDD, running Ubuntu 14.04), of which I was making full backups (i.e. of my work and, strange as it may sound, the system partition; using the handy rsync tool:

sudo rsync -a --exclude=lost+found --exclude=media --exclude=mnt --exclude=proc --exclude=run --exclude=sys --exclude=tmp / /media/janaka/SYSTEM/
sudo rsync -a --exclude=sysbackup --exclude=AndroHax --exclude=Desktop --exclude=Documents --exclude=Downloads --exclude=Music --exclude=Pictures --exclude=Public --exclude=Templates --exclude=Videos --exclude="VirtualBox VMs" --exclude=workspace --exclude=Documents --exclude=.android --exclude=.cache --exclude=.eclipse --exclude=.grails --exclude=.IntelliJIdea13 --exclude=.local/share/zeitgeist --exclude=.m2 --exclude=.mozbuild --exclude=.npm --exclude=.Private_encfs /home/janaka/ /media/janaka/SYSTEM/home/janaka/

When I recently switched to a new machine, I gave away the old machine to a friend. However, I didn't really want to part with my old machine, so I thought of trying to restore my old machine into a VM. Since I already had the (almost) complete status of the machine, it should not have been impossible.

Well, it wasn't that easy (partly due to a few blunders I made) and I could not still log in to my account using the GUI (though the guest login works fine), but the VM runs fine and I can log in and work on the tty. Anyway, the steps I followed may (hopefully) be useful for someone else stepping into the same waters.

Not intending to take the trouble of setting up boot configurations from scratch, I started off with an existing VDI with Ubuntu 14.04 minimal installed, and stripped off all content existing on the disk by mounting it via an Ubuntu live CD session:

sudo rm -r bin boot dev etc home lib lib64 opt sbin srv sys usr var initrd.img vmlinuz

Next, with the qemu-nbd tool I mounted the disk on the host and started replacing all its content with the rsync backup I had made (already mounted at /media/janaka/SYSTEM):

sudo modprobe nbd max_part=16
sudo qemu-nbd -c /dev/nbd0 /media/janaka/Stuff/VirtualBox/Test/Test.vdi
mkdir /tmp/part1
sudo mount /dev/nbd0p1 /tmp/part1/
sudo rsync -a /media/janaka/SYSTEM/* /tmp/part1/

Unfortunately it turned out that the VDI I used wasn't large enough to accommodate the full backup content. I resized the VDI with VirtualBox's Virtual Media Manager, and tried to expand the partition already existing on the disk, after deleting the unwanted (swap and home) partitions from the original VDI:

sudo parted
select /dev/nbd0
rm 2 5
resizepart 1 18000
quit

Although both parted and its GUI pal (gparted) seemed to resize the partition (and had successfully eliminated the deleted partitions), the size change seemed nonpersistent as the disk size kept falling back to the previous value as soon as the QEMU mount was removed. After some desperate struggling, I luckily came across a set of articles (particularly the last part of this answer that dealt with a few similar issues, and a single command finally did the trick:

sudo resize2fs /dev/nbd0p1

After resize I proceeded with rsync, and things went fine.

sudo mount /dev/nbd0p1 /tmp/part1/
sudo rsync -a /media/janaka/SYSTEM/* /tmp/part1/
sudo qemu-nbd -d /dev/nbd0

However, when trying to boot the resulting VM, I ran into a GRUB issue:

error: no such device: myoldphysicalharddisksuuidwasdisplayedhere

Rather than following the regular "mount all dirs and run update-grub" approach outlined in many forums (e.g. this AskUbuntu post) I went ahead and directly modified /usr/lib/grub/grub-mkconfig_lib on the VDI ("remove the search lines for..." section mentioned in the question section of the above post).

sudo vi /usr/lib/grub/grub-mkconfig_lib

... find and comment out occurrences of this part
# if fs_uuid="`${grub_probe} --device ${device} --target=fs_uuid 2> /dev/null`" ; then
# echo "search --no-floppy --fs-uuid --set ${fs_uuid}"
# fi

... save and quit
:wq

And voilà, the VM started booting up successfully!

I managed to log into a guest session via the GUI (Unity), and to my account via a terminal session (logging into my own account gives a blank desktop, very similar to this issue). Most of my services were intact, including Apache, MySQL, VirtualBox and Docker, and using the latter I even managed to run a container in my "newly virtualized" system!