Parse error at byte 12 (line 1): unexpected token - on boot after kernel upgrade

[Don Mallory]

Good morning,

After applying a kernel upgrade from 2.6.18-194.el5 to 2.6.18-194.26.1.el5, booting results in in the following error:

Activating logical volumes
Parse error at byte 12 (line 1): unexpected token
Failed to load config file /etc/lvm/lvm.conf
Internal error: _vginfos list should be empty

From all accounts, it looks like an LVM problem, but I'm not sure it is. Dropping back to the kernel 2.6.18-194.el5, the host boots fine.

I also thought it might be an issue with changes applied to the lvm.conf, so I put the default (.rpmnew) back in place. No joy as well.

The closest reference article I've found is about recovering the volume entirely: http://linux-prof.homelinux.org/index.php/Lvm_recovery2

But again, I don't really believe this is necessary, as it seems to be kernel related.

Is there a workaround, or patch that should be applied? Perhaps an upgrade of the lvm components or something on the lvols prior to the kernel being applied?

Thanks,
Don

[Matti_Kurkela · Accepted solution]

The kernel does not parse /etc/lvm/lvm.conf: an user-space LVM utility does that.

The "Activating logical volumes" step can occur in at least two times in the boot sequence:
1.) if your root filesystem is on LVM, before mounting the root filesystem
2.) if you have iSCSI disks, after networking and iSCSI have been activated.

If the error happens at step 1), your system startup is managed by initrd at that point.

When a new kernel is installed, a new initrd file is created by the kernel package installation scripts. The initrd file will contain copies of certain essential utilities and configuration files - as they exist at the initrd creation time.

The /etc/lvm/lvm.conf is definitely included in the initrd file. Did you re-create your initrd after returning to the default lvm.conf? If you didn't, the initrd of the new kernel will still be using the old lvm.conf file.

(Your older kernel might be using an even older version of lvm.conf and avoid the error because of that.)

See "man mkinitrd" for examples on re-creating your initrd file.

In cases like this, it might be helpful to extract the contents of the existing initrd file to "dissect" it. Here's the procedure for that:

mkdir /tmp/work_directory
cd /tmp/work_directory
zcat /boot/initrd- | cpio -iv

Within a RHEL 5 initrd, "/init" is a script, run by a stripped-down shell named "nash".

After extracting the initrd of the faulty kernel, check the contents of /tmp/work_directory/etc/lvm/lvm.conf. Pay special attention to the first line of that file: according to the error message, that's where the problem is.

MK

[Don Mallory]

Thank you very much. This showed that the lvm.conf contents were listed as:

dumpconfig -- devices {
dumpconfig -- dir="/dev"
dumpconfig -- scan="/dev"
dumpconfig -- filter="a/.*/"
dumpconfig -- cache="/etc/lvm/.cache"

Instead of:

devices {
dir = "/dev"
scan = [ "/dev" ]
preferred_names = [ ]
filter = [ "a/.*/" ]
cache_dir = "/etc/lvm/cache"

The file was obviously corrupted. The man page on mkinitrd didn't have any examples, but I found info from RedHat's knowledgebase.

mkinitrd -v -f /boot/initrd-2.6.18-194.17.1.el5.img 2.6.18-194.17.1.el5

Works like a dream. Thanks for the help.

Don