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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/camcogxg4myvjpp11j677fdkvw3zd5vpnroaxxgmddee5gd3...@mail.gmail.com
