On 10 July 2014 10:35, Juerg Haefliger <[email protected]> wrote: > > > > On Thu, Jul 10, 2014 at 9:35 AM, Anders Ingemann <[email protected]> > wrote: > > > > On 10 July 2014 08:52, Juerg Haefliger <[email protected]> wrote: > >> > >> > >> > >> > >> On Wed, Jul 9, 2014 at 9:29 PM, Anders Ingemann <[email protected]> > wrote: > >> > > >> > On 9 July 2014 21:09, Tomasz Rybak <[email protected]> wrote: > >> >> > >> >> Hello everyone. > >> >> I've been trying to understand what is going on when we try > >> >> to build HVM Wheezy image using GRUB 1.99 on GRUB 1.99. > >> >> > >> >> The host is run from /dev/xvda (PVM with pvgrub). > >> >> It contains following entries in /boot/grub/device.map > >> >> (hd0) /dev/xvda > >> >> (hd1) /dev/xvdf > >> >> IMO it is left-over from creation of AMI; xvda is from > >> >> host, xvdf is from AMI - and now what was xvdf during AMI > >> >> creation is xvda when this AMI is run. > >> >> > >> >> Target (chroot) contains following entries in device.map > >> >> (hd0) /dev/xvdf > >> >> (hd0,msdos1) /dev/mapper/xvdf1 > >> >> This might be the first source of problems; when I run > >> >> grub-install with --recheck, it created device.map > >> >> like in the first case (in host). > >> >> > >> >> /dev/mapper/xvdf1 points to /dev/dm-0. It points > >> >> to it from the very beginning, it is set by kpartx -as > >> >> Neither link_fn() nor unlink_fn() from common.tasks.boot.InstallGrub > >> >> are called. > >> >> Similarly, neither _before_link_dm_node nor _before_unlink_dm_node > >> >> from base.fs.volume.Volume are called. > >> >> > >> >> /etc/fstab on target contains UUID, not /dev/mapper/xvdf1 > >> >> for root partition. I've tried changing that, but it did not help. > >> >> > >> >> >From my point of view, this is rather messy. > >> >> * we have target / mounted to /dev/mapper/xvdf1, while > >> >> there exists /dev/xvdf1. > >> >> * /etc/fstab uses UUID > >> >> * grub-install is called with /dev/xvdf > >> >> * but later grub puts UUIDs into grub.cfg in root=* > >> >> > >> >> OTOH setting DISABLE_LINUX_UUID in grub configuration does not change > >> >> anything. > >> >> > >> >> I've found GRUB bug related to UUIDs but I am not sure whether > >> >> it is related to our case or not: > >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741342 > >> >> > >> >> I also tried fix proposed in > >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544577#10 > >> >> but it didn't help. > >> >> > >> >> Currently I feel lost with all of this. > >> >> > >> >> Maybe time will help - it looks like GRUB from Jessie does > >> >> not have those problems ;-). OTOH now Debian stable cannot be run > >> >> on the new cheep (or free) machines like t2 which use HVM. > >> >> > >> >> Best regards. > >> >> > >> >> -- > >> >> Tomasz Rybak GPG/PGP key ID: 2AD5 9860 > >> >> Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 > >> >> http://member.acm.org/~tomaszrybak > >> >> > >> > > >> > Nice job analyzing Tomasz. I am glad I'm not the only one looking at > this, I thought I was going completely insane and that there had to be > something simple I missed. It seems like that is not the case. > >> > I completely agree with you regarding the mix and matching of UUIDs > and devpaths, it should be cleaned up at some point. And I feel that work > would become easier once there is an automated way of building, booting and > testing. > >> > >> > >> Is there ongoing work for this (automated builiding/booting/testing)? > >> > >> ...Juerg > >> > > > > Yes, definitely. The latest commits have been in preparation for that. > > Is that work/process documented anywhere? What are the plans? What images > will be produced and how? What packages will they contain? How are they > configured and tested and distributed? What's the build cadence and update > strategy? > Sorry for bombarding you with all these questions but I've been thinking > about how to get this going (Debian building official cloud images) and in > fact just scheduled a open discussion at the next DebConf to talk about > this. > > How can I help? > > ...Juerg > > > > Whoa. That's a lot of really good questions. I'll try answering them to the best of my abilities.
> Is that work/process documented anywhere? Regarding the actual testing: No. I haven't begun working on it yet. The modularization is documented through the API docs <http://bootstrap-vz.readthedocs.org/>. Though some more prose text about how to e.g. bootstrap programatically with multiple manifests couldn't hurt. > What are the plans? To begin with I'll just take the stupid and simple route and see where it leads/what challenges I encounter. My primary motivation for this is actually for development. I am growing tired of having to bootstrap, wait, create instance, wait, try logging in, rinse & repeat. Especially when fiddling with the bootloader and partitioning. I'd like an automated way to verify that a specific configuration works. > What images will be produced and how? To begin with I'll focus on either ec2 or virtualbox and then abstract from there. Since I run OSX I bootstrap inside a vbox - running the resulting image inside that vm seems kind of wasteful and potential slow, so I'll probably come up with some kind of remote bootstrapping option. > What packages will they contain? > How are they configured and tested and distributed? > What's the build cadence and update strategy? These are not my questions to answer since I only provide the tool, the images are built and published by people working at the providers, and I'm quite happy with that arrangement :-) You'd have to ask James Bromberger (AWS) and Jimmy Kaplowitz (GCE) about that. Just one thing about the configuration: The official manifests for Debian images on AWS are available directly in the bootstrap-vz repo in the manifests/ folder. > Sorry for bombarding you with all these questions but I've been thinking about how to get this going (Debian building official cloud images) and in fact just scheduled a open discussion at the next DebConf to talk about this. Good to hear. I regret not attending DebConf last year and though Portland is a cool city it's a bit too far away for me this year (I live in Denmark). > How can I help? I have zero experience in doing testing on this scale (i.e. checking that an entire OS is running properly). I'd be interested in any pointers you or others might have to resources (tools, articles etc.) that could help in that regard. Anders
