It's probably not something you should do. I don't know what Ubuntu's official stance would be, but my experience has been that it's not the best thing to run apt-get dist-upgrade from a recovery kernel. There are a few things missing, even if you mount the root partition:
- /dev, /proc, /sys and the gang are all there, but only sort of. And /var/run? Well, not really this go-around, if you're using 14.04 LTS.
- Upstart didn't run from this root, so there is no Upstart. Anything that needs to deal with Upstart (like, evidently, libpam-systemd) will fail.
- If something is broken, it might get more broken if you run updates in recovery.
Still, it may become necessary. There might even be some failures that look semi-legit but are certainly not going to help you back to a working system, because said failures are standing in the way of completing your updates. One such issue is when one of the update scripts for one of the libraries being updated decides - suddenly - that it really needs to run a script out of /etc/init.d/. Let's suppose, whatever the reason, no such script exists at the time of this update. Apt fails, reporting that one of its packages wasn't able to complete all its steps.
One possible solution to this is to trick Apt into thinking there really IS a script available. In my case, I simply:
- touch /etc/init.d/systemd-logind
- chmod +x /etc/init.d/systemd-logind
Viola! Apt was able to finish processing the updates and now I might have a working system again. I stress might because it shouldn't have broken in the first place and I have no earthly idea why it did break. But, obviously, missing or non-configured update packages might be in the recipe.
The important thing, when you perform something abominable like what I mentioned above, is that you remove it before you reboot. If the service does depend on Upstart, having the fake init.d script available may cause much pain.
And that's that.
No comments:
Post a Comment