By the way, your modifications will impact in the same way the kvm provider that uses the same grub stuff than virtualbox, with the virtio stuff ni addition (device switch from /dev/sda to /dev/vda if virtio is activated)
Once your updates are done, I can test on kvm with and without virtio support. Olivier 2013/9/18 Anders Ingemann <[email protected]> > On 17 September 2013 22:42, Anders Ingemann <[email protected]> wrote: > > On 17 September 2013 15:46, olivier sallou <[email protected]> > wrote: > >> > >> > >> > >> 2013/9/17 Anders Ingemann <[email protected]> > >>> > >>> > The virtualbox provider in python branch worked fine at booting the > >>> > first bootable disk with grub installed via the loopback. > >>> Honestly, I was never able to get it to work. I think it failed > >>> exactly because it was a loopback device. Can you send a manifest that > >>> reproduces your setup? Maybe I can work my way up from there. > >>> > did you use grub2 on host machine ? grub1 fails to install over > loopback > >>> > device and lead to boot error (can't find grub). > >>> Exactly, which is why I am using dmsetup to fake a real hdd, so grub > >>> installs without a hitch :-). > >> > >> > >> I am using grub2 on my computer, it manages correctly the install over > >> loopback. > >> Being able to use grub1 would be perfect, but I do not know how to make > it > >> worked. I tried many things to get grub working, but it only worked > when I > >> used grub2 :-( > >>> > >>> > >>> > >>> > >>> > did you look also at your generated device.map and grub.cfg files ? > >>> Yes, everything seems fine, I'll have another look though (the config > >>> is in the pastebin I provided) > >>> > >>> > I know that while trying to setup grub stuff etc... for kvm and > >>> > virtualbox I had issues with auto-generated grub.cfg using loopback > devices > >>> > instead of using disk devices (see loopback keywork in grub.cfg). > >>> Yes, I circumvent that by making the fake hdd, although maybe there is > >>> some leftover in the grub.cfg... I'll check it out. > >>> > >>> > I also used disk device (/dev/sda for example) instead of disk uuids > in > >>> > boot menu setup of grub (disk uuids may not be the same when booting > on your > >>> > final host). > >>> Actually. They will be exactly the same, I even have problems when > >>> attaching two disks created by the same snapshot because VBox doesn't > >>> like duplicate UUIDs. At the very least the partition UUIDs will be > >>> the same (which is what I use in fstab). > >>> > >>> Anders > >>> > >>> > >>> On 17 September 2013 08:13, olivier sallou <[email protected]> > >>> wrote: > >>> > > >>> > > >>> > > >>> > 2013/9/16 Anders Ingemann <[email protected]> > >>> >> > >>> >> Hey guys > >>> >> > >>> >> I posted to [email protected], asking for help to figure out why my > >>> >> VirtualBox image is stuck at "GRUB loading.". I thought that it > might > >>> >> be more relevant over there, but maybe you guys have some ideas as > >>> >> well. > >>> > > >>> > did you look also at your generated device.map and grub.cfg files ? > >>> > > >>> > I know that while trying to setup grub stuff etc... for kvm and > >>> > virtualbox I > >>> > had issues with auto-generated grub.cfg using loopback devices > instead > >>> > of > >>> > using disk devices (see loopback keywork in grub.cfg). > >>> > > >>> > I also used disk device (/dev/sda for example) instead of disk uuids > in > >>> > boot > >>> > menu setup of grub (disk uuids may not be the same when booting on > your > >>> > final host). > >>> > > >>> > Olivier > >>> > > >>> >> > >>> >> Here's the link to the mailing list: > >>> >> http://lists.gnu.org/archive/html/help-grub/2013-09/threads.html(not > >>> >> a direct link, mailman seems to take its time indexing my post) > >>> >> ...and here's what I wrote > >>> >> --------------------------- > >>> >> Hello everybody > >>> >> > >>> >> I am developing the debian bootstrapper "build-debian-cloud" > >>> >> (https://github.com/andsens/build-debian-cloud) and am having some > >>> >> trouble getting grub to boot my debian installation. > >>> >> Since I bootstrap from a host system (with chroot etc.) I had to use > >>> >> some workarounds to get grub installed onto a loopback device > >>> >> (http://ebroder.net/2009/08/04/installing-grub-onto-a-disk-image/). > >>> >> > >>> >> The setup consists of a vdi image partitioned with GPT into boot, > >>> >> root, swap (in that order). > >>> >> I am unable to get past the "GRUB loading." message when booting the > >>> >> image in VirtualBox. > >>> >> > >>> >> I have a hard time figuring out what is wrong with the setup, > >>> >> especially because the scenario is a bit off the beaten path > (mounting > >>> >> vdi as an network block device, bootstrapping, using dmsetup to > fake a > >>> >> real hdd etc.). So the usual "just run BootRepair" or "reinstall > grub" > >>> >> won't really help to create a stable bootstrapping process. > >>> >> I have run Ubuntus Boot Repair system to check if anything was > wrong, > >>> >> but I can't seem to find anything. The output is here: > >>> >> http://paste.ubuntu.com/6115737/ > >>> >> > >>> >> The setup can be fully reproduced by cloning my repo and running > >>> >> `./build-debian-cloud manifests/virtualbox.manifest.json` (only > tested > >>> >> on debian wheezy). > >>> >> Simply create a new virtual machine in VBox, attach the resulting > >>> >> image and boot it. > >>> >> > >>> >> I would appreciate any help you can offer > >>> >> Anders Ingemann > >>> >> --------------------------- > >>> >> > >>> >> > >>> >> -- > >>> >> To UNSUBSCRIBE, email to [email protected] > >>> >> with a subject of "unsubscribe". Trouble? Contact > >>> >> [email protected] > >>> >> Archive: > >>> >> > >>> >> > http://lists.debian.org/camcogxfilv2+wq3fxe87wgv6ihs8etfqbejqb4vuof99onr...@mail.gmail.com > >>> >> > >>> > > >>> > > >>> > > >>> > -- > >>> > > >>> > gpg key id: 4096R/326D8438 (keyring.debian.org) > >>> > > >>> > Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 > >> > >> > >> > >> > >> -- > >> > >> gpg key id: 4096R/326D8438 (keyring.debian.org) > >> > >> Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 > > > > OK, having done a bit of research, I feel like I need to clear some > > stuff up, so we avoid any further confusion. I *think* I am getting > > this right, please correct me if I am wrong. > > > >> I am using grub2 on my computer, it manages correctly the install over > loopback. > >> Being able to use grub1 would be perfect, but I do not know how to make > it worked. I tried many things to get grub working, but it only worked when > I used grub2 :-( > > This is the main point that got me confused. The bootstrapper doesn't > > install grub1 on virtualbox and never has. It has always been grub2, > > debian switched to grub2 quite a while ago (since squeeze: > > https://wiki.debian.org/Grub). I am a bit puzzled as to how you > > managed to install the bootloader since grub2 gets all confused about > > loopback devices, which is why I haven't been able to install grub2 > > with neither your virtualbox version nor mine (yet :-) ). > > Are you sure you didn't accidentally test the wrong image after you > > bootstrapped? > > > > There is one exception to the use of grub1. We need it on EC2 because > > of the paravirtualized (PV) nature of the system. Here the grub > > bootloader is not actually installed to the volume, but rather > > launched from outside the box. That special version of grub then looks > > into the volume and parses the menu.lst file. > > menu.lst is the way grub1 figured out where the inital ram disk > > (initrd) was. The EC2 PV bootloader hasn't been updated yet and can > > therefore not parse the newer grub2 grub.cfg file. > > To that end we create a special grub2 configuration generation script > > which mimicks the old menu.lst layout. This config is then outputted > > by `update-grub` to /boot/grub/grub.cfg, which my bootloader symlinks > > to /boot/grub/menu.lst where PV-Grub (http://wiki.xen.org/wiki/PvGrub) > > can find it. > > Bonus info: This is what Charles Plessy has been working on with the > > "pv-grub-menu" package. Once that is working and packaged we don't the > > special grub2 config files any longer, because the tool generates that > > file. > > > > Now... on virtualbox _we don't need that workaround_. VirtualBox > > generates a full environment for grub to actually load. Meaning vbox > > couldn't care less about what the grub.cfg or menu.lst looks like. > > > > OK, so that was a bit of a tangent. I also want to report back what I > > have figured out so far. > > > > I am fairly certain that my grub.cfg is wrong, it has a `set > > root='/dev/mapper/vdb'`, which surely is not what grub sees at boot, > > mostly because '/dev/mapper' is only used by kpartx and lvm. Then > > again, what would root be set to when you boot from an lvm partitioned > > volume??? > > When I change that line to `set root='/dev/sda1'` it still does not > > work. But at this point I figured out that my partitioning may be a > > bit wrong, the boot partition started at sector 0 instead of the usual > > 1MiB mark. Also, I used MB for partition sizes not MiB, meaning my > > 1024MB volume suddenly grew to 1074MB. > > > > There is another issue about grub not being able to figure out where > > the partitions are located on the volume. I am pretty sure however > > that this can be fixed with a proper device.map (btw. the device.map > > file is not read at boot, it is used by the grub tools to figure out > > how to make the grub.cfg file work). > > > > I believe grub should map hd0 as /dev/sda at boot, however even when I > > try to set root to (hd0,gpt1) it still does not work. > > > > Again, if anybody finds an error with what I have written, please > > chime in, I would appreciate it. > > > > > > Anders Ingemann > > HAH! I figured it out! Apparently VirtualBox, GPT and grub2 don't mix > (though there seems to be a way: > https://bbs.archlinux.org/viewtopic.php?id=148145). > I implemented MBR partitioning and the stuff worked almost out of the box. > > I figured something else out as well. Don't worry too much about what > grub sets root to in the `set root=` statements, my cfg currently runs > with `set root=/dev/mapper/vdb`, which is totally wrong at boot time. > The magic lies in the line immediately after that: > set root='(/dev/mapper/vdb,msdos2)' > search --no-floppy --fs-uuid --set=root > d0c70a21-5c67-44d1-9de2-231d00f15d5b > grub only uses the `set root` as a fallback if it can't find the > partition by UUID. > > So. About the GPT partitioning, drobole over at archlinux writes: > > If you are creating a GPT partition table, and you are installing grub2, > you might want to try this: > > Make a 2 MB partition at the beginning of the disk for grub-bios (no > filesystem is necessary) > > Do this after finishing manual partitioning (Assuming sda is the install > disk and sda1 is the 2 MB bios partition) > > # parted /dev/sda set 1 boot on > > Add this to your arch installation procedure > > # pacstrap /mnt grub-bios > > This has been working for me anyway... > > Anyone know what *exactly* pacstrap is? It seems to be some kind of > bootloader installer. Is there an equivalent for debian? > Same question goes for grub-bios. > -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
