Arch Linux

status with 2.6.29?

Still doesn't work for me

Please report it to bugzilla.kernel.org or lkml to get it fixed

but it works on other distros.

This is a shortcoming of the option parsing in our initramfs. There was an unresolved bug about it already.

and for what it's worth this bug also affects 64 bit

any news on this? i really want to install arch but this is a showstopper for me :)

tackling this same problem I found this (temporary?) solution:
there is a for loop processing the kernel command line args in the initrd's /bin/init script:
for cmd in ${CMDLINE}; do
case "${cmd}" in
\#*) break ;; # ignore everything after a # in the commandline
# The kernel passes those to the kernel on its own
[0123456Ss]) ;;
single) ;;
#Allow "init=X" to pass-through
init=*) kinit_params="${kinit_params} ${cmd}" ;;
# only export stuff that does work with dash :)
*=*) cmd="$(replace -s= "${cmd}" '.' '_')"
cmd="$(replace -s= "${cmd}" '-' '_')"
export "${cmd}"
;;
*) cmd="$(replace "${cmd}" '.' '_')"
cmd="$(replace "${cmd}" '-' '_')"
export "${cmd}=y"
;;
esac
done

the shell chops
acpi_osi="!Windows
and
2006"
into two separate arguments and get processed by the last two (respectively) case matches.
for acpi_osi="!Windows this works (although is useless)
but for 2006" this does not work (it attempts to export an environment variable with the name 2006" which isn't allowed)

the solution here is already there: the #* match that breaks from the loop so you can insert that prior to the acpi_osi variable.
here is my grub entry as an example:

title Arch
root (hd0,3)
kernel /boot/vmlinuz26 root=/dev/disk/by-uuid/..... ro vga=773 # acpi_osi="!Windows 2006"
initrd /boot/kernel26.img

the kernel will still process this argument but that shell loop will not.

wow that's ugly so much for WYSIWYG :)

This bug is important for Sony VAIO Z Series users.
Please help :-)

syl: I am a VAIO Z user as well--adding the '#' character to your grub config (/boot/grub/menu.lst) line as in my example should solve this problem for you

Hi Tom, thanks for the info. I'll PM you, if you don't mind.
cheers

what is the status of this issue with new mkinitcpio-0.6?

Unchanged, I still don't really know how to solve it currently.

mmm, I tested it and boot without any issues. Seems that the error is ignored with the new mkinitcpio. Of course the env var for acpi_osi is not complete, but this is irrelevant.

# set
CMDLINE='root=/dev/disk/by-uuid/4ad49bf5-f44a-4116-8164-704bcecc5c59 ro console=ttyS0 acpi_osi="!Windows 2006" break=y'
...
acpi_osi='"!Windows'
...

@brain0: Just as "proof of concept", but if you considered good, ok and go ahead.

Also attached how look a sample command line.

Anyway, I don't know why this works with the patch: somevar="somevaluewithoutspace". If you try with a separate script, does not work. Weird!

I haven't seen this patch before, sorry.

I was thinking about a different approach: What if we only try to export things that are actually of interest to us and ignore the rest? No idea how to do that yet, but: we are not at all interested in the value of acpi_osi or most of the other stuff passed to the kernel. Basically, we want to know rw, ro, root=, cryptdevice=, crypto= (deprecated), cryptkey=, resume=, break= and very few more that I don't remember now.

IMO, there is no point in adding support for parsing a variable that we will just ignore anyway.

Just thought let's look what other distros do. This is what SuSE does:

# kernel commandline parsing
for o in $(cat /proc/cmdline); do
key="${o%%=*}"
key="${key//-/_}"
if [ "${key%.*}" != "${key}" ]; then # module parameter
add_module_param "${key%.*}" "${o#*.}"
else
# environment variable
# set local variables too, in case somehow the kernel does not do this correctly
value="${o#*=}"
value=${value:=1}
eval cmd_$key="${value}"
eval $key="${value}" 2> /dev/null
fi
done

I don't think they ignore this problem too.

> I haven't seen this patch before, sorry.
No problem.

About only accept needed params, is interesting. Something like: init script with a dynamic and configurable parameters via each install conf hook. So can have a file like ""/init_acepted_parameters"" generated by mkinitcpio. (If and only if is not much complicated with ash :P)

Something like that, yes. Would need changes in all hooks though.

Please confirm that mkinitcpio 0.6.10 fixes the problem.