All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Katz <katzj-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: "initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [ANNOUNCEMENT] dracut-0.5
Date: Sun, 19 Jul 2009 22:01:51 -0400	[thread overview]
Message-ID: <20090720020150.GA50193@redhat.com> (raw)
In-Reply-To: <4A608CD3.7070107-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

On Friday, July 17 2009, Harald Hoyer said:

> - more kernel command line parameters (see also man dracut(8))
> - a helper tool, which generates the kernel command line (dracut-gencmdline)
[snip]
> rd_DM_UUID, rd_LUKS_UUID, rd_MD_UUID help you, if dracut does more than 
> you want in its automatic mode. So if you want to be more specific on 
> what dracut is allowed to assemble, uncrypt etc. just specify the exact 
> parameters.

Hmmm, requiring/expecting this much in the way of kernel parameters in
the default case feels like it has a likelihood of hitting
architecture-specific limits on command line size.  I know that's been a
problem in a lot of cases on s390 in the past.

I wonder if its worth supporting reading these first from a file "in the
initramfs"[1] and then letting /proc/cmdline act as overrides of that
ala the way the s390 people have historically done .parm files[2].

Jeremy

[1] It doesn't actually need to be in the packaged initramfs -- we could
generate a host-specific file that's added as a second initramfs via the
bootloader config.  dracut doesn't need to know its from a second file
but that seems like it would be straight-forward enough and help the
problem.  It also could be used for things like keeping passwords out of
the kernel command line
[2] I can't believe I'm actually suggesting following something s390 has
done :-)
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2009-07-20  2:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-17 14:38 [ANNOUNCEMENT] dracut-0.5 Harald Hoyer
     [not found] ` <4A608CD3.7070107-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-07-20  2:01   ` Jeremy Katz [this message]
     [not found]     ` <20090720020150.GA50193-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-07-25 22:59       ` Karel Zak
     [not found]         ` <20090725225944.GC27655-sHeGUpI7y9L/9pzu0YdTqQ@public.gmane.org>
2009-07-26  2:17           ` Jeremy Katz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090720020150.GA50193@redhat.com \
    --to=katzj-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.