On 11/04/2011 01:15 PM, Colin Guthrie wrote:
'Twas brillig, and Frank Griffin at 04/11/11 17:09 did gyre and gimble:
To follow up, I just did a fresh install, and the new system doesn't
have the problem, so it looks like an upgrade issue. I have the failing
partition still on the side if you need any info....
There is indeed a bug in the rc.sysinit as JA Magallon said.
As the fresh install is using systemd, it likely masked the problem.
If you update the failing partition to the latest initscripts I've just
submitted and retest it that would be great.
If it doesn't boot enough to be able to install packages easily enough,
you could either.
a) mount that partition from another install and use rpm --root to
install the new package, or.
b) Boot it with init=/bin/systemd on kernel cmd line which will
hopefully be enough to boot and then update packages and then reboot
without systemd to test it.
Hope that makes sense and sorry for the hassle.
Actually, I spoke too soon. The fresh install didn't exhibit the
problem, but after I ran my post-install customization script and
rebooted, it did.
I'll try to update initscripts.
One of the things my script does is create a couple of symlinks in
/etc/init.d to initscripts of my own, and issue chkconfig --add /
chkconfig on for them. Might this cause the problem ?
The other thing I notice is that if I Magic-R-S-E, VC1 (which was hung
with console messages) clears and a getty prompt comes up. I'm able to
log on as root, but the root fs is mounted read-only. That might be the
cause of the "cannot allocate" errors. A df shows that none of my fstab
mounts are there, so /tmp would be the /tmp in the rootfs (and not a tmpfs).
