[syslinux] New 'quiet' behavior - optional?

[Kenneth Morse]

On Tue, Nov 23, 2010 at 3:03 PM, H. Peter Anvin <hpa at zytor.com> wrote:
> Use "loglevel=4" instead of "quiet".
>
>        -hpa
>

If it was only a matter of kernel log messages, that would probably be
sufficient.  Unfortunately, it's much more involved than that.  The
presence or absence of 'quiet' on the linux kernel command line makes
a functional difference in how the product runs.  With 'quiet'
specified, it does suppress all kernel messages, and then goes through
an automated series of steps, eventually launching an application for
the user to use.   Without 'quiet' on the command line, it begins an
interactive process, asks some start questions (which are suppressed
when 'quiet'), then drops the user at a linux command prompt,
expecting them to know what to use next - which is not a desired
outcome.   While this is of course all logic stored within the initrd
image, I do not have the ability to expand, alter, recreate, and then
cryptographically re-sign the initrd.  (And it checks the signature).
Even if it were possible, I would not be particularly thrilled about
having to recreate dozens of initrds for all existing images, and
rebuild every one I receive going forward - which is why I'm looking
at hopefully finding a solution on the syslinux/pxelinux side.

In the (distant) past, the rebuilding of pxelinux.0 by end users was a
delicate operation, discouraged, and not for the faint of heart.  Is
this still the case?

If rebuilding pxelinux.0 at my end is an option, I'll just remove the
'quiet' behavior added in 3.71.  Going forward, were an additional
parameter to be added to syslinux allowing the configuration to say
"Yes, there's a quiet on the command line, it's meant for the target,
syslinux please ignore it", it would make one installation very happy.

In the meantime, I'm off to crack open an initrd to reread it's logic
(long shot to see if there are any solutions to my problem to be found
there), and attack the syslinux source.

Regards,

-Ken