Arch Linux

Can you please provide ANY information? I don't even know where to start asking, as your report essentially contains nothing.

Maybe we can start with the symptoms: I need the full contents of the screen when the panic occurs.

Hello, please detail the contents of your mkinitcpio.conf and of course, the kernel panic message details, otherwise nobody can work on that issue.

I see this on a system that is EFI booted from Grub 2 (bzr build) to kernel26-2.6.38.1

:: Loading Initramfs
:: Starting udevd...
done.udev[45]: starting version 166

/init: eval: line 1: syntax error: unexpected "("
Kernel panic - not syncing: Attempted to kill init!
Pid:1, comm init Not tainted 2.6.38-ARCH #1


I downgraded to core/mkinitcpio-0.6.8-2 and it worked. mkinitcpio.conf is below (comments removed)

MODULES="ahci libahci ehci-hcd ext2 btrfs vfat crc32c"
BINARIES=""
FILES=""
HOOKS="base udev autodetect scsi sata btrfs filesystems"

Thanks, this is very useful. I also need the contents of /proc/cmdline to debug this.

EDIT: Hm, you are not the original reporter. I feel confident that he experiences the same problem though.

Btw, this is most likely the offending commit that introduced the 'eval' statements: https://projects.archlinux.org/mkinitcpio.git/commit/?id=42e8dba5dce4879e4a372c5c2fb5446b4e8bb16c

From a working boot with 0.6.8-2:
BOOT_IMAGE=(hd0,gpt4)/vmlinuz26 root=/dev/sda6 rootfstype=btrfs ro

Thanks. Let me see what I can come up with. Parsing this BOOT_IMAGE part is redundant anyway.

Well, trying to update to 2.6.38.2 with another try of mkinitcpio 0.6.9 this time SHOWED me a kernel panic (before I had blank screen):

input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0
/init: eval: line 1: syntax error: unexpected "("
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: init Not tainted 2.6.38-ARCH #1
Call Trace:
[<ffffffff813a90d0>] ? panic+0x9b/0x1a8
[<ffffffff8105cc04>] ? do_exit+0x8a4/0x8b0
[<ffffffff8105cf4f>] ? do_group_exit+0x3f/0xa0
[<ffffffff8105cfc2>] ? sys_exit_group+0x12/0x20
[<ffffffff8100ae12>] ? system_call_fastpath+0x16/0x1b

Again, rescuebooting LTS and downgrading mkinitcpio to 0.6.8-2 and another mkinitcpio -p kernel26 fixed this for me.

Thanks. This is indeed the same problem as described by smartcat99s. I'll have it fixed in the next few days, please stay with mkinitcpio 0.6.8 until then.

I had the same problem with grub2-efi-x86_64. The grub2 devs at #grub in freenode pointed out the problem in /init in the initramfs. The problem is the linux command line uses

linux (hd0,gpt4)/vmlinuz26 root=/dev/sda3 rootfstype=ext4 ro nomodeset
initrd (hd0,gpt4)/kernel26.img

Using

set root=(hd0,gpt4)
linux /vmlinuz26 root=/dev/sda3 rootfstype=ext4 ro nomodeset
initrd /kernel26.img

corrected the problem (ie. no brackets in the kernel commandline, otherwise /init in the initramfs fails). Dave (falconindy) pointed out http://projects.archlinux.org/mkinitcpio.git/commit/?id=42e8dba5dce4879e4a372c5c2fb5446b4e8bb16c commit to be the exact cause of the problem.

I already know where the problem is and I pointed out that commit in an earlier comment. I also have a solution in mind (which also might solve some other bugs). I just need to implement it, which probably won't happen before Monday.

Can one of you confirm that this helps? https://projects.archlinux.org/mkinitcpio.git/commit/?id=977583e34d21d59493fe71bf2f94bfe185673fa7

Yes, I no longer crash with that commit applied.

I can confirm this as well. Using grub2-bios
Installed from Archboot CD, but I suspect this may be true for grub2-bios in general...
It automatically setup my /boot/grub/grub.cfg as so (this is only from memory so maybe not completely right):

# (0) Arch Linux
menuentry "Arch Linux" {
search --label --no-floppy --set=root boot
linux $(boot)/vmlinuz26 root=/dev/sda3 rootflags=,subvol=master,compress=lzo rootfstype=btrfs ro radeon.modeset=1 quiet init=/bin/systemd
initrd /kernel26.img

The auto-search thing worked before one of the latest upgrades...then I got the same error as above. the '(' caused kernel panic. Fixed by simply removing the search line and the $(boot)

Please confirm that mkinitcpio 0.6.10 fixes the problem.

Sorry, to say so, but I can't confirm it.
After installing 0.6.10-1, doing a mkinitcpio -p kernel26 (I use x86_64), I got again after a reboot the kernel panic ...
panic
do_exit
do_group_exit
sys_exit_group
system_call_fastpath

Okay, I reintroduced the bug while fixing another one (should have done more testing here), this commit is the bad guy: https://projects.archlinux.org/mkinitcpio.git/commit/?id=d1264eb145c0aa0adc219dfb71fa5d7acc4e26ff

The eval is again the problem, I'll need to do more to fix this entirely.

@thomas: Your original work with export was "correct". I didn't understand why you switched to eval. eval is evil and will strip quotes, mangle data, and kick your cat.

So, I think that we need to enforce usage of octal escapes for spaces (similar to fstab), otherwise there's no sane way of parsing strings. /usr/bin/printf as well as busybox's printf both support the %b formatter mentioned below in the SO link.

http://stackoverflow.com/questions/993452/splitting-proc-cmdline-arguments-with-spaces

The 'export' is not correct, we don't want to fill the environment with useless variables.

I'm trying to pin down where the environment is cleared between initcpio and agetty, but I'm not having much luck (though I suspect its in init). The bottom line is that my current initcpio still uses export and _none_ of the variables exported during the initcpio's pid 1 make it down to my environment on the cmdline. Where are you seeing this pollution?

Karl, sorry for the delay. Can you apply the attached patch on top of mkinitcpio 0.6.10 and try? This should really fix it for good.

The first one had a small mistake, use this one instead.

patch /sbin/mkinitcpio < fix-parse-cmdline.patch
patching file /sbin/mkinitcpio
Hunk #1 FAILED at 31.
1 out of 1 hunk FAILED -- saving rejects to file /sbin/mkinitcpio.rej

That's what I got, trying to patch it with the 3.2 KiB patch. Am I patching it the wrong way?

This patch applies to /lib/initcpio/init_functions, not /sbin/mkinitcpio.

Done. Okay, I'm using mkinitcpio - in around 10 mins, you should get my answer, if it works. -.^

Thank you very much, Thomas. It's four times a go.
Tested it first successfully with kernel26 x86_64.
After that I tested also:
kernel26-lts x86_64
kernel26-mainline x86_64
kernel26-lqx x86_64
and last but not least ...
kernel26 i686 (on my wifes netbook).
It's a solution - and it works!

Great. I should be able to push 0.6.11 pretty soon then (which can finally move to core).