Tag Archives: tips

How to convert a physical hard drive to a virtual machine

This post is based on various notes from a project I did a while back. It all began when my laptop’s hard drive started making funny clicking noises. I took this as a sign it would stop working sooner or later, did a backup of the relevant things and replaced it. Since then, it had been lying on a shelf so I figured a fun project would be to turn it into a virtual machine. After all, a disk can be moved from one physical machine to another without any need for reinstalling or configuring with identical settings. Sounds easy enough to take whatever is on the disk, convert it to a virtual hard drive and boot it inside VirtualBox? That way, I could continue to use the existing installation even if the hardware failed. Turns out this wasn’t as straight forward as first expected.

Let’s start with the easy part, first we need to write the disk content to an image file. Not knowing the exact steps involved, it seemed like a good idea to have an exact copy. This makes it easier to experiment and go back if something fails or additional steps are needed. It also reduces the risk and issue of the disk suddenly dying if I have already grabbed all I need from it.

I plugged the old hard drive into my Ubuntu machine to make a copy of the content while the drive was still working. To create an image, I used dd which will create a byte for byte identical copy. As an example; dd if=/dev/sdb2 of=image.iso status=progress will create an exact copy of the sdb2 partition and store it in image.iso. Make sure a) that you read from the correct disk (check gparted or similar tools to be sure) and b) the target where you store the result has sufficient space. As we’ll get more into later, you want a copy of the whole disk not just individual partitions. Unfortunately this didn’t work in my case, attempting to copy the entire disk it would stop halfway through. Repeated attempts failed at the same exact number of bytes, presumably related to the disk problems. I therefore grabbed only the main Windows partition which I was able to without running into errors. That should be all I needed. Now that I had an exact copy of the disk (well, the parts I could get at least), I unplugged the physical one.

Next step was to convert the raw disk image to something the virtual machine can understand. In my case, I used VirtualBox’s tool for this conversion: vboxmanage convertfromraw image.iso virtualHd.vdi. Note that the raw image is a byte-for-byte exact copy and will need all the required space even to duplicate empty space, but the virtual hard drive only needs the actual space in use. My tip now would be to create a backup of the virtual hard drive, to ensure you can start over if (when) something goes wrong. You can possibly do this with snapshots in the VM, but I found it easier to know that I could always return to the original state and start over without any earlier changes spilling over.

Create a virtual machine in VirtualBox as normal and attach the virtualHd.vdi to the new VM. This is where the problems started, it refused to boot. The disk was there, it was connected, and if I booted with a live CD I could see all the files. So why didn’t it work?

I tried multiple things here, eventually took a look at it with a boot repair tool. The report told me the boot sector believed it should start reading from sector 200000 or so, while the disk in fact started at sector 0. This is where I should probably tell you that the original disk layout was a bit strange. The first partition was a rescue partition (for some reason), the second was Windows and the third a dual boot setup for Ubuntu. Since I had failed to copy the complete disk, I had settled for the Windows partition. However, it seemed that it had retained the offset caused by the first partition, so using only the second partition made it really confused.

Disk management overview of the partitions

Note that the boot repair tool was able to pin-point the issue, but despite the examples and documentation I was looking at it didn’t provide any solutions. I tried a couple of variations to re-create the MBR by overwriting it, but no matter how I tried it always messed up the partition so that no program knew exactly what partitions or file systems it contained anymore.

After banging my head against that wall for a while, it struck me that if it needed that partition layout, why not set it up that way? I had a recovery CD, created from when the laptop was new. (Seemed more like a clean install than a recovery, but that suited me even better). So the plan was: I do a recovery install in the VM, I get the same partition layout and then simply replace the second partition. This actually worked as expected. Replacing the content in the second partition was easy. I just booted the virtual machine with the newly installed hard drive, the copied hard drive and a Ubuntu live CD to move things from one to the other. As an experiment, it actually made a difference if you copy all the files or all bytes of the partition with dd. The former worked and booted, but strange dialogs popped up when logging in. It should have replaced and included all files, so I don’t really understand the issue here. However, going back and overwriting everything with raw bytes worked much better.

So I now had a clean install with a fresh partition 1 and a salvaged partition 2 copied over. The VM booted, everything was loading and I got to the login screen. A little detour here, before we get to the end: I was unable to remember my original password. I tried most likely variations and then some rather unlikely ones without any luck. While I had successfully moved the content of the disk, I was unable to access it.

I considered password cracking for a while, but that would require taking the time to brute-force it which I’d rather avoid. While looking around for how to extract the username and password hash I found that you don’t need to crack it, you can simply blank it out. This guide (while written for an older Ubuntu version) went through the details. In short terms, boot from an Ubuntu live CD, install chntpw, locate the SAM file and blank out the password for the account in question. After doing this and rebooting I was automatically logged in and shown my glorious desktop with all previously installed programs.

This is also when I discovered that if you convert a physical hard drive to a virtual one in a VM, Windows will count that as hardware change and require a license re-activation. This would be no different if I had done a clean install, but I had hoped it could be avoided by converting the existing install.

