[gentoo-amd64] grub and glibc won't build on my new install

[gentoo-amd64] grub and glibc won't build on my new install

[Randy Barlow]

Howdy! I'm trying to perform a Gentoo install in a VM (KVM), and I seem
to have a problem building grub.  It fails in the configure process like
this:

checking for i686-pc-linux-gnu-gcc... (cached) x86_64-pc-linux-gnu-gcc -m32
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: in
`/var/tmp/portage/sys-boot/grub-0.97-r9/work/grub-0.97':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.

I thought that was pretty odd. I also discovered that glibc won't build
correctly, with this:

make[2]: ***
[/var/tmp/portage/sys-libs/glibc-2.10.1-r1/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/xbootparam_prot.stmp]
Illegal instruction
make[2]: *** Waiting for unfinished jobs....
mkdir
/var/tmp/portage/sys-libs/glibc-2.10.1-r1/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcsvc
CPP='x86_64-pc-linux-gnu-gcc -E -x c-header'
/var/tmp/portage/sys-libs/glibc-2.10.1-r1/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/ld-linux.so.2
--library-path
/var/tmp/portage/sys-libs/glibc-2.10.1-r1/work/build-x86-x86_64-pc-linux-gnu-nptl:/var/tmp/portage/sys-libs/glibc-2.10.1-r1/work/build-x86-x86_64-pc-linux-gnu-nptl/math:/var/tmp/portage/sys-libs/glibc-2.10.1-r1/work/build-x86-x86_64-pc-linux-gnu-nptl/elf:/var/tmp/portage/sys-libs/glibc-2.10.1-r1/work/build-x86-x86_64-pc-linux-gnu-nptl/dlfcn:/var/tmp/portage/sys-libs/glibc-2.10.1-r1/work/build-x86-x86_64-pc-linux-gnu-nptl/nss:/var/tmp/portage/sys-libs/glibc-2.10.1-r1/work/build-x86-x86_64-pc-linux-gnu-nptl/nis:/var/tmp/portage/sys-libs/glibc-2.10.1-r1/work/build-x86-x86_64-pc-linux-gnu-nptl/rt:/var/tmp/portage/sys-libs/glibc-2.10.1-r1/work/build-x86-x86_64-pc-linux-gnu-nptl/resolv:/var/tmp/portage/sys-libs/glibc-2.10.1-r1/work/build-x86-x86_64-pc-linux-gnu-nptl/crypt:/var/tmp/portage/sys-libs/glibc-2.10.1-r1/work/build-x86-x86_64-pc-linux-gnu-nptl/nptl
/var/tmp/portage/sys-libs/glibc-2.10.1-r1/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcgen
-Y ../scripts -h rpcsvc/bootparam_prot.x -o
/var/tmp/portage/sys-libs/glibc-2.10.1-r1/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcsvc/bootparam_prot.T
make[2]: ***
[/var/tmp/portage/sys-libs/glibc-2.10.1-r1/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcsvc/bootparam_prot.stmp]
Illegal instruction
make[2]: Leaving directory
`/var/tmp/portage/sys-libs/glibc-2.10.1-r1/work/glibc-2.10.1/sunrpc'
make[1]: *** [sunrpc/others] Error 2

I'm wondering what is going on. Is it a problem of 64 bit vs. 32 bit?
The dom0 is 64-bit Gentoo, and things look OK to my in my emerge --info:

(chroot) livecd / # emerge --info
Portage 2.1.6.13 (default/linux/amd64/10.0, gcc-4.3.4,
glibc-2.9_p20081201-r2, 2.6.31-gentoo-r6 x86_64)
=================================================================
System uname:
Linux-2.6.31-gentoo-r6-x86_64-QEMU_Virtual_CPU_version_0.12.1-with-gentoo-1.12.13
Timestamp of tree: Sat, 16 Jan 2010 23:00:01 +0000
app-shells/bash:     4.0_p35
dev-lang/python:     2.6.4
sys-apps/baselayout: 1.12.13
sys-apps/sandbox:    1.6-r2
sys-devel/autoconf:  2.63-r1
sys-devel/automake:  1.9.6-r2, 1.10.2
sys-devel/binutils:  2.18-r3
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.6b
virtual/os-headers:  2.6.27-r2
ACCEPT_KEYWORDS="amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe -fomit-frame-pointer -march=core2"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d
/etc/fonts/fonts.conf /etc/gconf /etc/sandbox.d /etc/terminfo
/etc/udev/rules.d"
CXXFLAGS=""
DISTDIR="/usr/portage/distfiles"
FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox
sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="ftp://chi-10g-1-mirror.fastsoft.net/pub/linux/gentoo/gentoo-distfiles/
"
LDFLAGS="-Wl,-O1"
LINGUAS="en en_US"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times
--compress --force --whole-file --delete --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="64bit acl additions amd64 apache2 authdaemond avahi bash-completion
berkdb branding bzip2 caps cddb cdparanoia cdr cli courier cpudetection
cracklib crypt cups cxx dbus dcraw dri exif fam fortran ftp gd gdbm gpm
hal iconv id3tag imap java kpathsea mmx modules mudflap multilib mysql
ncurses netpbm nls nptl nptlonly openmp pam pcre perl php postfix
postscript ppds pppd python quotes readline reflection regex replytolist
samba sasl session slp spamassassin spl sse sse2 ssl
startup-notification subversion symlink sysfs tcpd tetex tk tokenizer
unicode unzip vditool vim-syntax xorg zip zlib" ALSA_CARDS="ali5451
als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371
es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident
usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw
asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug
ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route
share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias
authn_anon authn_dbm authn_default authn_file authz_dbm authz_default
authz_groupfile authz_host authz_owner authz_user autoindex cache dav
dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache
filter headers include info log_config logio mem_cache mime mime_magic
negotiation rewrite setenvif speling status unique_id userdir usertrack
vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev"
KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216
lcdm001 mtxorb ncurses text" LINGUAS="en en_US" RUBY_TARGETS="ruby18"
USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga neomagic nv
r128 radeon savage sis tdfx trident vesa via vmware voodoo"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK,
LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS,
PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY

This is very strange to me, so if anybody can give me a pointer, I'd be
very appreciative!

[gentoo-amd64] Re: grub and glibc won't build on my new install

[Duncan]

Randy Barlow posted on Mon, 18 Jan 2010 16:39:07 -0500 as excerpted:

> Howdy! I'm trying to perform a Gentoo install in a VM (KVM), and I seem
> to have a problem building grub.  It fails in the configure process like
> this:
> 
> checking for i686-pc-linux-gnu-gcc... (cached) x86_64-pc-linux-gnu-gcc
> -m32 checking for C compiler default output file name... a.out checking
> whether the C compiler works... configure: error: in
> `/var/tmp/portage/sys-boot/grub-0.97-r9/work/grub-0.97': configure:
> error: cannot run C compiled programs. If you meant to cross compile,
> use `--host'.
> 
> I thought that was pretty odd. I also discovered that glibc won't build
> correctly, with this:

That's classic screwed-up-32-bit symptoms.  Your primary 64-bit toolchain 
is fine, so most things compile fine, but the 32-bit toolchain is 
screwed, so anything attempting to use it fails.  Grub is of course 32-
bit, so it's failing.  glibc compiles for both bitnesses, so the 32-bit 
side of it is failing.  If I'm not mistaken, you'll likely find that gcc 
won't build either, because it too compiles dual bitnesses.

There are a number of reasons this might have happened.  You mention that 
this is a new install, which should eliminate some of the historical 
ones.  Your current profile looks good (it's a current 10th anniversary 
amd64 profile and isn't no-multilib), but you didn't mistakenly try a no-
multilib version and compile some bits of the toolchain, did you?

gcc 4.3.4... should be fine.  I know of no issues with glibc.

Hmm, kernel config!  You have 32-bit executable format turned on in the 
kernel, right?  That's under Executable file formats / Emulations, IA32 
Emulation.  (It's not emulation, but anyway...)  If that's it, you're not 
the first one that's messed up, and probably won't be the last, either.

I haven't messed with VMs here (my machine doesn't have the hardware 
extensions, and I haven't particularly needed a slower software-only a VM 
for anything, so...), so I know not what if any options may need enabled 
there, in either the host or the VM.  If it's related to that, you'll 
need to find help from someone else.

One other possibility to try is FEATURES=-sandbox emerge sandbox.  
Multilib profiles include sandboxing libs for both 32-bit and 64-bit as 
well, and sometimes it's simply the 32-bit side of that which gets 
screwed up.  Of course, building sandbox requires 32-bit as well, but if 
it's just the 32-bit sandbox libs that are screwed,t then bypassing them 
to remerge sandbox itself will work, and hopefully the newly built 
sandbox will be functional.  If that fails with 32-bit errors as well, 
the problem is deeper in your toolchain, likely a screwed-up 32-bit gcc, 
or possibly a screwed-up 32-bit glibc.  It can also be binutils.

If it's not sandbox and not kernel, particularly since you're just fresh 
installing, it's probably best to extract the stage tarball in a temp dir 
somewhere, chroot into it, and quickpkg gcc, glibc, binutils, and 
sandbox.  That will give you binpkgs of the stage tarball versions of 
those packages.  Back out of that temp chroot again, you can
emerge --usepkgonly the binpkgs you just created, thus getting back a 
working toolchain including 32-bit again.  (You can try one at a time and 
then test, to figure out what broke, or just do them all, then rebuild 
them later.)  Using that toolchain, you should be able to rebuild the 
packages you binpkg installed from the stage tarball, and get back on 
track.

Given the automated stage tarball building process gentoo uses these 
days, it's narrowly possible the current tarball is somehow screwed, too, 
and the binpkgs you create from it won't solve the problem.  That is 
quite unlikely, but narrowly possible.  If that turns out to be the case, 
you can try a tarball from a week or two ago, and hopefully it'll work 
better.  If it too gives problems, then it's likely something you're 
doing wrong.  In either case, when it gets to this stage it's time to 
file a bug and get someone who knows a bit more about the intricacies of 
multilib toolchains involved.

(FWIW, I run a no-multilib profile and have for a couple years now, I 
think, but I also use a 32-bit chroot, generally following the gentoo/
amd64 32-bit chroot guide but with a few changes since I'm making a fully 
bootable but not on that machine image, to compile the x86 gentoo image I 
use on my netbook.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: grub and glibc won't build on my new install

[Randy Barlow]

Duncan wrote:
> Your current profile looks good (it's a current 10th anniversary 
> amd64 profile and isn't no-multilib), but you didn't mistakenly try a no-
> multilib version and compile some bits of the toolchain, did you?

Hey Duncan, thanks for the amazingly rapid reply! I'm just now getting 
around to trying some of this out (busy work week!) I definitely didn't 
choose the no-multilib tool chain itself, but I did try out the "server" 
[rofile. Was that potentially my mistake (i.e., is the "server" profile 
non-multilib?)

> Hmm, kernel config!  You have 32-bit executable format turned on in the 
> kernel, right?  That's under Executable file formats / Emulations, IA32 
> Emulation.  (It's not emulation, but anyway...)  If that's it, you're not 
> the first one that's messed up, and probably won't be the last, either.

Well, I'm on the livecd. I assume that the live CD kernel has the 32-bit 
format enabled, otherwise how would you do what I'm trying to do? I did 
build 32-bit into the kernel that I made, but I haven't booted into that 
kernel yet since I can't build grub :)

> I haven't messed with VMs here (my machine doesn't have the hardware 
> extensions, and I haven't particularly needed a slower software-only a VM 
> for anything, so...), so I know not what if any options may need enabled 
> there, in either the host or the VM.  If it's related to that, you'll 
> need to find help from someone else.

I'd be surprised if this has something to do with virtualization, but 
hey, you could be right!

> One other possibility to try is FEATURES=-sandbox emerge sandbox.  
> Multilib profiles include sandboxing libs for both 32-bit and 64-bit as 
> well, and sometimes it's simply the 32-bit side of that which gets 
> screwed up.  Of course, building sandbox requires 32-bit as well, but if 
> it's just the 32-bit sandbox libs that are screwed,t then bypassing them 
> to remerge sandbox itself will work, and hopefully the newly built 
> sandbox will be functional.  If that fails with 32-bit errors as well, 
> the problem is deeper in your toolchain, likely a screwed-up 32-bit gcc, 
> or possibly a screwed-up 32-bit glibc.  It can also be binutils.

Unfortunately, an emerge -e world fails, which should build gcc, glibc, 
and binutils in the correct order. I'll give the sandbox trick a whirl.

Thanks for the reply, and I'll be sure to keep the list updated with my 
findings!

Re: [gentoo-amd64] Re: grub and glibc won't build on my new install

[Randy Barlow]

Randy Barlow wrote:
> I'll give the sandbox trick a whirl.

Well, that turned out to be kind of hilarious:

(chroot) livecd / # FEATURES=-sandbox emerge sandbox
Calculating dependencies... done!

 >>> Verifying ebuild manifests

 >>> Emerging (1 of 1) sys-apps/sandbox-1.6-r2
openpty failed: 'out of pty devices'
  * sandbox-1.6.tar.lzma RMD160 SHA1 SHA256 size ;-) ... 
   [ ok ]
  * checking ebuild checksums ;-) ... 
   [ ok ]
  * checking auxfile checksums ;-) ... 
   [ ok ]
  * checking miscfile checksums ;-) ... 
   [ ok ]
 >>> Unpacking source...
 >>> Unpacking sandbox-1.6.tar.lzma to 
/var/tmp/portage/sys-apps/sandbox-1.6-r2/work
  * Applying sandbox-1.6-disable-qa-static.patch ... 
    [ ok ]
  * Applying sandbox-1.6-disable-pthread.patch ... 
    [ ok ]
  * Applying 0001-libsandbox-handle-more-at-functions.patch ... 
    [ ok ]
 >>> Source unpacked in /var/tmp/portage/sys-apps/sandbox-1.6-r2/work
 >>> Compiling source in 
/var/tmp/portage/sys-apps/sandbox-1.6-r2/work/sandbox-1.6 ...
  * Configuring sandbox for ABI=x86...
  * econf: updating sandbox-1.6/config.sub with 
/usr/share/gnuconfig/config.sub
  * econf: updating sandbox-1.6/config.guess with 
/usr/share/gnuconfig/config.guess
../sandbox-1.6//configure --prefix=/usr --build=i686-pc-linux-gnu 
--host=i686-pc-linux-gnu --mandir=/usr/share/man 
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc 
--localstatedir=/var/lib --libdir=/usr/lib32
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for i686-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc -m32
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: in 
`/var/tmp/portage/sys-apps/sandbox-1.6-r2/work/build-x86':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.

!!! Please attach the following file when seeking support:
!!! /var/tmp/portage/sys-apps/sandbox-1.6-r2/work/build-x86/config.log
  *
  * ERROR: sys-apps/sandbox-1.6-r2 failed.
  * Call stack:
  *               ebuild.sh, line   49:  Called src_compile
  *             environment, line 2625:  Called econf
  *               ebuild.sh, line  534:  Called die
  * The specific snippet of code:
  *   			die "econf failed"
  *  The die message:
  *   econf failed
  *
  * If you need support, post the topmost build error, and the call 
stack if relevant.
  * A complete build log is located at 
'/var/tmp/portage/sys-apps/sandbox-1.6-r2/temp/build.log'.
  * The ebuild environment file is located at 
'/var/tmp/portage/sys-apps/sandbox-1.6-r2/temp/environment'.
  *
  * If configure failed with a 'cannot run C compiled programs' error, 
try this:
  * FEATURES=-sandbox emerge sandbox

I love how the package itself tells me to try the very command I did 
try. Anyways, perhaps I should just extract another snapshot over this 
one...

[gentoo-amd64] Re: grub and glibc won't build on my new install

[Duncan]

Randy Barlow posted on Fri, 22 Jan 2010 23:41:05 -0500 as excerpted:

> Randy Barlow wrote:
>> I'll give the sandbox trick a whirl.
> 
> Well, that turned out to be kind of hilarious:

>   * If configure failed with a 'cannot run C compiled programs' error,
> try this:
>   * FEATURES=-sandbox emerge sandbox
> 
> I love how the package itself tells me to try the very command I did
> try.

Yeah... That's a known issue, with that as one of the common fixes, so 
they mention it.  Obviously they don't check the feature set when output 
that, tho.

> Anyways, perhaps I should just extract another snapshot over this
> one...

That sounds like a good idea.  The toolchain is obviously broken, and 
extracting a new stage tarball over top is one way to fix it.

When you retry, keep track of what packages are installed and if you get 
that problem, which of the toolchain packages (gcc and glibc especially) 
was installed last.  That's going to be the problem package.  If they're 
all still what was on the stage tarball, then it's gotta be it.

Meanwhile, to make things easier if something like this happens when you 
have the system up and running normally, you may wish to set 
FEATURES=buildpkg (and set PKGDIR appropriately if you don't like the 
default).  That way, as you build packages, they'll get binpkged as 
well.  Over time, you'll build up multiple versions of most packages, and 
if one breaks, it's easy enough to revert using emerge --usepkgonly =pkg-
version.  That way, a broken gcc won't matter as you can just remerge an 
older, working version.  If the problem is portage or python, so emerge 
itself is broken, since the binpkgs are simple tarballs with extra 
metadata tacked on the end, you can simply extract the tarball directly 
over the live filesystem if you have to (but be sure to move config files 
out of the way first, so they don't get overwritten by the defaults in 
the pkg tarball, then move them back).  Of course, portage won't know 
about it then, so once it's working again, the first thing you'll want to 
do is remerge the version you just extracted, thus updating the package 
database so it knows what's installed.  If you put PKGDIR on its own 
filesystem, 4 gigs or so is a reasonable size, giving you room to keep 
multiple copies of your packages without having to clean out the old ones 
too often.

Anyway... hassles with 32-bit, and the fact that I don't run 
proprietaryware and all the FLOSS I run had been long ported to amd64 
anyway, were the reason I finally decided a couple years ago to go no-
multilib.

Generally, the only reason to run multilib is proprietary binary-only
32-bit-only packages such as games, codecs, and possibly other legacy 
software, and codecs, flash, etc, are more and more available for 64-bit 
anyway, if you /do/ choose to run proprietary, so the reasons to hassle 
32-bit multilib are becoming fewer and fewer.  Meanwhile, the benefits to 
going multilib include leaving the hassle of keeping a working 32-bit 
toolchain behind, and halving your gcc and glibc compile time because 32-
bit doesn't need built.  For me, that was an easy choice to make, and one 
I haven't regretted.  I only wished I had made it sooner! =:^)

And, FWIW, it's always possible to do the 32-bit chroot thing using the 
Gentoo guide for it, and compile your own separately tracked 32-bit 
system.  Actually, that's what I did when I setup my netbook with Gentoo, 
using a 32-bit chroot to setup an image on my main machine, since it's so 
much more powerful, then transferring the image to the netbook.  I'm 
using rsync to keep the images synced, now.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: grub and glibc won't build on my new install

[Randy Barlow]

Randy Barlow wrote:
> Anyways, perhaps I should just extract another snapshot over this
> one...

Man, I'm getting frustrated now. I just went and got the latest stage 3,
and it still fails to install grub with the same problem. I don't really
need the multilib setup, so I suppose I will try to no-multilib profile,
but it is frustrating that this won't work for me. Thanks for the help
Duncan, and I'll post back when I get it all running. This is my first
KVM Gentoo setup...

[gentoo-amd64] Re: grub and glibc won't build on my new install

[Duncan]

Randy Barlow posted on Sat, 23 Jan 2010 17:12:48 -0500 as excerpted:

> Man, I'm getting frustrated now. I just went and got the latest stage 3,
> and it still fails to install grub with the same problem. I don't really
> need the multilib setup, so I suppose I will try to no-multilib profile,
> but it is frustrating that this won't work for me. Thanks for the help
> Duncan, and I'll post back when I get it all running. This is my first
> KVM Gentoo setup...

Note that there's also grub-static, which is what is used if you run no-
multilib and thus can't compile grub.  Grub-static is basically a 
binpkged version of grub, that they ship pre-built, for those 64-bit-only 
folks who don't have a 32-bit compiler to build grub with.

If you're on the fence about multilib, try grub-static first.

(Actually, the thought occurs to me that I'm not sure how VMs boot, do 
they need grub at all, or can the host load the kernel into the VM 
directly and set it running, in effect functioning as the boot-loader?  
Or maybe they use something like the DOS based loadln?  I don't know.  
But presumably you're following a HOWTO of some kind and it says use 
grub?)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: grub and glibc won't build on my new install

[Randy Barlow]

Randy Barlow wrote:
> Man, I'm getting frustrated now. I just went and got the latest stage 3,
> and it still fails to install grub with the same problem. I don't really
> need the multilib setup, so I suppose I will try to no-multilib profile,
> but it is frustrating that this won't work for me. Thanks for the help
> Duncan, and I'll post back when I get it all running. This is my first
> KVM Gentoo setup...

No-multilib worked, so long as I used grub-static instead of normal
grub. But then grub wouldn't work with my virtio disk. Virtio is marked
"experimental" in the kernel, but I figured I would use it since it's
supposed to be faster. I might need to rethink that for now, because
grub wouldn't install to vda, and didn't seem to think there were any
physical disks at all.