On 16/01/16 09:16 PM, Ben Hutchings wrote:
On Thu, 2016-01-14 at 11:18 +0100, Marco d'Itri wrote:initramfs-tools needs this patch to be able to resolve recursive symlinks, or else the system will not boot while in the middle of a merged /usr transition. Then I will add a versioned conflict to the usrmerge package.[...]Taking a quick look at it, it looks like validate_init will only handle a *single* absolute symlink, but in this particular case there are two (absolute) symlinks: /sbin/init -> /usr/sbin/init /usr/sbin/init -> /lib/systemd/systemd[...] We can't resolve the second symlink until /usr is already mounted, so recursively reading symlinks is not going to help. But clearly if /sbin/init is a symlink to somewhere under /usr then we need to mount it! Ben.
That seems a separate (if related) issue: this non-bootable problem comes up up even when /usr is on the same partition as /sbin (and it isn't really specific to /usr).
To reformulate slightly (taking /usr out of the equation entirely), the following symlink setup currently fails to boot with initramfs-tools:
/sbin/init -> /sbin/blah /sbin/blah -> /sbin/real.init with error "Target filesystem doesn't have requested /sbin/init"An in-progress usrmerge installation (without any of the added complexity of a separate /usr mount) is simply exposing this by creating such a symlink chain.
Jason
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature