From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 355D53B796 for ; Mon, 13 May 2024 18:28:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715624932; cv=none; b=Gq/4PuTYSB6kLc2XFg6UKOqWuCXUpcenVviWo0dDoKr9EiYsaZpJDzamffAfATWXJsYyBHMv6lXkM0HRLyZCoQLCViYp4gV3hfTBIX2YZa++SKAi4v54H0BWarazUTP5n5SBNPK2STbAwVRkEQDN6dr2APqX56gCKs+NGYioH+w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715624932; c=relaxed/simple; bh=ng65z1y43rfisL/2a8iWi+B+aVRPeX98fMZtzkC4igs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: In-Reply-To:Content-Type:Content-Disposition; b=W6BhHS5ijY5jbqmXM7vn9U8kTF4zsPstZJQVm+eJbbR1y2GMNF4dSbjPej+2eDPKPTRsvY4Tfmnz6gmEvqdOntuUJnICdKHyNClL0jp+QzT5yJMY0Yy+/A8w/ecuIPpDtGgNZDN1V7bhUBJGc9EoChI1pAzucCv+ufaw9kYON8Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=KRaqqyKj; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="KRaqqyKj" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1715624928; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FKzk3LtOShZ4OFauXHHTCWPGMgZiRq79kGxnnYjIqPw=; b=KRaqqyKjND7bDdqDYFVUuozx994FA2ah76iGu7Yx76NyLUzy5EozJj551UO5Mq4v32mrkf 18Oh+918looaFOTpjlOwRVOl29WmxGeuU88f7pY++SkDBxaYwb5GwekqQKvoarweOZTCwp 39+iJSku8AaOJbAbhLTNl1GwYn482Io= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-36-IVg3Bg-CPhe4xQPFvVbMAQ-1; Mon, 13 May 2024 14:28:35 -0400 X-MC-Unique: IVg3Bg-CPhe4xQPFvVbMAQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7370C80027F; Mon, 13 May 2024 18:28:35 +0000 (UTC) Received: from localhost (unknown [10.42.28.23]) by smtp.corp.redhat.com (Postfix) with ESMTP id 36333C15BB1; Mon, 13 May 2024 18:28:35 +0000 (UTC) Date: Mon, 13 May 2024 19:28:34 +0100 From: "Richard W.M. Jones" To: Luis Chamberlain Cc: Scott Mayhew , kdevops@lists.linux.dev Subject: Re: [PATCH 05/10] guestfs: add initial debian trixie support with custom URLs Message-ID: <20240513182834.GL4345@redhat.com> References: <20240508065039.3408637-1-mcgrof@kernel.org> <20240508065039.3408637-6-mcgrof@kernel.org> Precedence: bulk X-Mailing-List: kdevops@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, May 11, 2024 at 04:46:48PM -0700, Luis Chamberlain wrote: > On Wed, May 08, 2024 at 01:30:42PM -0400, Scott Mayhew wrote: > > On Tue, 07 May 2024, Luis Chamberlain wrote: > > > > > debian does not yet provide an index file for virt-builder, but we > > > have URLS with qcow2 and raw files. Using them in guestfs is actually > > > not quite trivial. So we do the handy work to enable others to also > > > use custom URLs and build a virt-builder local source and index file > > > for you. All we need really, is to check the checksums. > > > > > > Sadly this does not yet work, as it seems we get stuck on the grub > > > prompt for some reason. This needs some more investigation. > > > > Yeah when I run 'make bringup' the consoles on all the guests are stuck > > on "Booting `Debian GNU/Linux'". > > Is that with Trixie or also with y9our own custom ISO? > > > I tried manually running virt-builder + virt-install using the same > > image and I get the same result. Granted, I've only ever used the > > images in the libguestfs repos or images that I've built myself, so I > > could be doing something wrong. > > I'm in hopes we can figure this out, there is likely something special > done on the images hosted by libguestfs.org which regular nocloud images > like debian's trixie is not doing: > > https://cloud.debian.org/images/cloud/trixie/daily/latest/debian-13-genericcloud-amd64-daily.raw > > Once we figure that out, we should be able to easily do that as a post > up with virt-builder. > > Richard, any hints on what likely should help fix boot? Sorry, it's not enough information to say. Is it possible to enable a serial console and find out where it's hanging? Rich. > > > diff --git a/kconfigs/Kconfig.guestfs b/kconfigs/Kconfig.guestfs > > > index 5838522908e8..5839fbedfd08 100644 > > > --- a/kconfigs/Kconfig.guestfs > > > +++ b/kconfigs/Kconfig.guestfs > > > @@ -1,5 +1,30 @@ > > > if GUESTFS > > > > > > +config GUESTFS_HAS_CUSTOM_RAW_IMAGE > > > + bool > > > > It might be useful for these variables to have prompts so they show up > > in 'make menuconfig'. > > That's a one line change, it just needs a description, for now its auto > because there is no custom raw image URL option, what you descrie seems > for us to want such a new entry and option. So sure, but I think that > can be done in subsequent patch? > > > I have a whole bunch of workflows running for > > RHEL8 and RHEL9 nightly builds... they start with 8.9 or 9.3 > > images > > I see, yes, we wouldn't need to let you enable GUESTFS_HAS_CUSTOM_RAW_IMAGE > but rather waht we want is just a drop down menu for distro to let you > select "custom", that way you could use a set of defconfigs which would > use the custom image URL, when that is enabled it selects > GUESTFS_HAS_CUSTOM_RAW_IMAGE. > > > and use the CONFIG_KDEVOPS_CUSTOM_YUM_REPOFILE to update them to > > the latest bits. > > My patch after this "guestfs: add support to infer host distro > mirrororing optimizations" helps to infer when we want to copy a > custom sources list, based on a host's hop count. What you describe > seems to beg for another auto-infererence which could be based on > some target directory and based on on the custom URL. That could be > added and then you wouldn't even need to make any custom .config other > than having a few defconfigs for each distro point release. > > > If I could build my own images and dump them in a > > directory without having to worry about updating the index file that > > would probably speed things up a bit. > > I think this is possible, we could just look for directory we add to > .gitignore, and if the user has it as a symlink, we leverage that as > a key indicator for "hunting season open for custom images, please > populate my Kconfig with these other custom options". > > > > + > > > +config GUESTFS_HAS_CUSTOM_RAW_IMAGE_URL > > > + bool > > > + > > > +config GUESTFS_CUSTOM_RAW_IMAGE_URL > > > + depends on GUESTFS_HAS_CUSTOM_RAW_IMAGE > > > + depends on GUESTFS_HAS_CUSTOM_RAW_IMAGE_URL > > > + string > > > + default "https://cloud.debian.org/images/cloud/trixie/daily/latest/debian-13-generic-amd64-daily" if GUESTFS_DEBIAN_TRIXIE_GENERIC_AMD64 > > > + default "https://cloud.debian.org/images/cloud/trixie/daily/latest/debian-13-genericcloud-amd64-daily" if GUESTFS_DEBIAN_TRIXIE_GENERIC_CLOUD_AMD64 > > > + default "https://cloud.debian.org/images/cloud/trixie/daily/latest/debian-13-nocloud-amd64-daily" if GUESTFS_DEBIAN_TRIXIE_NOCLOUD_AMD64 > > > > You need '.raw' at the end of the URL, right? > > Oops yes sorry. > > > > diff --git a/scripts/bringup_guestfs.sh b/scripts/bringup_guestfs.sh > > > index f90ed499051b..514a26a60436 100755 > > > --- a/scripts/bringup_guestfs.sh > > > +++ b/scripts/bringup_guestfs.sh > > > @@ -30,8 +30,135 @@ GUESTFSDIR="${TOPDIR}/guestfs" > > > OS_VERSION=${CONFIG_VIRT_BUILDER_OS_VERSION} > > > BASE_IMAGE_DIR="${STORAGEDIR}/base_images" > > > BASE_IMAGE="${BASE_IMAGE_DIR}/${OS_VERSION}.raw" > > > + > > > +build_custom_source() > > > +{ > > > + SOURCE_TMP=$(mktemp) > > > + cat <<_EOT >$SOURCE_TMP > > > +[local] > > ^^^ > > You probably want this to be unique based on the flavor. If you switch > > flavors, then you're going to wind up with multiple repo configs with the > > same repo id and virt-builder will only pick up the last one it reads... > > the end result being that it probably won't find the template you want > > to install. > > So this is for the source, not the index, the source is local, can we > not have multiple arbitrary sources with the same name? The indexes for > each file would be different. Here I just wanted to emphasize that the > source is local. > > > > > > +uri=file:///${CUSTOM_INDEX} > > > +proxy=off > > > +_EOT > > See the source, points to a custom index, and so we'd have multiple > local sources, the index files do change per flavor. > > But certainly, it would be good to get this right to make this scale. > For now to start off with trixie, and later to scale to whatever custom > setup we need for random builds. > > Thoughts / advice? > > Anyway, since this still has a big fat warning as "this doesn't work > yet", I've made the changes required so far and pushed these patches in, > we can make changes to scale this, now that at laest its easier to test > these things. > > Luis -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com nbdkit - Flexible, fast NBD server with plugins https://gitlab.com/nbdkit/nbdkit