In conclusion:
Yes, this can be done: duplicate the disk content, convert it to a format the virtual machine program reads and you can plug it into a VM. Though apart from being a fun hobby project it seems easier and less time-consuming to create a fresh install and then setup the same programs and configuration. If you do decide to convert a physical disk, make sure you create an image from the whole disk instead of a single partition, as this will save you lots of hassle in the long run. You can always clean up or wipe superfluous partitions in the VM afterwards.

Ukens kommando: git clone –depth

I blant så trenger jeg å sjekke ut et repo for å gjøre mindre endringer. Hvis repoet er ganske stort (årlang historikk, utallige bildefiler og gudene vet hva) så vil mesteparten av tiden gå med til å laste ned og kverne all historikken for disse filene. Det er jo strengt tatt overflødig når jeg bare skal fikse en stavefeil, pushe fiksen og så neppe røre repoet igjen. I disse tilfellene er det kjekt å vite at du kan hoppe over mye av historikken når du kloner. F. eks. git clone --depth=10 <reponavn> vil sjekke ut repoet, men tar kun med de 10 nyeste commitene. Ved å justere på --depth-flagget kan du ta med så mye eller lite du ønsker.

Pluss: går raskt og lettvint.
Minus: hvis du skal jobbe med flere eller større endringer eller lete i historikken lønner det seg heller å klone alt. Med mesteparten av historikken kuttet vil verktøy og commit-log anta at prosjektet oppstod i den første commiten du har tilgjengelig, hvilket sannsynligvis er misvisende for hvem som har jobbet på de ulike delene av kodebasen.

Alt i alt kjekt hvis du skal pushe en rask engangs-fiks og ikke har repoet tilgjengelig fra tidligere.

PS. Bazaar har tilsvarende funksjonalitet, bzr branch --stacked <reponavn> som lager en lokal utsjekk med nyeste versjon uten lokal historikk.

apt-get update

Et kort lite tips hvis du bruker apt-get mye: hvis du bruker en relativt ny utgave av distroen din kan du sannsynligvis bruke apt istedenfor. Apt er fire tegn kortere å skrive og fungerer som forventet for alle de vanligste valgene:
apt-get updateapt update
apt-get dist-upgradeapt dist-upgrade
Som en ekstra bonus viser apt teksten i ulike farger for å indikere fremgang.

Så hvis du sitter på Ubuntu 14.04 eller nyere, kan det være kjekt å gå over til apt fremfor apt-get.

Jeg er usikker på om apt vil ta over/pakke inn all funksjonaliteten til apt-get på sikt, men inntil videre er det fortsett et par valg som kun finnes i apt-get. Det jeg har merket mest er at jeg fortsatt må kjøre apt-get autoremove, men det er ikke noe jeg gjør ofte nok til at det er plagsomt.

Ukens kommando: df -i

For en stund tilbake støtte jeg på et sært problem. Jeg forsøkte å installere noe, men Ubuntu fortalte meg at det ikke var mulig siden harddisken var full. Det hørtes veldig rart ut, siden jeg kunne se at harddisken hadde mer enn nok ledig plass. Jeg lurte på noe kanskje rapporterte feil mengde ledig plass, så jeg dobbeltsjekket med nautilus og df -h som viste de samme tallene. (For de som ikke kjenner den fra før, kommandoen df viser størrelse, brukt og ledig plass på harddiskene. Jeg bruker flagget -h for å få med benevning som er litt enklere for mennesker, feks. M for Megabyte, G for Gigabyte, så jeg slipper å regne sammen bytes selv.)

Etter å ha tenkt på hva dette kunne skyldes en stund kom jeg på inoder. Hva er en inode? Kort fortalt er en inode metadata om et område på disken. Den vil typisk inneholde informasjon om filstørrelse, eierskap, rettigheter og lignende. Hver fil eller mappe har en tilhørende inode som peker til den og holder på metainformasjonen om den.

Det jeg husket jeg hadde hørt om inoder var at det er et gitt antall av dem. Hvis man legger til mange nok (spesielt små) filer vil man før eller senere gå tom for inoder for å holde orden på disse. Denne situasjonen hørtes veldig teoretisk ut, så jeg hadde ikke tenkt over det som en reell problemstilling. Likevel, det kunne jo muligens forklare feilmeldingen jeg fikk.

Etter litt søking fant jeg ut hvordan jeg kan se hvor mange inoder som er i bruk. Det viste seg fort at df også har støtte for dette; df -i vil vise antall, brukte og ledige inoder. Maskinen som rapporterte full disk viste seg å ha mye ledig plass i Gigabytes, men kun et fåtall tilgjengelige inoder for å kunne opprette nye filer. Aha! Så varslet om full harddisk betydde i dette tilfellet egentlig for få inoder til å legge til nye filer (som jo forsåvidt betyr at den er full).

