Arch Linux

I'm not sure the partition being mounted as readonly is the problem actually...

Looks like a problem in sysvinit bootlogd. It is unable to determine the console device.

It's a problem with the initscripts. It should run bootlogd with the -l option to set the logfile to a different location (/run ?)or start the logging after the root partition has been remounted rw.

It doesn't look like that at all to me. It still doesn't work if I specify /run/bootlog as the location to write the logfile. I traced the problem inside the source code to where it tries to locate the console device in the consolename() function:
if (errno != ENOIOCTLCMD) return -1;

This causes the main() function to return with exit code 1.

It works if I comment out that line.

errno is 22 (EINVAL - invalid argument).
This is occurring on two Arch Linux servers i'm running (kernel26-lts 2.6.32.53-1 with root filesystem on mdadm RAID 1).

It's possibles that there are two problems here.

https://bugzilla.novell.com/show_bug.cgi?id=681825
Seems that TIOCGDEV is only supported for kernel >= 2.6.38.

I have tested with the linux 3.1.9-1 and it works fine there.
I think we just need to add a patch to sysvinit package to also support the older kernel used for kernel26-lts.

Fix to support kernel26-lts

If that's the case, then it isn't really worth fixing sysvinit. There is currently a linux-lts 3.0.17 package in testing intended to replace the kernel26-lts package currently in core. Once it'll be moved to core (after required signoff), the problem will disappear by itself.

What about for older kernels in AUR?

@Eric and Jonathan: Thanks for figuring this out!

As Eric noted kernel26-lts is at its EOL, so this problem will solve itself very soon. I don't think it is a good idea to add any patches to fix old kernels, mainly because I don't think we should give the impression that they are at all supported. Using old kernels on new userspace (such as initscripts/sysvinit) is not a good idea. We try to make an exemption for linux-lts, but that's about it.

If you want the problem solved, I think it would be more effective to submit your patch upstream to sysvinit, they probably want to support older kernels (and I'm a bit surprised that this is broken actually).

It could be the reason that it is broken is that it is using newer kernel headers which define TIOCGDEV even though it may not be supported by kernels < 2.6.38.

Upstream bug report: http://savannah.nongnu.org/bugs/index.php?35311