Description of problem: pam_console_apply is no longer needed in rc.sysinit since udev is creating the /dev directory freshly on reboot. This is causing some bogus avc messages.
What happens if you have unclean shutdown, and there's a leftover console lock entry when udev runs on startup?
The pam_console_apply helper doesn't clean up the lock; rc.sysinit will continue to clear the lock, and udev will function as it does now. But calling pam_console_apply to reset permissions on devices which the user might have owned when the reset button was pressed became unnecessary when we made /dev non-persistent.
What I'm trying to say is that the lock is there *when udev starts on boot* from before the reset button was pressed - is udev using this stale information when it recreates the devices?
Oh, I see what you mean now. I don't see any calls to udev in the mkinitrd script. Are we still calling udev before rc.sysinit, or am I missing part of the boot process?
It's at the top of rc.sysinit, but it's before the read/write remount of /, so there could be leftover cruft in /var. I'll test this, just need to get in front of a machine of recent enough vintage.
Yeah, you can't remove it because there could be a stale console.lock file when udev runs.