Attempting to install Gentoo into VirtualBox

Back

Installing Gentoo

Today I decided I'd try out a different distribution of linux than my usual. After reading through the Gentoo handback, I decided to roll with Gentoo.

Of course, I decided to try everything out first and created an image in VirtualBox and then downloaded the minimal installation of gentoo. I ran into a problem with VirtualBox, but luckily the internet had me covered.

Next up, I grabbed the signature of the iso and verified it.

$gpg --recv-keys 0xBB572E0E2D182910
gpg: requesting key 2D182910 from hkp server keys.gnupg.net
gpg: key 2D182910: public key "Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>" imported
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   7  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   7  signed:   0  trust: 7-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2018-09-18
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)

$gpg --verify install-x86-minimal-20141209.iso.DIGESTS.asc 
gpg: Signature made Tue 09 Dec 2014 07:49:09 AM EST using RSA key ID 2D182910
gpg: Good signature from "Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 13EB BDBE DE7A 1277 5DFD  B1BA BB57 2E0E 2D18 2910

I then checked that the fingerprint matched the one on the Gentoo Website and then checked that the ISO file I had downloaded matched the hash within the digest file:

$grep -A 1 -i sha512 install-x86-minimal-20141209.iso.DIGESTS.asc 
# SHA512 HASH
4d6b7e6ec411b8536221ea5a5c5e7f2d0fa766d99727a6593bcbffa0aff0409a84486306217a6c208cc8b1504c3088711838fec57e0af2c5338e90978342b7bf  install-x86-minimal-20141209.iso
--
# SHA512 HASH
bfc0384646b3b38935bd272912d56cbc10f7a05f612073023205dc2ffbf9012f8e189d1bc8c7b8afbef92e2bf336cd5e2a0693894775573f11800e7e0a48f90e  install-x86-minimal-20141209.iso.CONTENTS

sha512sum install-x86-minimal-20141209.iso
4d6b7e6ec411b8536221ea5a5c5e7f2d0fa766d99727a6593bcbffa0aff0409a84486306217a6c208cc8b1504c3088711838fec57e0af2c5338e90978342b7bf  install-x86-minimal-20141209.iso

Once done I started up VirtualBox and booted the gentoo image. On the first screen, the kernel select I accidently waited looking at it a bit too long and had to reset the VM, but then hit F1 for the kernel's list and chose gentoo. Once I had done this a happy penguin appeared in front of me and a bunch of text started flowing by.

And then it got stuck while trying to load the SATA. And sat there for a while not doing anything and being frozen.

I tried out booting with gentoo, gentoo-nofb, and gentoo-nofb nodetect and it just seemed like it was sitting and waiting. So then it was time to check if VirtualBox was stuck, a quick sudo sysdig proc.name=VirtualBox told me, no?

...
207470 22:46:34.128462638 0 VirtualBox (13696) > recvfrom fd=25(<u>) size=4096 
207471 22:46:34.128462972 0 VirtualBox (13696) < recvfrom res=-11(EAGAIN) data= tuple=NULL 
207472 22:46:34.128464051 0 VirtualBox (13696) > poll fds=20:e1 24:u1 25:u1 29:u1 18:u1 30:p1 35:u1 36:u1 timeout=0 
207473 22:46:34.128465099 0 VirtualBox (13696) < poll res=0 fds= 
207474 22:46:34.128465571 0 VirtualBox (13696) > read fd=20(<e>) size=16 
207475 22:46:34.128465881 0 VirtualBox (13696) < read res=-11(EAGAIN) data= 
207476 22:46:34.128466612 0 VirtualBox (13696) > recvfrom fd=18(<u>) size=4096 
207477 22:46:34.128466931 0 VirtualBox (13696) < recvfrom res=-11(EAGAIN) data= tuple=NULL 
207478 22:46:34.128468874 0 VirtualBox (13696) > recvfrom fd=18(<u>) size=4096 
207479 22:46:34.128469221 0 VirtualBox (13696) < recvfrom res=-11(EAGAIN) data= tuple=NULL 
207480 22:46:34.128470133 0 VirtualBox (13696) > recvfrom fd=25(<u>) size=4096 
207481 22:46:34.128470424 0 VirtualBox (13696) < recvfrom res=-11(EAGAIN) data= tuple=NULL 
207482 22:46:34.128471513 0 VirtualBox (13696) > poll fds=20:e1 24:u1 25:u1 29:u1 18:u1 30:p1 35:u1 36:u1 timeout=0 
207483 22:46:34.128472509 0 VirtualBox (13696) < poll res=0 fds= 
207484 22:46:34.128473025 0 VirtualBox (13696) > read fd=20(<e>) size=16 
207485 22:46:34.128473347 0 VirtualBox (13696) < read res=-11(EAGAIN) data= 
207486 22:46:34.128474079 0 VirtualBox (13696) > recvfrom fd=18(<u>) size=4096 
207487 22:46:34.128474410 0 VirtualBox (13696) < recvfrom res=-11(EAGAIN) data= tuple=NULL 
207488 22:46:34.128476533 0 VirtualBox (13696) > recvfrom fd=18(<u>) size=4096 
207489 22:46:34.128476845 0 VirtualBox (13696) < recvfrom res=-11(EAGAIN) data= tuple=NULL 
207490 22:46:34.128477776 0 VirtualBox (13696) > recvfrom fd=25(<u>) size=4096 
207491 22:46:34.128478073 0 VirtualBox (13696) < recvfrom res=-11(EAGAIN) data= tuple=NULL 
...

