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.
