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]) by passt.top (Postfix) with ESMTP id E57575A026D for ; Thu, 25 Apr 2024 06:48:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1714020506; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NjugMiokdkCSz4J0J8gVu2vPblaP2+eTNHkdSmvKvtU=; b=b+VlENH1pVy7odbafkFuH91fvijzuXtbCTk8xPzkafNkutXsHiaKsHcwkEeNV8bZUJwiLu geVfhptbSoH8kZ+zhuV/goi3SIm7P8fnWSwlalz70JKC89Uj/xaYlEQzcrKxBKaPIgdCVL +yNx6+D4BaKZvHbjLybheqrDev6f0Ig= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-588-Hmtyw2PKPaiSJXei9Fepxg-1; Thu, 25 Apr 2024 00:48:15 -0400 X-MC-Unique: Hmtyw2PKPaiSJXei9Fepxg-1 Received: by mail-ej1-f69.google.com with SMTP id a640c23a62f3a-a5872678bd2so26675366b.3 for ; Wed, 24 Apr 2024 21:48:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714020493; x=1714625293; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=NjugMiokdkCSz4J0J8gVu2vPblaP2+eTNHkdSmvKvtU=; b=WqnAWwhVQa94m2f9hPX+aOilwzjIj/vdLw3c0c5PYGo44WxjbsshoZOUo0gClqoC8B Z0trCQ4B6Svh2Tsd1s2ndyQutSGHJHhFo2GZjxpghtYGQIjcVJ6pDF8TH0Omi7WmKFyW R6cjnNGQ60TwaZSQX1s4rVTFivOUm+TsqhU4UmweXBfEkeuhZCxRNGRMGVrXt1pBikGk KI5GZiG5J7TVoGdb6B+zHGsJOuUa7f6CKqWEUfboKGT4jZXbQxaYWw0bFG37fJft7TJm 9Wn0Pv94K1UcPTc5f28Dnese/LaY0K6KsEZgPEIZ+Pu/pAWx5i1210uj4ecIq1Ebc37h Lklg== X-Forwarded-Encrypted: i=1; AJvYcCVuzI2KaDK/2v6Qgq7I1M2sIdoh9e6BxA0eac1iJCiNExS9NFlK0yRS4eymp7io3KKV+Wk61PaKZhU2JAibb5xjEaIH X-Gm-Message-State: AOJu0YyyjQDTS0p9G5gZ12J03MS4R4nhHqk5SD1iZVdLJe5B64HsMNdQ 3X5jxA9fp+AHrIndROHep/sEl4XCP47iZN7zssKs/JijEbKZhrufD8vi+MqI73YgtwooCP9XqyP HNk8j8o3s2Ma/RdocpsEwNjodK72aUpKXK3criQiKETnK1mzjzCIZsfUH0T0a X-Received: by 2002:a17:907:a4c:b0:a58:9485:3156 with SMTP id be12-20020a1709070a4c00b00a5894853156mr2947912ejc.50.1714020493576; Wed, 24 Apr 2024 21:48:13 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFmghIfHAHfMjZjw0gbj8fnusVtZ5GIJEUH6+U07vH11mYt/pVnTzkqWa4bqc1b3xzKBvxEog== X-Received: by 2002:a17:907:a4c:b0:a58:9485:3156 with SMTP id be12-20020a1709070a4c00b00a5894853156mr2947900ejc.50.1714020493058; Wed, 24 Apr 2024 21:48:13 -0700 (PDT) Received: from maya.cloud.tilaa.com (maya.cloud.tilaa.com. [164.138.29.33]) by smtp.gmail.com with ESMTPSA id i21-20020a170906091500b00a5216df5d25sm9066500ejd.3.2024.04.24.21.48.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Apr 2024 21:48:12 -0700 (PDT) Date: Thu, 25 Apr 2024 06:47:38 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 2/4] Remove stale archivemount support Message-ID: <20240425064738.0368f902@elisabeth> In-Reply-To: References: <20240322022739.2746102-1-david@gibson.dropbear.id.au> <20240322022739.2746102-3-david@gibson.dropbear.id.au> <20240405200921.0a1f0318@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.36; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: EMG4UJ2YQ5H6E5PRP4UDZDT7RIIBVCOT X-Message-ID-Hash: EMG4UJ2YQ5H6E5PRP4UDZDT7RIIBVCOT X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: lvivier@redhat.com, passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Sat, 6 Apr 2024 14:02:58 +1100 David Gibson wrote: > On Fri, Apr 05, 2024 at 08:09:32PM +0200, Stefano Brivio wrote: > > On Fri, 22 Mar 2024 13:27:37 +1100 > > David Gibson wrote: > > > > > mbuto has two ways of building the initramfs. One is the typical approach > > > of staging its contents in a temporary directory, then building the > > > initramfs with cpio. The other is to create an empty initramfs, mount > > > it with archivemount, and copy things into the mounted archive. > > > > > > However, the archivemount approach is broken. I'm not entirely sure why, > > > but it appears not to properly unmount the archive and retrieve the final. > > > filled version. The upshot is that if archivemount is installed, then > > > mbuto generates an empty, gzip-compressed initramfs instead of whatever it > > > was supposed to. It looks like this has bitrotted from some earlier > > > working version. > > > > > > The archivemount approach is not necessary, and honestly a pretty strange > > > and roundabout way of building the initramfs. Remove it. > > > > There were two reasons behind that: first off, I mistakenly assumed > > that the kernel could see changes made to the initramfs after boot. > > Yeah, that was never going to work. > > > Second, it was actually convenient for developing this tool as I could > > just make directories and copies in half-working images. I also had > > half a mind about some usage with QEMU rebooting the guest, and the > > initramfs would change across reboots without having to call mbuto > > again, for bisections or suchlike. > > That's not really dependent on using archivemount in any case. If > qemu re-reads the initrd on each boot, then you can still do this by > rebuilding the image between boots (which is all that archivemount > would do anyway). That was exactly my point: with archivemount, the user doesn't have to call mbuto again -- archivemount does it, implicitly. > If qemu doesn't re-read it, then this won't work even if you are using > archivemount. It looks like QEMU doesn't do that, at least not on x86, so yes, this part never worked anyway. -- Stefano