Me three .............. errm 4, errm 5 ......................
Yep she's borked :lolflag:
Printable View
Replacing upstart with systemd is a viable workaround.
When booting using grub just edit the line GRUB_CMDLINE_LINUX_DEFAULT and append init=/lib/systemd/systemd so it will read like this:Reload grubCode:GRUB_CMDLINE_LINUX_DEFAULT="quiet init=/lib/systemd/systemd"
and reboot.Code:update-grub
Note that we're not removing upstart. We're still keeping upstart around but making permanent booting with systemd.
Please disregard my last post. Even though I was able to boot and load the system it resulted in a kernel panic situation. ](*,)
I do not have UU at hand at this moment.
This sounds much like (avahi) that initramfs did not work (or that some of You are trying to use kernels that did not get initramfs updated (default is that it is updated only for the newest kernel (that can be changed in /etc/initramfs-tools/update-initramfs.conf)))...
Beware: If I'm not right (not rare occasion) You should not contaminate working kernels by updating initramfs... ;)
Got that 2 hour ago on the ubuntu-devel list from Martin Pitt:
Quote:
Hello all,
this morning we found that current utopic du jour would hang at boot.
The cause has been identified, and we found a relatively simple
solution which restores booting, which is in sysv-rc 2.88dsf-41ubuntu15.
If you are in a situation where your machine does not boot any more,
the least intrusive workaround ironically is to boot with systemd:
Press "shift" during boot to get to the grub menu, press "e" on the
Ubuntu line, and append this to the "linux" line":
init=/lib/systemd/systemd
Then press Ctrl-X to boot.
Should that fail for any reason, the alternative workaround is to boot
into rescue mode, mount the root partition R/W, get a shell, and run
touch /etc/init.d/.legacy-bootordering
then reboot. After getting the fixed sysv-rc, you should remove that
file again.
For those who are interested in the details: We recently switched
Ubuntu's "old" upstart/sysvinit policy to what Debian currently uses.
Debian dropped support for the old statically numbered init.d script
links in /etc/rc*.d/ and moved to insserv and startpar long ago. We
finally did that transition as well to avoid an ever-growing delta in
Ubuntu and packages slowly becoming incompatible with the old way.
But it happens that some of our upstart jobs are "tasks" which appear
as "stopped" after they did their thing. init.d scripts which depend
on these will never start as startpar assumes that the depending
upstart job is "running". So we need to find out how to keep upstart's
"task" job semantics and make that work with startpar, but this isn't
something which we want to or can do "under the gun". Hence the above
sysv-rc upload disables startpar again for now.
Sorry for that blunder and for the inconvenience!
Martin
I hope You will not deem inappropriate if I say that this situation led me to faster boot: http://ubuntuforums.org/showthread.p...7#post13036197 ... ;)
I have solved my boot problem with this fix. Related: http://ubuntuforums.org/showthread.p...828&p=13036241
Me used chroot to update system from 14.04 install on disk 1.
I'm getting this for this morning's update:
Quote:
root@ubuntu:/var/cache/apt/archives# sudo apt-get -f install
sudo: unable to resolve host ubuntu
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 112 not upgraded.
5 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
E: Can not write log (Is /dev/pts mounted?) - openpty (2: No such file or directory)
Setting up procps (1:3.3.9-1ubuntu4) ...
invoke-rc.d: -----------------------------------------------------
invoke-rc.d: WARNING: 'invoke-rc.d procps start' called
invoke-rc.d: during shutdown sequence.
invoke-rc.d: enabling safe mode: initscript policy layer disabled
invoke-rc.d: -----------------------------------------------------
update-rc.d: error: unable to read /etc/init.d/procps-instance
dpkg: error processing package procps (--configure):
subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of udev:
udev depends on procps; however:
Package procps is not configured yet.
dpkg: error processing package udev (--configure):
dependency problems - leaving unconfigured
No apport report written because the error message indicates its a followup error from a previous failure.
dpkg: dependency problems prevent configuration of systemd:
systemd depends on udev; however:
Package udev is not configured yet.
dpkg: error processing package systemd (--configure):
dependency problems - leaving unconfigured
No apport report written because the error message indicates its a followup error from a previous failure.
dpkg: dependency problems prevent configuration of libpam-systemd:amd64:
libpam-systemd:amd64 depends on systemd (= 204-10ubuntu8); however:
Package systemd is not configured yet.
dpkg: error processing package libpam-systemd:amd64 (--configure):
dependency problems - leaving unconfigured
No apport report written because MaxReports is reached already
dpkg: dependency problems prevent configuration of ppp:
ppp depends on procps; however:
Package procps is not configured yet.
dpkg: error processing package ppp (--configure):
dependency problems - leaving unconfigured
No apport report written because MaxReports is reached already
Errors were encountered while processing:
procps
udev
systemd
libpam-systemd:amd64
ppp
E: Sub-process /usr/bin/dpkg returned an error code (1)