On Thu, 31 Mar 2011 22:14:27 -0400, Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote: > On 03/31/2011 04:27 PM, micah anderson wrote: > > > I propose building a package that installs pre-built images into > > /boot/debirf and the following (tested!) /etc/grub.d/21_debirf to fill > > out the grub menu: > > Are you imagining that some binary package would actually contain the > pre-built debirf images as well? I think it would be difficult to > create such a thing on any buildd, since the buildds are not required to > have a network connection.
Yes. I want to install a package and have the image installed, and grub setup. I couldn't find any policy about debian autobuilders and network access, but I did find http://ftp-master.debian.org/wiki/projects/autosigning/ which discusses the rationale. It certainly makes sense not to have network access, it just makes certain things more difficult. With that said, on a buildd, there is a complete debian mirror available locally, the building of packages has to be able to fetch necessary dependencies. That mirror typically is accessed via apt. If that is done through the network or a local package cache, it doesn't matter. The packages are available, if the debirf debootstrap build process was configured to use the right location, it shouldn't have a problem pulling in packages. I dont know if there is a canonical location for buildds. For example, you can look at a buildd log and see the package build pulling in various packages: https://buildd.debian.org/fetch.cgi?pkg=downtimed&ver=0.4-1&arch=s390&stamp=1301669991&file=log in this case, its pulling things from http://ftp.de.debian.org and http://incoming.debian.org/debian. On a powerpc buildd its pulling things from http://ftp.uk.debian.org, etc. > However, we're now running a debirf autobuilder and publishing > cryptographically-signed, pre-built images for common architectures > (i386 and amd64 at the moment): > > http://debirf.cmrg.net/autobuilds/ > > What if we made a small arch:all package named "debirf-prebuilt-images" > which provides the grub snippet, and a tool for easy download and > verification of those images? That package could be installed without > even needing the debirf package or its dependencies at all. I'd rather pull the package with the image straight from my local system's configured repository if possible, rather than have a package that pulls in external data. > > #!/bin/sh > > set -e > > > > prefix=/usr > > exec_prefix=${prefix} > > bindir=${exec_prefix}/bin > > libdir=${exec_prefix}/lib > > . ${libdir}/grub/grub-mkconfig_lib > > > > DEBIRF_CMDLINE="root=/dev/ram0 rw panic=15 $GRUB_CMDLINE_LINUX" > > what are the arguments "root=/dev/ram0" and "rw" doing here? i don't > think they're meaningful in the debirf initramfs. I was wondering that too, I got them from jrollin's snippit he provided (https://www.finestructure.net/pastebin/1301589901), which this was based off of originally. I figured he knew something about debirf I did not, so I included them. > > # loop-AES arranges things so that /dev/loop/X can be our root device, but > > # the initrds that Linux uses don't like that. > > case ${GRUB_DEVICE} in > > /dev/loop/*|/dev/loop[0-9]) > > GRUB_DEVICE=`losetup ${GRUB_DEVICE} | sed -e > > "s/^[^(]*(\([^)]\+\)).*/\1/"` > > ;; > > esac > > > > if [ "x${GRUB_DEVICE_UUID}" = "x" ] || [ "x${GRUB_DISABLE_LINUX_UUID}" = > > "xtrue" ] \ > > || ! test -e "/dev/disk/by-uuid/${GRUB_DEVICE_UUID}" \ > > || uses_abstraction "${GRUB_DEVICE}" lvm; then > > LINUX_ROOT_DEVICE=${GRUB_DEVICE} > > else > > LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID} > > fi > > Aren't these also unnecessary? why is LINUX_ROOT_DEVICE meaningful to > debirf? Is this really the minimal grub config snippet such a package > would need? I'd be happy to ship a reasonable grub config snippet, but > i don't want to cargo-cult anything we don't need. It depends on what you mean by 'these'. I am guessing you mean both of the above if blocks, which includes some mangling of GRUB_DEVICE in the first one, and some LINUX_ROOT_DEVICE in the second? I'm only unclear because you only ask about LINUX_ROOT_DEVICE. Starting with GRUB_DEVICE....I'm also unsure of some of grub's variables, such as GRUB_DEVICE, as I haven't been able to find a manual where they come from to better understand what they are used for. If you have any knowledge of where I can find that, I'd be happy to know about it. If I were to hazard a guess $GRUB_DEVICE is the /boot/grub/device.map device where grub is actually installed. This is used when constructing the $prepare_boot_cache variable, which uses the prepare_grub_to_access_device function. That ends up providing us with stanzas similar to the following that are used in the actual menuentry: insmod part_msdos insmod ext2 set root='(hd0,msdos1)' search --no-floppy --fs-uuid --set f0c8aad1-788f-4f1b-8142-18afe67d6b03 If there is no use having the root device passed in grub, then I dont see any reason for having the above two if blocks, nor the prepare_boot_device variable, nor the printf which puts them in the menuentry. I wasn't sure if it would be useful in debirf to pass a root device or not, but again I was basing my assumptions on the snippit jrollins provided which has this: set root=(hd0,5) which is clearly not going to be universally useful, so I figured that if that was needed/useful (and I suspected it was because jrollins was using it), then it should be generated from what the system has. Regarding the LINUX_ROOT_DEVICE if block... this isn't actually used in this particular script, but it would be used if passing a root device to the kernel should be set to something that is similarly dynamically generated for the system, rather than 'root=/dev/ram0'. If passing a root device at all is pointless, then this should be removed. micah
pgpQVwYMh88Fp.pgp
Description: PGP signature