So I reset my VM and decided to enable the debug logging (something I should have done in the first place) and to tell gentoo not to bother with SATA. Running gentoo nosata debug got me to the point where it tried to scan for raid456, and then it hung.

So I reset the VM again and ran gentoo nosata noload=raid456 debug, it got farther this time, all the way to raid5. So maybe it was a problem with the raid modules themselves? I scanned the Handbook and found the option nodmraid, reset the VM and tried running gentoo nosata nodmraid debug.

This apparently wasn't what I thought it was, so I reset and started looking through the handbook again before deciding to just list the modules I didn't need. This is what I ended up with:

gentoo noload=ahci,ata_piix,raid456,raid5,raid6,btrfs,e1000 debug

After doing this, the system loaded and dropped me in on a console. My user id was 0 (whoami told me so but didn't have a name for the user). The weird thing was that my prompt complained as it dropped me on my head:

BusyBox v1.20.0 (built in shell ash)
/bin/ash: can't access tty; job control turned off
#

At this point I had to wonder what was going on, and so I checked the internet for people having the same problem, checking /dev/tty got me a permission denied message, it didn't seem like a size problem like some users experienced, but a permissions one. Running the same command without the debug option gave me the error: "making tmpfs for /newroot" and "segmentation fault" right underneath.

So something was clearly up. Looking at the Virtualbox settings, I realized the IDE controller setting was set to ahci, but wait didn't I have to say noload=ahci to get to the shell in the first place? Looking in my host system, I wondered if maybe I didn't have the drivers there, so it was having trouble with that? So I looked for clues:

$locate ahci
/lib/modules/3.2.0-23-generic/kernel/drivers/ata/acard-ahci.ko
/lib/modules/3.2.0-23-generic/kernel/drivers/ata/ahci_platform.ko
/usr/src/linux-headers-3.2.0-23/include/linux/ahci_platform.h
/usr/src/linux-headers-3.2.0-23-generic/include/config/sata/ahci
/usr/src/linux-headers-3.2.0-23-generic/include/config/sata/ahci.h
/usr/src/linux-headers-3.2.0-23-generic/include/config/sata/acard/ahci.h
/usr/src/linux-headers-3.2.0-23-generic/include/config/sata/ahci/platform.h
/usr/src/linux-headers-3.2.0-23-generic/include/linux/ahci_platform.h

Looking at the include/config directories, I noticed something important about the ahci files. Namely that they were all emtpy. Returning to the handbook, I read over the boot parameters again, trying out ide=nodma since the handbook statues:

If the system is having trouble reading from the IDE CDROM, try this option.

I also tried any options (such as nodetect) that hinted at being able to trouble shoot issues with the CDROM. Staring at the screen, I began to wonder if it wasn't the cd rom that was the problem, but the space to mount it. There was a line stating that there was a segmentation fault creating tmpfs for /newroot after all.

But all in all, no matter what settings I tried, changing the IDE to primary, to slave, to reading the init script and trying to run the mounting of the cd myself, it just didn't work.

You've beaten me for now virtualbox!

Other Posts

comments powered by Disqus