Comment 7 for bug 399954

> Firstly we call "ifup" from udev for most standard network devices, and this happens very early in the boot sequence. At this point the /var/run/utmp file doesn't exist, so runlevel will output that error and exit because it can't find the file.

Yes, and it is because of udev calling dhclient that all these shenanigans are needed-- the profile must be loaded before dhclient is started otherwise it is unconfined.

> Secondly "runlevel" inherently returns undefined data when running through rcS.d, because you have not yet entered a runlevel. rcS.d is not the "single-user runlevel", it is the sysinit phase; until this is completed, you are neither in single-user mode *or* multi-user mode. You're still bootstrapping the system.

I am aware of that. The point of:

while [ ! -e "$AAPROFILES" ]; do
    # If apparmor is not loaded by the time we leave rcS, we go into S from
    # another runlevel, or are in a non-S runlevel, just exit
    runlevel | grep -E -q '( [0-9]|[0-9] S)' && exit 0
    sleep 1
done

was to quietly wait around for AAPROFILES to show up, or exit if they didn't by the time we went into a numbered runlevel or went into S (I observed going into 'S' was needed when testing this on Jaunty, though I don't recall why off-hand). Due to the silent waiting, this coped with /var/run being a tmpfs just fine (ie it waited). This technique had the added benefit of working even if a big fsck occurred on /.

I thought that entering single user mode would result in 'S 1', but I'll take your word that it does not.

That said, while this did work on Jaunty just fine in my testing (and the lack of bug reports bears this out), it is clearly too brittle and I'll need to rethink it.