Bug#1036918: debvm: manual mounting of root image
Hi Helmut,
On Thu, Jun 01, 2023 at 07:53:00AM +0200, Helmut Grohne wrote:
> Hi Wouter,
>
> On Wed, May 31, 2023 at 12:18:00PM +0200, Wouter Verhelst wrote:
> > I don't think it is. All packages that do things at early boot have
> > complicatd requirements; nbd isn't the only one. It's just the first one
> > you hear about.
>
> Thank you for not giving up here.
>
> > > and that debvm may not be the right hammer for your job? While debvm
> > > gives you a complete rootfs, you seem to be satisfied with a kernel an
> > > an initrd.
> >
> > No, that is not accurate; I do need a root filesystem too.
>
> Now that - to me - is a compelling argument. Arguably, that should have
> been obvious. Thanks for spelling it out.
>
> > Yes, I could run debvm-create and then do the extraction of the kernel
> > and initrd myself, but that shouldn't be necessary -- debvm-run would be
> > a perfectly good abstraction, if only it allowed me to tell it not to
> > try to mount the hard drive automatically and/or let me override the
> > root= parameter.
>
> I believe I now understand your use case and I follow your reasoning
> that debvm could reasonably do better at supporting it.
>
> Both mmdebstrap and debvm-create have a --skip mechanism. Doing
> something similar to debvm-run seems sensible initially. The precise way
> of doing it less so. Would you be interested in helping sort the
> details?
>
> For one thing, I think your use of -append does not work well with
> debvm-run. While it sounds like it was appending, it actually is
> replacing the kernel cmdline. debvm-run has its own ideas and passes the
> rootfs, console and terminal emulation type there. By overriding
> -append, you miss all of that. I suspect, we need a more clever
> management of cmdline here and am unsure what that should be exactly.
Ah, yes. I did indeed assume it was keeping the arguments, but it not
doing so seems consistent with what I saw. I assumed that things went
wrong because there were multiple versions of hte same filesystem; but
come to think of it, I would then still have had some output, at least,
which I did not. Losing the whole command line would lose the console,
which would mean there was no output.
I do think debvm-run needs to have a way to actually add to the kernel
command line. Some use cases would need this without having to basically
reimplement what it is already doing. Combined with a skip mechanism, I
think that would cover a lot of use cases.
Since ordering of the kernel command line rarely matters, adding a
simple option for additional command line bits (which then get added at
the end of the command line) should be sufficient, I would think.
> For passing the actual rootfs, I guess a --skip=rootdev would address
> your need. I imagine it as skipping both the root= cmdline argument and
> passing of the blockdev.
I think it may make more sense to treat the two as separate. You mount
the root filesystem by label, currently; so it does not matter how the
block device is set up, as long as it is there. I think some use cases
would benefit from being able to fine-tune the way the block device is
set up without having to add the root filesystem again.
On the other hand, adding a root= parameter to the command line after it
has been removed should be fairly trivial, provided there is a way to
add to the kernel command line without having to redo it. So I don't
think this is really crucial.
> Other things that users might want to skip include the network setup
> (not in your case ;) and the random device setup.
>
> So at this point, the addition of a --skip option seems fairly likely to
> me, but I'd like to consult with other users some more and won't upload
> debvm before bookworm has been released anyway. Still your (and other's)
> input on what kind of features should be skippable and how we could
> better deal with the cmdline is welcome.
>
> Thanks for insisting.
>
> Helmut
>
>
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1036918: debvm: manual mounting of root image
Hi Wouter, On Wed, May 31, 2023 at 12:18:00PM +0200, Wouter Verhelst wrote: > I don't think it is. All packages that do things at early boot have > complicatd requirements; nbd isn't the only one. It's just the first one > you hear about. Thank you for not giving up here. > > and that debvm may not be the right hammer for your job? While debvm > > gives you a complete rootfs, you seem to be satisfied with a kernel an > > an initrd. > > No, that is not accurate; I do need a root filesystem too. Now that - to me - is a compelling argument. Arguably, that should have been obvious. Thanks for spelling it out. > Yes, I could run debvm-create and then do the extraction of the kernel > and initrd myself, but that shouldn't be necessary -- debvm-run would be > a perfectly good abstraction, if only it allowed me to tell it not to > try to mount the hard drive automatically and/or let me override the > root= parameter. I believe I now understand your use case and I follow your reasoning that debvm could reasonably do better at supporting it. Both mmdebstrap and debvm-create have a --skip mechanism. Doing something similar to debvm-run seems sensible initially. The precise way of doing it less so. Would you be interested in helping sort the details? For one thing, I think your use of -append does not work well with debvm-run. While it sounds like it was appending, it actually is replacing the kernel cmdline. debvm-run has its own ideas and passes the rootfs, console and terminal emulation type there. By overriding -append, you miss all of that. I suspect, we need a more clever management of cmdline here and am unsure what that should be exactly. For passing the actual rootfs, I guess a --skip=rootdev would address your need. I imagine it as skipping both the root= cmdline argument and passing of the blockdev. Other things that users might want to skip include the network setup (not in your case ;) and the random device setup. So at this point, the addition of a --skip option seems fairly likely to me, but I'd like to consult with other users some more and won't upload debvm before bookworm has been released anyway. Still your (and other's) input on what kind of features should be skippable and how we could better deal with the cmdline is welcome. Thanks for insisting. Helmut
Bug#1036918: debvm: manual mounting of root image
On Mon, May 29, 2023 at 08:22:06PM +0200, Helmut Grohne wrote:
> Hi Wouter,
>
> On Mon, May 29, 2023 at 02:20:09PM +0200, Wouter Verhelst wrote:
> > I am exploring the possibility to write an autopkgtest for the initramfs
> > stuff that I wrote for nbd-client.
>
> Please see my other mail regarding the use of debvm in autopkgtests.
> Let's not duplicate that topic here. I note that this fully applies in
> the exact way to the projected use of mmdebstrap below.
Sure, but as there were two feature requests, I opened two wishlist bugs ;-)
> > In order to do so, I want to run a client VM that has no root hard disk
> > configured, but is configured to attempt to mount the VM image over the
> > network, using NBD. This is accomplished by way of a few kernel command
> > line parameters.
> >
> > I tried running
> >
> > debvm-run -- -append 'nbdroot=192.168.88.103,root_export,nbd0'
>
> May I suggest that this is a quite unusual use case
Sigh.
Everyone who I talk to about nbd autopkgtest tells me it's an "unusual"
use case.
I don't think it is. All packages that do things at early boot have
complicatd requirements; nbd isn't the only one. It's just the first one
you hear about.
> and that debvm may not be the right hammer for your job? While debvm
> gives you a complete rootfs, you seem to be satisfied with a kernel an
> an initrd.
No, that is not accurate; I do need a root filesystem too.
For reference, nbd is not nfs; it is a network BLOCK device, which means
you need to layer a filesystem on top. So in order to be able to boot
from nbd, you need to create an image that you export. While I could do
this myself, it's what debvm-create does, and I don't think it makes
much sense to replicate that.
In short, the plan is to do something along these lines:
1. Create a filesystem image
2. Configure nbd-server to export that image over NBD, and restart nbd-server
3. boot a VM with the root filesystem on NBD, pointed to the nbd-server that we
just configured
4. Verify that we reach a shell in the VM
5. shut down the VM again
6. Verify that the shutdown worked correctly
7. Boot the VM again, make configuration changes, update the initramfs
8. Reboot the VM, repeat steps 4 through 6.
(I might also want to try some of the other nbdroot= argument formats
that are documented in nbd-client's README.Debian, which all would
require their own reboot, but these are details)
I was looking at guestfish and other similar things, but really, debvm
already does all of this, so there's no point. The only thing is that it
insists on passing root and hard disk arguments to qemu, which break for
my use case.
Yes, I could run debvm-create and then do the extraction of the kernel
and initrd myself, but that shouldn't be necessary -- debvm-run would be
a perfectly good abstraction, if only it allowed me to tell it not to
try to mount the hard drive automatically and/or let me override the
root= parameter.
Thanks for considering,
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1036918: debvm: manual mounting of root image
Hi Wouter, On Mon, May 29, 2023 at 02:20:09PM +0200, Wouter Verhelst wrote: > I am exploring the possibility to write an autopkgtest for the initramfs > stuff that I wrote for nbd-client. Please see my other mail regarding the use of debvm in autopkgtests. Let's not duplicate that topic here. I note that this fully applies in the exact way to the projected use of mmdebstrap below. > In order to do so, I want to run a client VM that has no root hard disk > configured, but is configured to attempt to mount the VM image over the > network, using NBD. This is accomplished by way of a few kernel command > line parameters. > > I tried running > > debvm-run -- -append 'nbdroot=192.168.88.103,root_export,nbd0' May I suggest that this is a quite unusual use case and that debvm may not be the right hammer for your job? While debvm gives you a complete rootfs, you seem to be satisfied with a kernel an an initrd. How about peeking at debvm's source and extracting the useful bits from it? In effect you can skip much of what debvm does and construct a manageable mmdebstrap invocation directly. The following draft is entirely untested: mmdebstrap \ --variant=apt \ unstable \ /dev/null \ --include=linux-image-"$(dpkg --print-architecture)" \ --customize-hook="download /initrd ./initrd" \ --customize-hook="download /vmlinuz ./vmlinuz" > I would like to see an option to tell debvm-run not to mount the > filesystem image but to let the user handle that. However, the > extracting of the kernel and initramfs which debvm-run does would still > be necessary; it's just that I want to fiddle with how we get to the > filesystem. Given the images, I think you can pass them to qemu directly. Do you agree that for this use case, using the underlying tools directly does a better job? Helmut
Bug#1036918: debvm: manual mounting of root image
Package: debvm Version: 0.2.10 Severity: wishlist Hi, I am exploring the possibility to write an autopkgtest for the initramfs stuff that I wrote for nbd-client. In order to do so, I want to run a client VM that has no root hard disk configured, but is configured to attempt to mount the VM image over the network, using NBD. This is accomplished by way of a few kernel command line parameters. I tried running debvm-run -- -append 'nbdroot=192.168.88.103,root_export,nbd0' however, since debvm-run had by this point already mounted the hard drive, the kernel sees the same root device twice, and let's just say that this didn't go very well. I would like to see an option to tell debvm-run not to mount the filesystem image but to let the user handle that. However, the extracting of the kernel and initramfs which debvm-run does would still be necessary; it's just that I want to fiddle with how we get to the filesystem. Thanks, -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE:nl Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debvm depends on: ii e2fsprogs 1.47.0-2 ii genext2fs 1.5.0-3 ii ipxe-qemu 1.0.0+git-20190125.36a4c85-5.1 ii mmdebstrap 1.3.5-7 ii passwd 1:4.13+dfsg1-1+b1 ii qemu-system-arm 1:7.2+dfsg-7 ii qemu-system-mips1:7.2+dfsg-7 ii qemu-system-misc1:7.2+dfsg-7 ii qemu-system-ppc 1:7.2+dfsg-7 ii qemu-system-sparc 1:7.2+dfsg-7 ii qemu-system-x86 [qemu-kvm] 1:7.2+dfsg-7 Versions of packages debvm recommends: ii arch-test 0.20-1 ii binfmt-support2.2.2-2 ii fakechroot2.20.1+ds-15 ii fakeroot 1.31-1.2 ii file 1:5.44-3 ii openssh-client1:9.2p1-2 ii qemu-system 1:7.2+dfsg-7 ii qemu-user-static 1:7.2+dfsg-7 ii seabios 1.16.2-1 ii systemd 252.6-1 ii uidmap1:4.13+dfsg1-1+b1 Versions of packages debvm suggests: ii qemu-system-gui 1:7.2+dfsg-7 -- no debconf information
