HAH! I figured it out! Apparently VirtualBox, GPT and grub2 don't mixOn 17 September 2013 22:42, Anders Ingemann <anders@ingemann.de> wrote:
> On 17 September 2013 15:46, olivier sallou <olivier.sallou@gmail.com> wrote:
>>
>>
>>
>> 2013/9/17 Anders Ingemann <anders@ingemann.de>
>>>
>>> > 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 <olivier.sallou@gmail.com>
>>> wrote:
>>> >
>>> >
>>> >
>>> > 2013/9/16 Anders Ingemann <anders@ingemann.de>
>>> >>
>>> >> Hey guys
>>> >>
>>> >> I posted to help-grub@gnu.org, 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 debian-cloud-request@lists.debian.org
>>> >> with a subject of "unsubscribe". Trouble? Contact
>>> >> listmaster@lists.debian.org
>>> >> Archive:
>>> >>
>>> >> [🔎] CAMcOGXFiLv2+WQ3fXe87wGv6ihs8eTfQBejqb4Vuof99OnrzZg@mail.gmail.com" target="_blank">http://lists.debian.org/[🔎] CAMcOGXFiLv2+WQ3fXe87wGv6ihs8eTfQBejqb4Vuof99OnrzZg@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
(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