So can this be backported to utopic? It's kind of a serious bug since it
renders the system unbootable.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1421117
Title:
This bug was fixed in the package initramfs-tools - 0.103ubuntu13
---
initramfs-tools (0.103ubuntu13) vivid; urgency=medium
* hooks/busybox: Create /bin/chroot symlink, to fix absolute symlinks when
busybox-static is not installed. (LP: #1421117)
-- Martin PittTue, 24 Feb 2
** Changed in: initramfs-tools (Ubuntu)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1421117
Title:
fails to boot wit
initramfs-tools already depends busybox-initramfs. What's missing is the hook
to symlink bin/chroot to busybox in the initrd.
Supporting /sbin/init being a symlink was not fixed for all cases in bug
#1351295. There was only a readlink symlink added but the chroot call in the
following line was m
Correct, ubuntu defaults to pulling in busybox-static into initramfs if
available. In practice, we pretty much require it for all our initramfs
and rarely don't have it. Maybe it should become a hard dependency on
ubuntu?
However, given that we support booting with either systemd or upstart,
shoul
FTR, that happens if busybox-static is *not* installed; that's in
ubuntu-standard, which explains why most people have it.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/b
Michael confirmed on IRC that with an explicit ln -s busybox
${DESTDIR}/bin/chroot in /usr/share/initramfs-tools/hooks/busybox it
works. It's indeed a bit curious where the existing hardlink comes
from..
** Changed in: initramfs-tools (Ubuntu)
Importance: Undecided => Medium
** Changed in: ini
For the record, the chroot is done here:
# Work around absolute symlinks
if [ -d "${rootmnt}" ] && [ -h "${rootmnt}${checktarget}" ]; then
case $(readlink "${rootmnt}${checktarget}") in /*)
checktarget="$(chroot ${rootmnt} readlink
${checkta
I managed to some more output to the serial log (booted with
"console=ttyS1,115200" only, no "console=tty0"):
starting version 219
[1.851984] sd 2:0:0:0: [sda] Assuming drive cache: write through
/init: line 307: chroot: not found
Target filesystem doesn't have requested /sbin/init.
/init: lin
Michael confirmed on IRC that it does work with a relative symlink, so
this sounds like a bug in initramfs-tools. But it works fine with an
absolute link on all my machines, VMs, LXCs etc, so I wonder if
initramfs-tools does something special on VMWare?
** Summary changed:
- fails to boot with "A
>From the booted system:
$ ls -l /sbin/init
lrwxrwxrwx 1 root root 20 Feb 10 10:59 /sbin/init -> /lib/systemd/systemd
$ ls -l /lib/systemd/systemd
-rwxr-xr-x 1 root root 1396464 Feb 10 11:00 /lib/systemd/systemd
For the output from the initramfs see the attached picture.
** Attachment added: "Out
11 matches
Mail list logo
