Recently I upgraded my laptop to F16 using preupgrade. This morning, at a convention, I did a system update that included (I thought) a new kernel. The next time I booted, the system hung, with no output. I had to power-cycle to try again, this time getting error messages: it couldn't find libcrypt.so.1 and there were a number of failures of systemd-remount-api-vfs. I power-cycled again, and hit the space bar to enter the GRUB menu. There was one F16 kernel, the upgrade, and the latest F14 kernel, which worked.
After several experiments, I found that libcrypt.so.1 is provided by glibc-devel, so I told yum to install it, which brought along some other things I'd thought I'd had. Alas, it didn't fix the boot failure. Although this isn't my main box, I'd like to keep it working as well as I can, and would prefer to be using an F16 kernel if I'm running F16, as I appear to be.
Also, as a side note, I'd tried using the fedorautils and made the mistake of adding the color terminal, finding that I don't like it. How do I reverse this?
Joe Zeff writes:
Recently I upgraded my laptop to F16 using preupgrade. This morning, at a convention, I did a system update that included (I thought) a new kernel. The next time I booted, the system hung, with no output. I had to power-cycle to try again, this time getting error messages: it couldn't find libcrypt.so.1 and there were a number of failures of systemd-remount-api-vfs. I power-cycled again, and hit the space bar to enter the GRUB menu. There was one F16 kernel, the upgrade, and the latest F14 kernel, which worked.
After several experiments, I found that libcrypt.so.1 is provided by glibc-devel,
No, it's not. libcrypt.so.1 is provided by glibc, not glibc-devel.
[mrsam@monster ~]$ rpm -q -f /lib64/libcrypt.so.1 glibc-2.14.90-18.x86_64
Furthermore, if you have a corrupted libcrypt.so.1, it wouldn't matter which kernel you're booting. You wouldn't be able to boot anything. No matter which kernel you boot, you're running the same userspace, and the same set of userspace libraries. If a fundamental, key rpm like glibc is bad, you're bricked, until you fix it in rescue mode.
Unless you're in the business of actually building, and compiling anything, you do not need any -devel package.
so I told yum to install it, which brought along some otherthings I'd thought I'd had. Alas, it didn't fix the boot failure. Although this isn't my main box, I'd like to keep it working as well as I can, and would prefer to be using an F16 kernel if I'm running F16, as I appear to be.
There's no sufficient information to determine what your problem is. But, whatever it is, you have to start with a stable filesystem. That's your starting point. No matter what your problem is, if you have a corrupted filesystem, you're going to spin around in circles. Given that you've experienced boot failures, and hard resets, your first order of business is to stabilize your filesystem.
# touch /forcefsck
Then reboot, using whichever kernel you're able to boot. If your boot starts rhgb and plymouth, press ESC as soon as it comes up, to see the kernel messages. You should see messages that confirm that all your filesystems are getting fsck-ed. The end result is going to be either that fsck was able to repair your filesystems, or not. If not, you have too much damage, and no other option but to wipe and reinstall. fsck might result in an extra reboot, and a second round of fscking, if there was damage to your root filesystem. That's normal, as long as the second time around the job gets done.
If fsck gives you a clean bill of health, and you can boot, the next step is to validate your rpm database. Run 'rpm --rebuilddb'. From this point, you have a stable filesystem, and a good rpm database, and you have a starting point to figure out what's really broken with your overall system. If 'rpm -- rebuilddb' gave you an empty rpm database, or one that's obviously not reflecting reality, you'll pretty much have to reinstall – it's possible to restore it, if you spend some time to gather what you have, and what the rpm database should really show for you, but that'll be very time consuming, and the path of least resistance is a reinstall.
At this point, with a stable filesystem and a good rpm database, you can begin figuring out why you can't boot the latest kernel. The first thing to try would be to remove, and reinstall the kernel rpm, in order to recreate the boot initrd image, and the grub menu entries. It's very possible that, if your problem was a dud initrd, that would fix it.
Keep in mind that if, after a forced fsck (and an rpm rebuild, I suppose), you ended up with an unbootable brick, it wasn't caused by the fsck. You were bricked to start with. All that fsck did was make it obvious.
Also, as a side note, I'd tried using the fedorautils and made the mistake of adding the color terminal, finding that I don't like it. How do I reverse this?
On 11/26/2011 09:10 PM, Sam Varshavchik wrote:
Furthermore, if you have a corrupted libcrypt.so.1, it wouldn't matter which kernel you're booting. You wouldn't be able to boot anything. No matter which kernel you boot, you're running the same userspace, and the same set of userspace libraries. If a fundamental, key rpm like glibc is bad, you're bricked, until you fix it in rescue mode.
First, glibc was one of the things brought it. Second, I don't encrypt anything on this computer. I'll try letting it fsck itself and see what happens.
On 11/26/2011 09:10 PM, Sam Varshavchik wrote:
Furthermore, if you have a corrupted libcrypt.so.1, it wouldn't matter which kernel you're booting
The specific message is that /sbin/sulogin failed because it coulden't find libcrypt.so.1.
I touched /forcefsck and rebooted into the F16 kernel and it hung. Tried again with the F14 and it either ignored the /forcefsck or it'd been nuked by the failed boot. Will try again.
Joe Zeff writes:
On 11/26/2011 09:10 PM, Sam Varshavchik wrote:
Furthermore, if you have a corrupted libcrypt.so.1, it wouldn't matter which kernel you're booting. You wouldn't be able to boot anything. No matter which kernel you boot, you're running the same userspace, and the same set of userspace libraries. If a fundamental, key rpm like glibc is bad, you're bricked, until you fix it in rescue mode.
First, glibc was one of the things brought it. Second, I don't encrypt anything on this computer.
No, you most certainly do. Everyone who installs Fedora ends up encrypting something. I'll bet that all your passwords in /etc/shadow are encrypted, for example. Because that's the kind of things libgcrypt.so.1 is responsible for.
On 11/26/2011 09:27 PM, Sam Varshavchik wrote:
No, you most certainly do. Everyone who installs Fedora ends up encrypting something. I'll bet that all your passwords in /etc/shadow are encrypted, for example. Because that's the kind of things libgcrypt.so.1 is responsible for.
I sit corrected. Thank you. The odd thing is that /sbin/sulogin can't find it if and only if I use the latest kernel. Checking, it's in /lib, which is where I'd expect to find it.
Joe Zeff <joe <at> zeff.us> writes:
On 11/26/2011 09:10 PM, Sam Varshavchik wrote:
Furthermore, if you have a corrupted libcrypt.so.1, it wouldn't matter which kernel you're booting
The specific message is that /sbin/sulogin failed because it coulden't find libcrypt.so.1.
I touched /forcefsck and rebooted into the F16 kernel and it hung. Tried again with the F14 and it either ignored the /forcefsck or it'd been nuked by the failed boot. Will try again.
At boot time stop F16 kernel and append this boot kernel command line param: systemd.unit=rescue.target which should set up the base system and a rescue shell (similar to run level 1), but without sulogin executed.
From there you can run all you can, e.g.
# fsck # package-cleanup --dupes # package-cleanup --problems # rpm -V -a --quiet and whatever else you wish.
When you finish you can leave by: # shutdown -Fr now or # exit
On boot, this time stop as above once again and change that kernel boot option to: systemd.unit=multi-user.target which should bring you to non-GUI login.
After that your system should be yours (debug/investigate it if needed).
JB
Joe Zeff writes:
On 11/26/2011 09:27 PM, Sam Varshavchik wrote:
No, you most certainly do. Everyone who installs Fedora ends up encrypting something. I'll bet that all your passwords in /etc/shadow are encrypted, for example. Because that's the kind of things libgcrypt.so.1 is responsible for.
I sit corrected. Thank you. The odd thing is that /sbin/sulogin can't find it if and only if I use the latest kernel. Checking, it's in /lib, which is where I'd expect to find it.
sulogin is only used when you're dropping into single user mode. Why would you be dropping into single user mode, if you select the newest kernel for booting.
Again, I'd suggest uninstalling the most recent kernel, and reinstalling it, in order to regenerate the initrd, and the grub menu item for it, afresh.
On 11/27/2011 04:09 AM, JB wrote:
From there you can run all you can, e.g. # fsck # package-cleanup --dupes # package-cleanup --problems # rpm -V -a --quiet and whatever else you wish
I suspect that things aren't quite as bad as you think; I'm using the "badly corrupted" computer right now and all seems well as long as I don't boot into the most recent kernel. Still, I'll try some of this after I get home from the convention and have time to play with it. Thanx for your suggestions.
On 11/27/2011 06:13 AM, Sam Varshavchik wrote:
Again, I'd suggest uninstalling the most recent kernel, and reinstalling it, in order to regenerate the initrd, and the grub menu item for it, afresh.
That's probably the best idea of all. I don't remember your mentioning it before and don't have time for it now, but I'll do that after I get home.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/27/2011 10:19 AM, Joe Zeff wrote:
On 11/27/2011 06:13 AM, Sam Varshavchik wrote:
Again, I'd suggest uninstalling the most recent kernel, and reinstalling it, in order to regenerate the initrd, and the grub menu item for it, afresh.
That's probably the best idea of all. I don't remember your mentioning it before and don't have time for it now, but I'll do that after I get home.
You may want to run "yum reinstall <kernel version>" instead. I am not 100% sure, but it should generate a new initrd.
Mikkel - --
Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
On 11/27/2011 05:05 PM, Mikkel L. Ellertson wrote:
You may want to run "yum reinstall<kernel version>" instead. I am not 100% sure, but it should generate a new initrd.
I've just gotten home and haven't had time to bring in everything (too tired) let alone set up my laptop. However, man yum has this to say about reinstall:
Will reinstall the identically versioned package as is currently installed. This does not work for "installonly" packages, like Kernels. reinstall operates on groups, files, provides and filelists just like the "install" command.
Nice idea, though, and thanx for the thought.
On 11/27/2011 06:13 AM, Sam Varshavchik wrote:
Again, I'd suggest uninstalling the most recent kernel, and reinstalling it, in order to regenerate the initrd, and the grub menu item for it, afresh.
More information, now that I'm home again and have time to dig into this. I went back into the yum history and found the update in question. It included this line in the list of updates:
Install kernel-PAE-3.1.2-1.fc16.i686
At the bottom was this:
Scriptlet output: 1 grubby fatal error: unable to find a suitable template 2 grubby fatal error: unable to find a suitable template 3 grubby: doing this would leave no kernel entries. Not writing out new config.
I'm not sure what went wrong, or where, but I don't think that uninstalling and reinstalling that kernel will make any difference, at least until the grubby issue is corrected.
Joe Zeff writes:
On 11/27/2011 06:13 AM, Sam Varshavchik wrote:
Again, I'd suggest uninstalling the most recent kernel, and reinstalling it, in order to regenerate the initrd, and the grub menu item for it, afresh.
More information, now that I'm home again and have time to dig into this. I went back into the yum history and found the update in question. It included this line in the list of updates:
Install kernel-PAE-3.1.2-1.fc16.i686
At the bottom was this:
Scriptlet output: 1 grubby fatal error: unable to find a suitable template 2 grubby fatal error: unable to find a suitable template 3 grubby: doing this would leave no kernel entries. Not writing out new config.
If you upgraded from F15, grubby is complaining about the old grub.cfg. This is harmless. rm /etc/grub.cfg to make this complaint go away.
I'm not sure what went wrong, or where, but I don't think that uninstalling and reinstalling that kernel will make any difference, at least until the grubby issue is corrected.
As log as grubby did its job with grub2, there is no issue.
If grubby is having a problem with grub2, using grub2-mkconfig should fix it.
On 12/01/2011 04:02 AM, Sam Varshavchik wrote:
If you upgraded from F15, grubby is complaining about the old grub.cfg. This is harmless. rm /etc/grub.cfg to make this complaint go away.
No, from F14, but the point's still good. As to the other, I'll try it as soon as I have time, then report back. Thanx.
On 12/01/2011 04:02 AM, Sam Varshavchik wrote:
As log as grubby did its job with grub2, there is no issue.
If grubby is having a problem with grub2, using grub2-mkconfig should fix it.
More thoughts. Remember, Sam, that I can't boot into the new kernel so there might be an issue. (I just remembered that the laptop hung on shutdown after that update, forcing me to use the power button and that's very much not normal.)
I take it that you suggest getting rid of that file in /etc, re-running grub2-mkconfig and trying to boot again into the new kernel?
On Thu, 2011-12-01 at 12:17 -0800, Joe Zeff wrote:
On 12/01/2011 04:02 AM, Sam Varshavchik wrote:
As log as grubby did its job with grub2, there is no issue.
If grubby is having a problem with grub2, using grub2-mkconfig should fix it.
More thoughts. Remember, Sam, that I can't boot into the new kernel so there might be an issue. (I just remembered that the laptop hung on shutdown after that update, forcing me to use the power button and that's very much not normal.)
I take it that you suggest getting rid of that file in /etc, re-running grub2-mkconfig and trying to boot again into the new kernel?
Can you boot into rescue mode from install media (don't forget to enable the network) and mount the filesystems?
chroot /mnt/sysimage ; then try another yum update see if a newer kernel yet will fix things.
On 12/01/2011 12:38 PM, Terry Polzin wrote:
Can you boot into rescue mode from install media (don't forget to enable the network) and mount the filesystems?
chroot /mnt/sysimage ; then try another yum update see if a newer kernel yet will fix things.
Why? I can, and do boot into the last working kernel from F14 just fine. And, no, there's not been a new kernel in the last few days.
Joe Zeff writes:
On 12/01/2011 04:02 AM, Sam Varshavchik wrote:
As log as grubby did its job with grub2, there is no issue.
If grubby is having a problem with grub2, using grub2-mkconfig should fix it.
More thoughts. Remember, Sam, that I can't boot into the new kernel so there might be an issue. (I just remembered that the laptop hung on shutdown after that update, forcing me to use the power button and that's very much not normal.)
I take it that you suggest getting rid of that file in /etc, re-running grub2-mkconfig and trying to boot again into the new kernel?
The warning from grubby can be due either to grubby choking on grub.cfg, old grub 1 config file, which is not needed any more, or if grubby can't figure out what to do with grub2. grubby, when told to do its thing, will check to see if either grub 1 or grub 2 is installed, and run through both of them.
It's not clear if your grubby warnings are due to the old grub 1 config, or the current grub 2 config. If it's grub 1, deleting grub.cfg will shut grubby up. If it's grub 2, I found that rerunning grub2-mkconfig generates a new grub 2 config file that will make grubby happy, going from that point on.
On 12/01/2011 02:15 PM, Sam Varshavchik wrote:
It's not clear if your grubby warnings are due to the old grub 1 config, or the current grub 2 config. If it's grub 1, deleting grub.cfg will shut grubby up. If it's grub 2, I found that rerunning grub2-mkconfig generates a new grub 2 config file that will make grubby happy, going from that point on.
When I have the time, I'll nuke that file as you suggested and re-run grub2-mkconfig. If there aren't any error messages, I'll reboot into the new kernel and see what happens. If nothing else, we'll have more information to go on.
On 11/27/2011 06:13 AM, Sam Varshavchik wrote:
Again, I'd suggest uninstalling the most recent kernel, and reinstalling it, in order to regenerate the initrd, and the grub menu item for it, afresh.
More info, now that I've had the time to play with my laptop. First, the kernel in question is 3.1.2-1.fc16.i686.PAE. Second, /etc/grub.conf is simply a link to the file in /boot/grub and third, /boot/grub2/grub.cfg was a zero byte file. Simply running grub2-mkconfig streamed the new file to stdout; checking, I needed to add the switch -o /boot/grub2/grub.cfg to have it write the new file out. Alas, rebooting to the new kernel didn't work. Aside from uninstall/reinstall, are there any other suggestions?
On 11/27/2011 06:13 AM, Sam Varshavchik wrote:
Again, I'd suggest uninstalling the most recent kernel, and reinstalling it, in order to regenerate the initrd, and the grub menu item for it, afresh.
I used yumex to do a full update on my laptop, having it remove the most recent kernel as well. Then, after making sure that /boot/grub/grub.conf was current, I had it install the most recent kernel again. The kernel showed up again, correctly and there was a new /boot/grub2/grub.cfg written during the install.
I tried rebooting to the new kernel. The teardrop appeared, and vanished, followed by a long list of reports from systemd. Then, SELinux reported that it needed to relabel things, warning that it might take a long time, followed by a report that it was building the volatile files and directories. It sat there, with no disk activities for about ten minutes, when I tried again with the same results. As always, booting into the last good F14 kernel works exactly as it should. (As far as I can tell, no SELinux relabeling needed under that kernel.)
I don't want to set up a kickstart file to make sure that my UserID stays at 500, and to get the rest of my programs properly installed but it seems like that might be the only way to fix this. And, of course, I need to upgrade my desktop before F14 reaches EOL, but what's been going on with my laptop makes me worry because I need to have at least one of them up and running properly.
Currently, the laptop goes into emergency mode and hangs two out of three times if I use the newest kernel. The third time it continues until it says that SELinux needs to relabel things and that it might take a while. Then it just sits with no disk activity until I power cycle it. If I try booting from the old F14 kernel, it's a Ronson: "first time, every time." No trouble booting.
One of the things worrying me now is that I have three kernels: the newest, the upgrade kernel and the old, working one. I'd like to get rid of the upgrade kernel, safely, so that the next kernel update doesn't nuke the only working one I currently have. Anybody know how?
On Mon, 2011-12-05 at 13:37 -0800, Joe Zeff wrote:
Currently, the laptop goes into emergency mode and hangs two out of three times if I use the newest kernel. The third time it continues until it says that SELinux needs to relabel things and that it might take a while. Then it just sits with no disk activity until I power cycle it. If I try booting from the old F14 kernel, it's a Ronson: "first time, every time." No trouble booting.
One of the things worrying me now is that I have three kernels: the newest, the upgrade kernel and the old, working one. I'd like to get rid of the upgrade kernel, safely, so that the next kernel update doesn't nuke the only working one I currently have. Anybody know how?
---- I am under the impression that you can change the 'installonly_limit' value in /etc/yum.conf (of which kernel is definitely one of those) but to be honest, I've never tinkered with it.
Craig
On 12/05/2011 05:57 PM, Craig White wrote:
I am under the impression that you can change the 'installonly_limit' value in /etc/yum.conf (of which kernel is definitely one of those) but to be honest, I've never tinkered with it.
I've also heard that, but wasn't sure just where it was. I wonder if it would be safe to edit grub.conf by moving the upgrade kernel to the bottom and rebuilding grub.cfg so that if there's another kernel update before I get this fixed, the working kernel isn't nuked.
Also, somebody on fedoraforum says that if you upgrade by yum (I used preupgrade) it installs grub2 but doesn't actually activate it. You have to do that part yourself. Do you know anything about this?
Joe Zeff <joe <at> zeff.us> writes:
Currently, the laptop goes into emergency mode and hangs two out of three times if I use the newest kernel. The third time it continues until it says that SELinux needs to relabel things and that it might take a while.
Change selinux config to this (for the time being): # cat /etc/sysconfig/selinux ... # SELINUX=enforcing SELINUX=disabled ...
...
One of the things worrying me now is that I have three kernels: the newest, the upgrade kernel and the old, working one. I'd like to get rid of the upgrade kernel, safely, so that the next kernel update doesn't nuke the only working one I currently have. Anybody know how?
To remove an unneeded kernel: # yum list installed "*kernel*" ... kernel.i686 3.1.1-1.fc16 @updates ... # yum remove "*kernel*3.1.1-1.fc16*"
Now, reboot your system to your latest F16 kernel and see what happens. JB
On 12/06/2011 06:13 AM, JB wrote:
To remove an unneeded kernel: # yum list installed "*kernel*" ... kernel.i686 3.1.1-1.fc16 @updates ... # yum remove "*kernel*3.1.1-1.fc16*"
Now, reboot your system to your latest F16 kernel and see what happens.
Already did that and it didn't help. Thanx anyway. And as far as the SELinux issue goes, it doesn't seem to be noticed unless I try to boot into the latest kernel.
On Tue, 2011-12-06 at 10:52 -0800, Joe Zeff wrote:
On 12/06/2011 06:13 AM, JB wrote:
To remove an unneeded kernel: # yum list installed "*kernel*" ... kernel.i686 3.1.1-1.fc16 @updates ... # yum remove "*kernel*3.1.1-1.fc16*"
Now, reboot your system to your latest F16 kernel and see what happens.
Already did that and it didn't help. Thanx anyway. And as far as the SELinux issue goes, it doesn't seem to be noticed unless I try to boot into the latest kernel.
Is there an error is /etc/sysconfig/selinux?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/06/2011 02:44 PM, Joe Zeff wrote:
On 12/06/2011 11:31 AM, Terry Polzin wrote:
Is there an error is /etc/sysconfig/selinux?
No.
SELinux relabeling is caused by booting a rescue mode kernel. As soon as you boot a system with SELinux disabled, the init system creates the /.autorelabel file, so the next time it boots with SELinux it will relabel.
Daniel J Walsh <dwalsh <at> redhat.com> writes:
... SELinux relabeling is caused by booting a rescue mode kernel. As soon as you boot a system with SELinux disabled, the init system creates the /.autorelabel file, so the next time it boots with SELinux it will relabel.
Question: Are you not setting yourself up for trouble with this /.autorelabel here ?
Case: - I disable selinux # cat /etc/sysconfig/selinux ... SELINUX=disabled - I reboot the system, - /.autorelabel created by sys init, - I enable selinux again, - I reboot with intention to boot rescue mode kernel (obviously because I assume there is some problem to fix; it would make sense to boot to the same system state that caused me to want it have investigated or fixed, without e.g. any potential interruption or fs changes, perhaps from selinux doing relabeling), - Selinux jumps in with relabeling (potential interference/change to system state as described above, it may not even finish its job, and so I am stuck and unable to fix the system, now and possibly on next attempt as well).
Do you see a problem here ?
JB
On Tuesday 06 December 2011 22:16:40 JB wrote:
Daniel J Walsh <dwalsh <at> redhat.com> writes:
... SELinux relabeling is caused by booting a rescue mode kernel. As soon as you boot a system with SELinux disabled, the init system creates the /.autorelabel file, so the next time it boots with SELinux it will relabel.
Question: Are you not setting yourself up for trouble with this /.autorelabel here ?
Case:
- I disable selinux # cat /etc/sysconfig/selinux ... SELINUX=disabled
- I reboot the system,
- /.autorelabel created by sys init,
- I enable selinux again,
- I reboot with intention to boot rescue mode kernel (obviously because I
assume there is some problem to fix; it would make sense to boot to the same system state that caused me to want it have investigated or fixed, without e.g. any potential interruption or fs changes, perhaps from selinux doing relabeling), - Selinux jumps in with relabeling (potential interference/change to system state as described above, it may not even finish its job, and so I am stuck and unable to fix the system, now and possibly on next attempt as well).
Do you see a problem here ?
I see a problem with a second-to-last step in your list.
If you have a broken system which needs rescuing, and it has SELinux disabled to begin with, why would you want to enable it just before getting into rescue mode?
And if you actually do have a reason to enable it and then rescue the system, you'd better let it relabel, or else you are in for a very fun ride with your rescue operation...
This is one of the reasons why I don't like the option to disable SELinux completely. If you leave it in permissive mode, it will keep out of your way while keeping proper file labelling. Thus no problems can arise if you ever want to enforce SELinux again.
Disabling SELinux completely makes sense only on HPC clusters and similar, where every bit of CPU time should be squeezed out, where SELinux has a nontrivial CPU/FS footprint, and where security is not an issue so that its footprint is useless. The rule of thumb is --- disable SELinux only on systems where you are absolutely certain that you will never ever ever want to reenable it again. On everything else keep it in enforcing or permissive, and you won't get into inconvenient-relabeling-time problems.
HTH, :-) Marko
Marko Vojinovic <vvmarko <at> gmail.com> writes:
...
Case:
- I disable selinux # cat /etc/sysconfig/selinux ... SELINUX=disabled
- I reboot the system,
- /.autorelabel created by sys init,
- I enable selinux again,
- I reboot with intention to boot rescue mode kernel (obviously because I
assume there is some problem to fix; it would make sense to boot to the same system state that caused me to want it have investigated or fixed, without e.g. any potential interruption or fs changes, perhaps from selinux doing relabeling), - Selinux jumps in with relabeling (potential interference/change to system state as described above, it may not even finish its job, and so I am stuck and unable to fix the system, now and possibly on next attempt as well).
Do you see a problem here ?
I see a problem with a second-to-last step in your list.
If you have a broken system which needs rescuing, and it has SELinux disabled to begin with, why would you want to enable it just before getting into rescue mode?
Yes, indeed, but it is not impossible. I wanted to re-play (mechanically) a case reflecting Daniel's description. And it seems to show a weak point.
And if you actually do have a reason to enable it and then rescue the system, you'd better let it relabel, or else you are in for a very fun ride with your rescue operation...
That may be true on the surface, but as I already stated there is a danger in selinux not finishing or getting stuck, altering system state to be "rescued" (investigated or fixed).
...
Yes, your other remarks regarding selinux are valid.
JB
JB <jb.1234abcd <at> gmail.com> writes:
...
To make my point clear.
In general, the resuce mode turns all services off for the purpose of preserving the original troubled environment (machine state) and preventing any worsening of it until it can be investigated or fixed.
So it seems a rescue mode should not allow execution of selinux relabeling right before it, under any circumstances.
JB
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/07/2011 03:14 AM, JB wrote:
JB <jb.1234abcd <at> gmail.com> writes:
...
To make my point clear.
In general, the resuce mode turns all services off for the purpose of preserving the original troubled environment (machine state) and preventing any worsening of it until it can be investigated or fixed.
So it seems a rescue mode should not allow execution of selinux relabeling right before it, under any circumstances.
JB
My understanding is when you are in rescue mode SELinux should be disabled and no relabeling should take place. What does happen is the flag gets set (/.autorelabel). So theoretically when you reboot the machine with SELinux enabled, the first thing it will do is make sure all the labels are correct so SELinux will work properly. If you see a system that you boot in rescue mode trying to relabel, then I would guess this is a bug.
Daniel J Walsh <dwalsh <at> redhat.com> writes:
On 12/07/2011 03:14 AM, JB wrote:
JB <jb.1234abcd <at> gmail.com> writes:
...
To make my point clear.
In general, the resuce mode turns all services off for the purpose of preserving the original troubled environment (machine state) and preventing any worsening of it until it can be investigated or fixed.
So it seems a rescue mode should not allow execution of selinux relabeling right before it, under any circumstances.
JB
My understanding is when you are in rescue mode SELinux should be disabled and no relabeling should take place. What does happen is the flag gets set (/.autorelabel). So theoretically when you reboot the machine with SELinux enabled, the first thing it will do is make sure all the labels are correct so SELinux will work properly. If you see a system that you boot in rescue mode trying to relabel, then I would guess this is a bug.
OK. We are on the same page with regard to the principle: In rescue mode SELinux should be disabled and no relabeling should take place.
But the issue is how to enforce it. You say "should be", but I showed in that Case scenario that I constructed few posts above that SELinux can be enabled by chance (sysadmin is doing her job, there are problems, boom, ...), followed by reboot to rescue mode, which gets preceded by actual relabeling due to SELinux being enabled as above.
I would like to see it enforced "the hard way", so that the principle does not get violated by chance or even intention (at least easily via selinux config file or manual entry).
I thought about using unit file directive(s) to do that, making relabeling serice and emergency or rescue services (targets) mutually exclusive.
I am not an expert on systemd :-) but it seems that Conflicts= and ConflictedBy= can do the job.
Can that be done ?
JB
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/07/2011 09:53 AM, JB wrote:
Daniel J Walsh <dwalsh <at> redhat.com> writes:
On 12/07/2011 03:14 AM, JB wrote:
JB <jb.1234abcd <at> gmail.com> writes:
...
To make my point clear.
In general, the resuce mode turns all services off for the purpose of preserving the original troubled environment (machine state) and preventing any worsening of it until it can be investigated or fixed.
So it seems a rescue mode should not allow execution of selinux relabeling right before it, under any circumstances.
JB
My understanding is when you are in rescue mode SELinux should be disabled and no relabeling should take place. What does happen is the flag gets set (/.autorelabel). So theoretically when you reboot the machine with SELinux enabled, the first thing it will do is make sure all the labels are correct so SELinux will work properly. If you see a system that you boot in rescue mode trying to relabel, then I would guess this is a bug.
OK. We are on the same page with regard to the principle: In rescue mode SELinux should be disabled and no relabeling should take place.
But the issue is how to enforce it. You say "should be", but I showed in that Case scenario that I constructed few posts above that SELinux can be enabled by chance (sysadmin is doing her job, there are problems, boom, ...), followed by reboot to rescue mode, which gets preceded by actual relabeling due to SELinux being enabled as above.
I would like to see it enforced "the hard way", so that the principle does not get violated by chance or even intention (at least easily via selinux config file or manual entry).
I thought about using unit file directive(s) to do that, making relabeling serice and emergency or rescue services (targets) mutually exclusive.
I am not an expert on systemd :-) but it seems that Conflicts= and ConflictedBy= can do the job.
Can that be done ?
JB
I thought the rescure kernel would boot with selinux=0. I am no expert on systemd either. Perhaps should discuss on systemd list.
On 11/27/2011 06:13 AM, Sam Varshavchik wrote:
Again, I'd suggest uninstalling the most recent kernel, and reinstalling it, in order to regenerate the initrd, and the grub menu item for it, afresh.
I haven't quite done that, but I have something new to report. The following is quoted from a post on fedoraforum.org, to avoid retyping:
I just now noticed something that might be significant: if I boot from either of the fc16 kernels, boot gets to:
Started Loading Random Seed
then goes back to:
Starting LSB
and this time it hands when it's trying a second time to recreate the Volatile Files and Directories. Also, in my current grub2.cfg, there are two inetrd lines for each fc16 kernel, but if I take either out by boot-time editing, it fails even worse.
-
Craig White -
Daniel J Walsh -
JB -
Joe Zeff -
Marko Vojinovic -
Mikkel L. Ellertson -
Sam Varshavchik -
Terry Polzin