Nå som jeg visste hva problemet var, fjernet jeg fjernet en del eldre pakker som jeg ikke lenger trengte. Dette frigjorde flere inoder, som jeg verifiserte med df -i, og jeg kunne gå videre med installasjon av programmene jeg ønsket. Så hvis du får feilmeldinger om at harddisken er full, selv om det ser ut til å være mye ledig plass på den, kan det være en ide å sjekke om det er ledige inoder som er problemet.

PS. Det er ingen garantier for at dette blir en ukentlig spalte, men jeg likte navnet idet jeg skrev overskriften.

Hvordan få fine farger i git

Mange prosjekter bruker git til versjonskontroll, så de fleste utviklere har brukt det på et eller annet tidspunkt. Dessverre (og til min irritasjon) ser det ut som standardinnstillingene til git-klienten bruker samme farge på all utdata. Den har heldigvis innebygget støtte for bruk av flere farger der det er hensiktsmessig, som er noe av det første jeg slår på når jeg setter opp git på et nytt system.

Med farger får vi blant annet tydeligere markering av hvilken gren vi står på, men den viktigste fordelen er at differ (både endringer som ikke er commitet og eldre) blir fargekodet. I eksempelbildet ser vi klart hvilke linjer som er fjernet, lagt til eller forblir uendrete siden de er merket henholdsvis rødt, grønt og hvit (standard). Dette gjør det mye klarere og lettere å få oversikt sammenlignet med å manuelt forsøke å se hva som fjernes eller legges til i et sett med endringer der alle er listet med samme farge .

Eksempel på git med fargerSå som en huskelapp til meg selv og andre, kjør:

git config --global color.ui true

for å  slå på farger i git-klienten. Det er også mulig å spesifisere mer detaljert i hvilke situasjoner du ønsker farger og ikke, se dokumentasjonen for detaljer.


Hjelp, hva gjør jeg hvis en virtuell maskin bruker alt minnet mitt?

Jeg liker å kunne bruke virtuelle maskiner (fortrinnsvis Virtualbox), siden de gir meg mulighet til å teste ut forskjellige programmer eller andre ting uten at det forstyrrer oppsettet på maskinen jeg jobber på til vanlig. Dette gjør det enklere å eksperimentere mer fritt, og enklere å gå tilbake til slik det var før hvis noe går skeis.

Men, fra tid til annen, har jeg hatt problemer med at jeg har startet en virtuell maskin for mye. Enten fordi jeg hadde tenkt å se hvordan de virtuelle maskinene oppførte seg i nettverk eller rett og slett fordi jeg glemte jeg hadde andre kjørende. Særlig hvis det er lite minne (RAM), er det lett å ende opp i situasjoner hvor ting går såpass tregt at de tilsynelatende fryser vertssystemet. På dette tidspunktet er det selvfølgelig mulig å slå maskinen av og på igjen, men da mister jeg alt jeg har lagret, samt det tar ekstra tid. I tillegg er det ikke nødvendig, siden det er fullt mulig å bruke VirtualBox via kommandolinjen.

Si du kjører Ubuntu (eller en annen Linux-distro) og du nettopp har startet en ny virtuell maskin som sammen med de andre tar opp mesteparten av minnet og tilsynelatende fryser systemet dit. Trykk Ctrl+Alt+F1 for å komme til en annen virtuell terminal (hvordan du kommer tilbake igjen, tar vi for oss senere). Der vil du bli møtt av en svart skjerm med hvit skrift der du kan logge deg inn med brukernavn og passord. Etter en vellykket innlogging, vil du ha tilgang til en kommandolinje der du kan skrive inn kommandoer.

VirtualBox har en ypperlig klient for kommandolinjen som så vidt jeg vet kan gjøre alt det samme som det grafiske programmet. Kjør vboxmanage for å se alle mulighetene som er tilgjengelig. Det vi er interessert i nå er muligheten til å liste hvilke maskiner som kjører. vboxmanage list runningvms vil skrive ut en liste over de maskinene som kjører for øyeblikket. F. eks.
"maskin1" {masse-tall-og-bokstaver}
"maskin2" {masse-tall-og-bokstaver}

Vi har dermed navnene på de to maskinene som kjører. La oss si vi ønsker å pause den første, “maskin1”. Dette gjøres ved å kjøre følgende kommando: vboxmanage controlvm "maskin1" pause. Hvis du kjører vboxmanage controlvm ser du hvilke andre endringer du kan gjøre med maskinen, så lenge du oppgir navnet eller iden på maskinen der endringene skal gjøres. For å gå tilbake til det grafiske skrivebordet der vi kom fra, trykk Ctrl+Alt+F7. (Husk vi brukte Ctrl+Alt+F1 for å komme hit, og det er lignene terminaler fordelt på de forskjellige F-tastene).

Tilbake på skrivebordet bør ting fungere litt bedre siden den virtuelle maskinen som ble pauset opptar mindre av minnet i bruk. Du kan nå velge å stoppe maskinen helt, eller om du vil lukke andre programmer for å kunne kjøre ting samtidig. (Husk forøvrig at når du er ferdig bør du logge ut fra terminalen på Ctrl+Alt+F1 ved å bruke kommandoen exit.)