Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#26119 - [mkinitcpio] ash: closing paren expected

Attached to Project: Arch Linux
Opened by Mantas Mikulėnas (grawity) - Monday, 26 September 2011, 13:29 GMT
Last edited by Dave Reisner (falconindy) - Wednesday, 05 October 2011, 00:13 GMT
Task Type Bug Report
Category Arch Projects
Status Closed
Assigned To Thomas Bächler (brain0)
Dave Reisner (falconindy)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Very early during boot, the following line appears:

ash: closing paren expected

This is before *anything* else, even before the "Starting udev" message. The system boots normally otherwise.

This might be caused by my kernel command line, which is:

BOOT_IMAGE=(hd0,gpt2)/vmlinuz-linux root=/dev/disk/by-label/rainroot ro init=/bin/systemd irqpoll pcie_aspm=force

The "BOOT_IMAGE=(hd0,gpt2)/vmlinuz-linux" part is added automatically by the grub2 bootloader.

initscripts 2011.07.3-1
mkinitcpio 0.7.2-1
This task depends upon

Closed by  Dave Reisner (falconindy)
Wednesday, 05 October 2011, 00:13 GMT
Reason for closing:  Fixed
Additional comments about closing:  mkinitcpio 0.7.3
Comment by Gerardo Exequiel Pozzi (djgera) - Monday, 26 September 2011, 15:09 GMT
  • Field changed: Summary ([initscripts/?] ash: closing paren expected → [mkinitcpio] ash: closing paren expected)
  • Field changed: Status (Unconfirmed → Assigned)
  • Field changed: Category (Packages: Core → Arch Projects)
  • Task assigned to Thomas Bächler (brain0), Dave Reisner (falconindy)
This is caused by ( ) in init_functions:parse_cmdline() at if [ "${rhs:0:1}" = "\"" ]; then

+ [ ( = " ]
ash: closing paren expected
Comment by Jakob Matthes (jakobm) - Monday, 26 September 2011, 15:17 GMT
Yes, it is your cmdline. parse_cmdline from init_functions (mkinitcpio) is the corresponding function.
Comment by Dave Reisner (falconindy) - Monday, 26 September 2011, 15:26 GMT
The expression should be reversed so that the constant is on the left hand side:

$ w='(hd0,gpt2)/vmlinuz-linux'
$ rhs="$(echo "${w}" | cut -d= -f2-)"
$ [ "\"" = "${rhs:0:1}" ]
$ echo $?
1
Comment by Thomas Bächler (brain0) - Monday, 26 September 2011, 15:26 GMT
This must be a regression in busybox. I am pretty sure I tested all this crap in ash extensively - and this works in bash.

Still, this shows that errors in parse_cmdline are no longer fatal, which is a win.
Comment by Thomas Bächler (brain0) - Monday, 26 September 2011, 15:27 GMT
@Dave: This is confusing, but I'd be happy if it helps.
Comment by Dave Reisner (falconindy) - Monday, 26 September 2011, 15:31 GMT
Not sure if this is a regression, but I am somewhat surprised that this fails, given the history of grub2 based bug reports about our cmdline parsing. For what its worth, this fails in Dash as well, with the same fix necessary. The left and right hand sides of an expression are _not_ treated equally in POSIX shells, as you can see here. Another equally awful and POSIX looking solution would be to prefix each side with a dummy value, i.e.

[ "x${rhs:0:1}" = "x\"" ]

This prevents the parser from doing stupid things.
Comment by Thomas Bächler (brain0) - Monday, 26 September 2011, 15:42 GMT
I reversing the arguments helps, I would prefer to not do the stupid-looking "x$foo" solution.
Comment by Dave Reisner (falconindy) - Monday, 26 September 2011, 18:06 GMT
Pushed to my devel branch:

https://github.com/falconindy/mkinitcpio/commit/8aabf1bd
Comment by Dave Reisner (falconindy) - Wednesday, 05 October 2011, 00:13 GMT
Fixed: http://projects.archlinux.org/mkinitcpio.git/commit/?id=575c9c458264ca4e507a6a08eb104de5d1255556

Loading...