> So e.g. chroot /mnt/the_failed_upgrade_root does not work and bash > can not be run?
Though the system doesn't boot, running bash chrooted to it worked. Using that method, I tried what you suggested in an earlier message:
> could you please try running dpkg -i on the modules-init-tools > package in /var/cache/apt/archives
I assume you mean module-init-tools. There were two such packages:
-r--r--r-- 1 root root 86570 2007-08-20 16:21 module-init-tools_3.3-pre3-1ubuntu7_i386.deb -rw-r--r-- 1 root root 87414 2007-10-05 20:04 module-init-tools_3.3-pre4-2ubuntu4_i386.deb
I chose the latter one. This is what happened:
root@guesthouse:/var/cache/apt/archives# dpkg -i module-init-tools_3.3-pre4-2ubuntu4_i386.deb (Reading database ... 36359 files and directories currently installed.) Preparing to replace module-init-tools 3.3-pre4-2ubuntu4 (using module-init-tools_3.3-pre4-2ubuntu4_i386.deb) ... Unpacking replacement module-init-tools ... Setting up module-init-tools (3.3-pre4-2ubuntu4) ... Segmentation fault (core dumped) dpkg: error processing module-init-tools (--install): subprocess post-installation script returned error exit status 139 Errors were encountered while processing: module-init-tools
Rerunning dpkg under "strace -f" revealed that the core dump is from /usr/sbin/update-rc.d. I located the core file in /etc/rc0.d/core.
Running "/usr/sbin/update-rc.d module-init-tools start 15 S ." by hand also causes a core dump.
I will attach the part of the strace -f output pertaining to the /usr/sbin/update-rc.d process.
Since /usr/sbin/update-rc.d is a perl script, I note that the installed version of perl is 5.8.8-7ubuntu3.1 according to dpkg-query --show.
> So e.g. chroot /mnt/the_ failed_ upgrade_ root does not work and bash
> can not be run?
Though the system doesn't boot, running bash chrooted to it worked.
Using that method, I tried what you suggested in an earlier message:
> could you please try running dpkg -i on the modules-init-tools apt/archives
> package in /var/cache/
I assume you mean module-init-tools. There were two such packages:
-r--r--r-- 1 root root 86570 2007-08-20 16:21 module- init-tools_ 3.3-pre3- 1ubuntu7_ i386.deb init-tools_ 3.3-pre4- 2ubuntu4_ i386.deb
-rw-r--r-- 1 root root 87414 2007-10-05 20:04 module-
I chose the latter one. This is what happened:
root@ guesthouse: /var/cache/ apt/archives# dpkg -i module- init-tools_ 3.3-pre4- 2ubuntu4_ i386.deb init-tools_ 3.3-pre4- 2ubuntu4_ i386.deb) ... init-tools
(Reading database ... 36359 files and directories currently installed.)
Preparing to replace module-init-tools 3.3-pre4-2ubuntu4 (using module-
Unpacking replacement module-init-tools ...
Setting up module-init-tools (3.3-pre4-2ubuntu4) ...
Segmentation fault (core dumped)
dpkg: error processing module-init-tools (--install):
subprocess post-installation script returned error exit status 139
Errors were encountered while processing:
module-
Rerunning dpkg under "strace -f" revealed that the core dump is from update- rc.d. I located the core file in /etc/rc0.d/core.
/usr/sbin/
Running "/usr/sbin/ update- rc.d module-init-tools start 15 S ." by hand
also causes a core dump.
I will attach the part of the strace -f output pertaining to the update- rc.d process.
/usr/sbin/
Since /usr/sbin/ update- rc.d is a perl script, I note that the
installed version of perl is 5.8.8-7ubuntu3.1 according to
dpkg-query --show.