Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
On 2011-08-13 23:17 +0200, Sven Joachim wrote:
> On 2011-08-13 22:14 +0200, Jonathan Nieder wrote:
>
>> Sven Joachim wrote:
>>
>>> - link_name="debian/tmp-$(curpass)/lib/$$rtld_so" ; \
>>> + link_name="debian/tmp-$(curpass)/$(call xx,rtlddir)/$$rtld_so" ; \
>>> target="$(call xx,slibdir)/$$(readlink
>>> debian/tmp-$(curpass)/$(call xx,slibdir)/$$rtld_so)" ; \
>>> + mkdir -p debian/tmp-$(curpass)/$(call xx,rtlddir); \
>>> ln -s $$target $$link_name ; \
I have completely dropped this part. Installing into
debian/tmp-$(curpass)/lib is fine at this stage, no matter what the
final destination is.
>> Do I understand correctly that this is this a no-op (to prepare for
>> patch 5)?
>
> Ouch. It should not have been; I made a mistake while rebasing the
> patches, because the target dir in libc.install needs to be set to
> RTLDDIR, not to /lib.
So I install into both RTLDDIR and /lib, as in the old patch 5.
>> [...]
>>> @@ -384,6 +404,13 @@ fi
>>> #DEBHELPER#
>>>
>>> if [ -n "$preversion" ]; then
>>> +if test -L /lib64; then
>>> + case ${DPKG_MAINTSCRIPT_ARCH:-$(dpkg --print-architecture)} in
>>> + amd64 | ppc64 | sparc64 | s390x)
>>> + remove_lib64_symlink ;;
>>> + esac
>>> +fi
>>
>> If DPKG_MAINTSCRIPT_ARCH isn't set for some reason, this gives the
>> wrong value. Would it be possible to introduce a variable in
>> debian/rules.d/debhelper.mk so the right value can be cooked in at
>> build time?
>
> Probably, but I guess it does not matter in practice.
> DPKG_MAINTSCRIPT_ARCH is exported by dpkg since 1.15.4, and old dpkg
> versions don't support multiarch so you have to do something totally
> weird to install a foreign libc6.
I don't feel the need to do anything about it and leave it to Aurelien
if he thinks this is necessary.
>> Maybe it would be possible to mv /lib64 somewhere and loudly let the
>> admin know about it if it contains anything more than the dynamic
>> linker.
>
> Good idea. Something like that:
>
> aside=$(mktemp -d /lib64-moved-by-libc6-prerm.XX)
> echo "Moving /lib64 aside to $aside"
> mv /lib64 $aside
See patches 5 and 6 in the new attached series.
> I have some private undertakings tomorrow, will likely send a new patch
> series on Monday, unless somebody beats me to it.
The biggest change compared to the previous one is the new patch 6 which
tries to check that there is at least one free inode. Namely, if there
aren't any, the sequence
rm -f /lib64
$interpreter /bin/mkdir /lib64
$interpreter /bin/ln -s $ldfile RTLD_SO
will fail in the third command which is rather embarrassing. This is of
course far from perfect, if another process runs riot and creates files
rapidly, you can still lose. Also, that part isn't really tested at all
(except that it works when there are no ENOSPC problems).
I have lightly tested unpack failures by introducing a file conflict
with another package, they do at least not lead to immediate disaster.
The only problem that I see is that if unpacking fails during upgrade
and you then downgrade to an older _major_ eglibc version,
/lib64/ld-linux-x86-64.so.2 becomes a dangling symlink. I don't think
there is much which can be done about this.
Cheers,
Sven
>From 6ead53c51dac3ef8aa77b96b8c8f1a647f654a6d Mon Sep 17 00:00:00 2001
From: Sven Joachim
Date: Thu, 11 Aug 2011 17:15:03 +0200
Subject: [PATCH 1/6] Don't create /lib64 and /usr/lib64 symlinks
---
debian/sysdeps/amd64.mk |3 ---
debian/sysdeps/kfreebsd-amd64.mk |6 --
debian/sysdeps/ppc64.mk |6 --
debian/sysdeps/s390x.mk |6 --
debian/sysdeps/sparc64.mk|6 --
5 files changed, 0 insertions(+), 27 deletions(-)
diff --git a/debian/sysdeps/amd64.mk b/debian/sysdeps/amd64.mk
index c99dea4..67000a5 100644
--- a/debian/sysdeps/amd64.mk
+++ b/debian/sysdeps/amd64.mk
@@ -1,10 +1,7 @@
libc_rtlddir = /lib64
extra_config_options = --enable-multi-arch
-# /lib64 and /usr/lib64 are provided by glibc instead base-files: #259302.
define libc6_extra_pkg_install
-ln -sf /lib debian/$(curpass)/lib64
-ln -sf lib debian/$(curpass)/usr/lib64
make -C debian/local/memcpy-wrapper
install -m 755 -o root -g root -d debian/libc6/$(libdir)/libc
diff --git a/debian/sysdeps/kfreebsd-amd64.mk b/debian/sysdeps/kfreebsd-amd64.mk
index 261cbda..635b72d 100644
--- a/debian/sysdeps/kfreebsd-amd64.mk
+++ b/debian/sysdeps/kfreebsd-amd64.mk
@@ -1,12 +1,6 @@
# Main library
extra_config_options = --disable-compatible-utmp --disable-multi-arch
-# /lib64 and /usr/lib64 are provided by glibc instead base-files: #259302.
-define libc0.1_extra_pkg_install
-ln -sf /lib debian/$(curpass)/lib64
-ln -sf lib debian/$(curpass)/usr/lib64
-endef
-
# build 32-bit (i386) alternative library
EGLIBC_PASSES += i386
DEB_ARCH_REGULAR_PACKAGES += libc0.1-i386 libc0.1-dev-i386
diff --git a/debian/sysdeps/ppc64.mk b/debian/sysdeps/ppc64.mk
index 98cea4b..c8d2509 1006
Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Thanks for the review, Jonathan.
On 2011-08-13 22:14 +0200, Jonathan Nieder wrote:
> Sven Joachim wrote:
>
>> - link_name="debian/tmp-$(curpass)/lib/$$rtld_so" ; \
>> + link_name="debian/tmp-$(curpass)/$(call xx,rtlddir)/$$rtld_so" ; \
>> target="$(call xx,slibdir)/$$(readlink
>> debian/tmp-$(curpass)/$(call xx,slibdir)/$$rtld_so)" ; \
>> + mkdir -p debian/tmp-$(curpass)/$(call xx,rtlddir); \
>> ln -s $$target $$link_name ; \
>
> Do I understand correctly that this is this a no-op (to prepare for
> patch 5)?
Ouch. It should not have been; I made a mistake while rebasing the
patches, because the target dir in libc.install needs to be set to
RTLDDIR, not to /lib.
> [...]
>> @@ -384,6 +404,13 @@ fi
>> #DEBHELPER#
>>
>> if [ -n "$preversion" ]; then
>> +if test -L /lib64; then
>> +case ${DPKG_MAINTSCRIPT_ARCH:-$(dpkg --print-architecture)} in
>> +amd64 | ppc64 | sparc64 | s390x)
>> +remove_lib64_symlink ;;
>> +esac
>> +fi
>
> If DPKG_MAINTSCRIPT_ARCH isn't set for some reason, this gives the
> wrong value. Would it be possible to introduce a variable in
> debian/rules.d/debhelper.mk so the right value can be cooked in at
> build time?
Probably, but I guess it does not matter in practice.
DPKG_MAINTSCRIPT_ARCH is exported by dpkg since 1.15.4, and old dpkg
versions don't support multiarch so you have to do something totally
weird to install a foreign libc6.
>> It would be more prudent to prevent the downgrade from happening, but
>> if we fail the prerm script, the one from the previous version kicks
>> in and succeeds.
>
> Fixed by dpkg commit 9d3ec0f5 (“dpkg: do not fallback to "new-prerm
> failed-upgrade" for downgrades”). Probably that's too new to count
> on.
Ah, I wasn't aware of that. Still, adding a Pre-Depends on dpkg 1.16.1
on the affected arches is probably not a good idea.
>> +#Downgrading from a version with a /lib64 directory to a version with
>> +# a /lib64 symlink is extremely dangerous. We need to blow away the
>> +# directory and restore the symlink, otherwise the dynamic linker gets
>> +# lost after unpacking the replacing version.
>> +
>> +ldfile=$(readlink -e RTLD_SO)
>> +# Test if libc is of the same architecture as coreutils
>> +# If not, they almost surely have a multiarch system and we can use
>> +# the native ELF interpreter
>> +if ! $ldfile /bin/true 2>/dev/null; then
>> +interpreter=
>> +else
>> +interpreter=$ldfile
>> +fi
>> +
>> +# sync before and after the operation to reduce the danger of hosing
>> +# the system
>> +sync
>> +rm -rf /lib64
>> +$interpreter /bin/ln -s /lib /lib64
>
> Maybe it would be possible to mv /lib64 somewhere and loudly let the
> admin know about it if it contains anything more than the dynamic
> linker.
Good idea. Something like that:
aside=$(mktemp -d /lib64-moved-by-libc6-prerm.XX)
echo "Moving /lib64 aside to $aside"
mv /lib64 $aside
I have some private undertakings tomorrow, will likely send a new patch
series on Monday, unless somebody beats me to it.
Cheers,
Sven
--
I still say "/lib64" is one of the nastiest pieces of shit I've ever
heard of.
-- Branden Robinson
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874o1lroz5@turtle.gmx.de
Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Quick thoughts.
Sven Joachim wrote:
> +ldfile=$(readlink -e RTLD_SO)
> +# Test if libc is of the same architecture as coreutils
> +# If not, they almost surely have a multiarch system and we can use
> +# the native ELF interpreter
> +if ! $ldfile /bin/true 2>/dev/null; then
> + interpreter=
> +else
> + interpreter=$ldfile
> +fi
Very neat.
[...]
> Subject: [PATCH 2/6] Install the dynamic linker into RTLDDIR rather than /lib
[...]
> --- a/debian/debhelper.in/libc.install
> +++ b/debian/debhelper.in/libc.install
> @@ -1,4 +1,4 @@
> -TMPDIR/lib/*.so* /lib
> +TMPDIR/RTLDDIR/*.so* /lib
> TMPDIR/SLIBDIR/*.so* SLIBDIR
> TMPDIR/LIBDIR/gconv/* LIBDIR/gconv
>
> diff --git a/debian/rules.d/build.mk b/debian/rules.d/build.mk
> index 18f1800..36d7ee7 100644
> --- a/debian/rules.d/build.mk
> +++ b/debian/rules.d/build.mk
[...]
> - link_name="debian/tmp-$(curpass)/lib/$$rtld_so" ; \
> + link_name="debian/tmp-$(curpass)/$(call xx,rtlddir)/$$rtld_so" ; \
> target="$(call xx,slibdir)/$$(readlink debian/tmp-$(curpass)/$(call
> xx,slibdir)/$$rtld_so)" ; \
> + mkdir -p debian/tmp-$(curpass)/$(call xx,rtlddir); \
> ln -s $$target $$link_name ; \
Do I understand correctly that this is this a no-op (to prepare for
patch 5)?
[...]
> @@ -384,6 +404,13 @@ fi
> #DEBHELPER#
>
> if [ -n "$preversion" ]; then
> +if test -L /lib64; then
> + case ${DPKG_MAINTSCRIPT_ARCH:-$(dpkg --print-architecture)} in
> + amd64 | ppc64 | sparc64 | s390x)
> + remove_lib64_symlink ;;
> + esac
> +fi
If DPKG_MAINTSCRIPT_ARCH isn't set for some reason, this gives the
wrong value. Would it be possible to introduce a variable in
debian/rules.d/debhelper.mk so the right value can be cooked in at
build time?
> Subject: [PATCH 6/6] Restore the /lib64 symlink on downgrades
>
> It would be more prudent to prevent the downgrade from happening, but
> if we fail the prerm script, the one from the previous version kicks
> in and succeeds.
Fixed by dpkg commit 9d3ec0f5 (“dpkg: do not fallback to "new-prerm
failed-upgrade" for downgrades”). Probably that's too new to count
on.
> +#Downgrading from a version with a /lib64 directory to a version with
> +# a /lib64 symlink is extremely dangerous. We need to blow away the
> +# directory and restore the symlink, otherwise the dynamic linker gets
> +# lost after unpacking the replacing version.
> +
> +ldfile=$(readlink -e RTLD_SO)
> +# Test if libc is of the same architecture as coreutils
> +# If not, they almost surely have a multiarch system and we can use
> +# the native ELF interpreter
> +if ! $ldfile /bin/true 2>/dev/null; then
> + interpreter=
> +else
> + interpreter=$ldfile
> +fi
> +
> +# sync before and after the operation to reduce the danger of hosing
> +# the system
> +sync
> +rm -rf /lib64
> +$interpreter /bin/ln -s /lib /lib64
Maybe it would be possible to mv /lib64 somewhere and loudly let the
admin know about it if it contains anything more than the dynamic
linker.
Remaining problems:
- disruption to anything running concurrently with the
upgrade/downgrade. In the general case, there's nothing one can do
about this except warn about it.
- what happens if someone (a) has been trying to load libraries by
filename in /lib64 or (b) has been installing libraries to /lib64
and expecting to find them there?
Most likely, that's not a big deal --- I would expect people to have
used /usr/local/lib64 or /usr/lib64, but not /lib64.
- What happens to the /usr/lib64 symlink?
Except where mentioned above, it looks good to me (though I haven't
tested yet). Thanks!
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110813201419.gb13...@elie.gateway.2wire.net
Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
On 2011-08-10 22:03 +0200, Aurelien Jarno wrote: > On Wed, Aug 10, 2011 at 08:35:39PM +0200, Sven Joachim wrote: >> >> I'll have a look at it in the next few days if nobody beats me to it. >> Just to confirm that my ideas were the same as yours, AFAICS the >> following needs to be done in the preinst (on amd64), if /lib64 is a >> symlink: >> >> 1) remove /lib64 >> 2) create /lib64 directory >> 3) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to >> /lib64/ld-linux-x86-64.so.2 >> >> 2) and 3) are a bit difficult after the path to the ELF interpreter has >> just disappeared. I guess you still want to stick to shell nonetheless >> (as opposed to doing these steps in perl, say) ? >> > > This is basically what we have in mind, though it has not been tested. > For step 2 and 3, you can call the ELF interpreter directly, that is > "/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 mkdir /lib64". Almost right, you have use /bin/mkdir though since the interpreter knows nothing about PATH: , | # /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 mkdir /lib64 | mkdir: error while loading shared libraries: mkdir: cannot open shared object file ` > The whole operation is still not atomic, but so far it's the best way to > do it. We might want to insert a call to sync as steps 0 and 4, to > minimize the possible time with ELF interpreter, and to make sure the > data is written to the disk as soon as possible (otherwise if the > machine crashes, the system can't boot). After getting the necessary minimal grasp of the packaging system, I have come up with a first shot towards a solution, see the attached patch set. Upgrade from and downgrade to 2.13-16 has been tested in a minimal amd64 sid chroot. Also, I have tested upgrades from and downgrades to 2.13-10 in an i386/amd64 chroot with a multiarch-capable dpkg and i386 as primary architecture. I haven't yet checked or analyzed the consequences of unpacking failures during upgrade or downgrade. Known problems: - Multiarch systems with multiple libc6 versions shipping the /lib64 symlink will be hosed if the native libc6 is not unpacked first. Since this involves at least one unofficial architecture and an unofficial dpkg, it is probably ignorable. - Installing packages that ship files under /lib64 and then downgrading to a libc6 that ships the symlink breaks those packages. Should maybe give a warning on downgrades if any files beside the ELF interpreter are found in /lib64. - The lsb-core package installs symlinks /lib64/ld-lsb-x86-64.so.[23] to /lib/ld-linux-x86-64.so.2 that get broken. Nothing dramatic and solvable in a few ways. Cheers, Sven -- I still say "/lib64" is one of the nastiest pieces of shit I've ever heard of. -- Branden Robinson >From 6ead53c51dac3ef8aa77b96b8c8f1a647f654a6d Mon Sep 17 00:00:00 2001 From: Sven Joachim Date: Thu, 11 Aug 2011 17:15:03 +0200 Subject: [PATCH 1/6] Don't create /lib64 and /usr/lib64 symlinks --- debian/sysdeps/amd64.mk |3 --- debian/sysdeps/kfreebsd-amd64.mk |6 -- debian/sysdeps/ppc64.mk |6 -- debian/sysdeps/s390x.mk |6 -- debian/sysdeps/sparc64.mk|6 -- 5 files changed, 0 insertions(+), 27 deletions(-) diff --git a/debian/sysdeps/amd64.mk b/debian/sysdeps/amd64.mk index c99dea4..67000a5 100644 --- a/debian/sysdeps/amd64.mk +++ b/debian/sysdeps/amd64.mk @@ -1,10 +1,7 @@ libc_rtlddir = /lib64 extra_config_options = --enable-multi-arch -# /lib64 and /usr/lib64 are provided by glibc instead base-files: #259302. define libc6_extra_pkg_install -ln -sf /lib debian/$(curpass)/lib64 -ln -sf lib debian/$(curpass)/usr/lib64 make -C debian/local/memcpy-wrapper install -m 755 -o root -g root -d debian/libc6/$(libdir)/libc diff --git a/debian/sysdeps/kfreebsd-amd64.mk b/debian/sysdeps/kfreebsd-amd64.mk index 261cbda..635b72d 100644 --- a/debian/sysdeps/kfreebsd-amd64.mk +++ b/debian/sysdeps/kfreebsd-amd64.mk @@ -1,12 +1,6 @@ # Main library extra_config_options = --disable-compatible-utmp --disable-multi-arch -# /lib64 and /usr/lib64 are provided by glibc instead base-files: #259302. -define libc0.1_extra_pkg_install -ln -sf /lib debian/$(curpass)/lib64 -ln -sf lib debian/$(curpass)/usr/lib64 -endef - # build 32-bit (i386) alternative library EGLIBC_PASSES += i386 DEB_ARCH_REGULAR_PACKAGES += libc0.1-i386 libc0.1-dev-i386 diff --git a/debian/sysdeps/ppc64.mk b/debian/sysdeps/ppc64.mk index 98cea4b..c8d2509 100644 --- a/debian/sysdeps/ppc64.mk +++ b/debian/sysdeps/ppc64.mk @@ -1,12 +1,6 @@ libc_rtlddir = /lib64 extra_config_options = --enable-multi-arch -# /lib64 and /usr/lib64 are provided as symlinks -define libc6_extra_pkg_install -ln -sf /lib debian/$(curpass)/lib64 -ln -sf lib debian/$(curpass)/usr/lib64 -endef - # build 32-bit (powerpc) alternative library EGLIBC_PASSES += powerpc DEB_ARCH_REGULAR_PACKAGES += libc6-powerpc libc6-dev-powerpc diff --git a/debian/sysdeps/s390x.mk b/debian/sysdep
Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Aurelien Jarno wrote: > I don't think we want any manual intervention for this transition. For > the symlink I would prefer not having /lib64 left, as a lot of configure > scripts are actually looking to /lib64 to determine random things. Also > we have just seen that leaving leftover that are not handled by dpkg can > be a pain years after. Ok, that's convincing enough. I'm tempted to suggest (*) mkdir /lib64.real symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to /lib64.real/ld-linux-x86-64.so.2 if this is a chroot: sync unlink /lib64 rename /lib64.real to /lib64 sync else: ln -s lib64.real /lib64.eglibc-tmp rename lib64.eglibc-tmp to /lib64 and replacing the /lib64 symlink with a directory on startup in the non-chroot case, hoping that (1) in chroots, hopefully not too much is happening concurrently (2) in non-chroots, people reboot from time to time to get security updates But for now, why not always take the "if this is a chroot" branch. The atomicity part can happen later (when it is reported as a bug or someone implements it). If we're lucky, the syncs will stall other processes long enough to avoid trouble. :) -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110810211315.gb7...@elie.gateway.2wire.net
Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
On 2011-08-10 22:44 +0200, Aurelien Jarno wrote: > On Wed, Aug 10, 2011 at 10:32:27PM +0200, Sven Joachim wrote: >> On 2011-08-10 22:03 +0200, Aurelien Jarno wrote: >> > >> > This is basically what we have in mind, though it has not been tested. >> > For step 2 and 3, you can call the ELF interpreter directly, that is >> > "/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 mkdir /lib64". >> >> Except for the case where you install the libc on a foreign >> architecture. Then this might not work. >> > > The goal is to do that only in the preinst of libc0.1/6 (we can't do > that in the postinst as it would means the files on the filesystem and > in dpkg are not consistent), and only if /lib64 is a symlink. Given we > have removed the "Multiarch: same" tag in the libc6 packages of > architectures having a /lib64 symlink, You have removed them, but people still might have older libc versions installed that are Multiarch:same. Like myself in my multiarch adventure chroot were libc6 is stalled at 2.13-10. > these systems can't have a foreign coreutils as it would depends on a > foreign libc which is not installable. Even if libc6 is no longer Multiarch:same, that does not prevent installing libc6:amd64 and libc0.1:kfreebsd-amd64 simultaneously, AFAICS. Now when upgrading you have a 50% chance that the native libc is unpacked first. > That's only valid if we ignore the 2 or 3 versions that have been in sid > with this "Multiarch: same" tag. Ubuntu has many more versions, and a dpkg that actually supports multiarch. But for them this may not be such a big problem since only amd64 and i386 are supported, and people who have enabled multiarch almost surely run a 64-bit kernel. Cheers, Sven -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aabh6kk7@turtle.gmx.de
Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
On Wed, Aug 10, 2011 at 10:32:27PM +0200, Sven Joachim wrote: > On 2011-08-10 22:03 +0200, Aurelien Jarno wrote: > > > On Wed, Aug 10, 2011 at 08:35:39PM +0200, Sven Joachim wrote: > >> > >> I'll have a look at it in the next few days if nobody beats me to it. > >> Just to confirm that my ideas were the same as yours, AFAICS the > >> following needs to be done in the preinst (on amd64), if /lib64 is a > >> symlink: > >> > >> 1) remove /lib64 > >> 2) create /lib64 directory > >> 3) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to > >> /lib64/ld-linux-x86-64.so.2 > >> > >> 2) and 3) are a bit difficult after the path to the ELF interpreter has > >> just disappeared. I guess you still want to stick to shell nonetheless > >> (as opposed to doing these steps in perl, say) ? > >> > > > > This is basically what we have in mind, though it has not been tested. > > For step 2 and 3, you can call the ELF interpreter directly, that is > > "/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 mkdir /lib64". > > Except for the case where you install the libc on a foreign > architecture. Then this might not work. > The goal is to do that only in the preinst of libc0.1/6 (we can't do that in the postinst as it would means the files on the filesystem and in dpkg are not consistent), and only if /lib64 is a symlink. Given we have removed the "Multiarch: same" tag in the libc6 packages of architectures having a /lib64 symlink, these systems can't have a foreign coreutils as it would depends on a foreign libc which is not installable. That's only valid if we ignore the 2 or 3 versions that have been in sid with this "Multiarch: same" tag. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110810204423.gb5...@hall.aurel32.net
Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
On 2011-08-10 22:03 +0200, Aurelien Jarno wrote: > On Wed, Aug 10, 2011 at 08:35:39PM +0200, Sven Joachim wrote: >> >> I'll have a look at it in the next few days if nobody beats me to it. >> Just to confirm that my ideas were the same as yours, AFAICS the >> following needs to be done in the preinst (on amd64), if /lib64 is a >> symlink: >> >> 1) remove /lib64 >> 2) create /lib64 directory >> 3) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to >> /lib64/ld-linux-x86-64.so.2 >> >> 2) and 3) are a bit difficult after the path to the ELF interpreter has >> just disappeared. I guess you still want to stick to shell nonetheless >> (as opposed to doing these steps in perl, say) ? >> > > This is basically what we have in mind, though it has not been tested. > For step 2 and 3, you can call the ELF interpreter directly, that is > "/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 mkdir /lib64". Except for the case where you install the libc on a foreign architecture. Then this might not work. > The whole operation is still not atomic, but so far it's the best way to > do it. We might want to insert a call to sync as steps 0 and 4, to > minimize the possible time with ELF interpreter, and to make sure the > data is written to the disk as soon as possible (otherwise if the > machine crashes, the system can't boot). Good idea. Cheers, Sven -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqkd6m90@turtle.gmx.de
Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
On Wed, Aug 10, 2011 at 03:05:19PM -0500, Jonathan Nieder wrote: > Aug 10, 2011 at 09:59:48PM +0200, Aurelien Jarno wrote: > > On Wed, Aug 10, 2011 at 02:50:46PM -0500, Jonathan Nieder wrote: > > >> mv -fT /lib64.eglibc-tmp /lib64 > >> > >> should work. > > > > No it doesn't work for symlinks. > > Could you elaborate? Running > > ln -s a b > ln -s c d > strace mv -fT b d > ls -l d > > seems to suggest replacing one symlink by another works on Linux. > Further, rename(2) is documented to allow this, and I am not aware of > any special-case logic in coreutils that would affect it. Ah ok, I thought you were trying to replace a symlink by a directory. > [...] > >>rm /lib64 > >>mv /lib64.real /lib64 > >> > >> when nothing is running concurrently, in early boot. > > > > The problem is that your never reboot chroots. > > Sure, hence the need for the admin to intervene at a quiet time (or > it can be left alone --- is a symlink /lib64 -> lib64.real really > harmful?). I don't think we want any manual intervention for this transition. For the symlink I would prefer not having /lib64 left, as a lot of configure scripts are actually looking to /lib64 to determine random things. Also we have just seen that leaving leftover that are not handled by dpkg can be a pain years after. > Alternatively, why can't we keep the /lib64 -> /lib symlink? Getting > rid of it is not my itch. Lack of breakage in the squeeze -> wheezy > upgrade is. Because install libc6:amd64 on a 32-bit system means that /lib64 points to a directory with 32-bit libraries. People can break their systems that way (see for example #632176). -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110810201956.gc29...@hall.aurel32.net
Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Aug 10, 2011 at 09:59:48PM +0200, Aurelien Jarno wrote: > On Wed, Aug 10, 2011 at 02:50:46PM -0500, Jonathan Nieder wrote: >> mv -fT /lib64.eglibc-tmp /lib64 >> >> should work. > > No it doesn't work for symlinks. Could you elaborate? Running ln -s a b ln -s c d strace mv -fT b d ls -l d seems to suggest replacing one symlink by another works on Linux. Further, rename(2) is documented to allow this, and I am not aware of any special-case logic in coreutils that would affect it. [...] >> rm /lib64 >> mv /lib64.real /lib64 >> >> when nothing is running concurrently, in early boot. > > The problem is that your never reboot chroots. Sure, hence the need for the admin to intervene at a quiet time (or it can be left alone --- is a symlink /lib64 -> lib64.real really harmful?). Alternatively, why can't we keep the /lib64 -> /lib symlink? Getting rid of it is not my itch. Lack of breakage in the squeeze -> wheezy upgrade is. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110810200519.gc17...@elie.gateway.2wire.net
Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
On Wed, Aug 10, 2011 at 08:35:39PM +0200, Sven Joachim wrote: > On 2011-08-10 19:48 +0200, Aurelien Jarno wrote: > > > On Wed, Aug 10, 2011 at 07:14:57PM +0200, Sven Joachim wrote: > >> On 2011-07-25 14:50 +0200, Santiago Vila wrote: > >> > >> > reassign 632682 libc6 > >> > retitle 632682 we should probably remove /lib64 -> lib symlink (with > >> > care) > >> > thanks > >> > > >> > Hi. After discussing about this today, it seems what we really need > >> > for multiarch to work is to remove those symlinks, hence this reassign. > >> > >> Has anyone started working on this yet? > >> > > > > We got some ideas, but AFAIK nobody has started to work on that. > > I'll have a look at it in the next few days if nobody beats me to it. > Just to confirm that my ideas were the same as yours, AFAICS the > following needs to be done in the preinst (on amd64), if /lib64 is a > symlink: > > 1) remove /lib64 > 2) create /lib64 directory > 3) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to > /lib64/ld-linux-x86-64.so.2 > > 2) and 3) are a bit difficult after the path to the ELF interpreter has > just disappeared. I guess you still want to stick to shell nonetheless > (as opposed to doing these steps in perl, say) ? > This is basically what we have in mind, though it has not been tested. For step 2 and 3, you can call the ELF interpreter directly, that is "/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 mkdir /lib64". The whole operation is still not atomic, but so far it's the best way to do it. We might want to insert a call to sync as steps 0 and 4, to minimize the possible time with ELF interpreter, and to make sure the data is written to the disk as soon as possible (otherwise if the machine crashes, the system can't boot). -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110810200307.gb29...@hall.aurel32.net
Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
On Wed, Aug 10, 2011 at 02:50:46PM -0500, Jonathan Nieder wrote: > Hi again, > > Sorry for the lack of clarity. > > Sven Joachim wrote: > > On 2011-08-10 20:47 +0200, Jonathan Nieder wrote: > > >> 3) ln -s lib64.real /lib64.eglibc-tmp > >> 4) mv -f /lib64.eglibc-tmp /lib64 > > > > Now you have a broken lib/lib64.eglibc.tmp symlink which is not quite > > what you want. ;-) It would make more sense to use /lib64.eglibc-tmp/ > > as source, but this seems to fail with ENOTDIR. > > Yes, this is what I get for thinking in terms of system calls instead > of reading the manpage. > > mv -fT /lib64.eglibc-tmp /lib64 > > should work. No it doesn't work for symlinks. > >> 5) clean up on next reboot > > > > Not sure what you mean with that. Could you elaborate? > > Well, I handwaved it, but the problem is that there is no way to > atomically replace a symlink by a directory, and it would be best if > this is atomic to avoid disrupting applications running concurrently. > How to address that? Well, just do the hard part: > > rm /lib64 > mv /lib64.real /lib64 > > when nothing is running concurrently, in early boot. The problem is that your never reboot chroots. > Well, that is what I just wrote, but there is a little handwaving > involved: which initscript, exactly? (The initramfs would be the > easy place to do that kind of thing, but not everyone uses an > initramfs.) And how to prevent this from running concurrently with > another script? I don't have a good answer for that. > > One answer would be to make a script for the sysadmin to run to > take care of it and just leave a /lib64 -> /lib64.real symlink until > that's done. > -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110810195948.ga29...@hall.aurel32.net
Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Hi again, Sorry for the lack of clarity. Sven Joachim wrote: > On 2011-08-10 20:47 +0200, Jonathan Nieder wrote: >> 3) ln -s lib64.real /lib64.eglibc-tmp >> 4) mv -f /lib64.eglibc-tmp /lib64 > > Now you have a broken lib/lib64.eglibc.tmp symlink which is not quite > what you want. ;-) It would make more sense to use /lib64.eglibc-tmp/ > as source, but this seems to fail with ENOTDIR. Yes, this is what I get for thinking in terms of system calls instead of reading the manpage. mv -fT /lib64.eglibc-tmp /lib64 should work. >> 5) clean up on next reboot > > Not sure what you mean with that. Could you elaborate? Well, I handwaved it, but the problem is that there is no way to atomically replace a symlink by a directory, and it would be best if this is atomic to avoid disrupting applications running concurrently. How to address that? Well, just do the hard part: rm /lib64 mv /lib64.real /lib64 when nothing is running concurrently, in early boot. Well, that is what I just wrote, but there is a little handwaving involved: which initscript, exactly? (The initramfs would be the easy place to do that kind of thing, but not everyone uses an initramfs.) And how to prevent this from running concurrently with another script? I don't have a good answer for that. One answer would be to make a script for the sysadmin to run to take care of it and just leave a /lib64 -> /lib64.real symlink until that's done. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110810195046.ga17...@elie.gateway.2wire.net
Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
On 2011-08-10 20:47 +0200, Jonathan Nieder wrote: > Sven Joachim wrote: > >> 1) remove /lib64 >> 2) create /lib64 directory >> 3) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to >> /lib64/ld-linux-x86-64.so.2 >> >> 2) and 3) are a bit difficult after the path to the ELF interpreter has >> just disappeared. I guess you still want to stick to shell nonetheless >> (as opposed to doing these steps in perl, say) ? > > I wonder if the following would make sense: > > 1) mkdir /lib64.real > 2) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to > /lib64.real/ld-linux-x64-64.so.2 ^ Should be -x86-, but otherwise this makes some sense to me. But with the following you've lost me: > 3) ln -s lib64.real /lib64.eglibc-tmp > 4) mv -f /lib64.eglibc-tmp /lib64 Now you have a broken lib/lib64.eglibc.tmp symlink which is not quite what you want. ;-) It would make more sense to use /lib64.eglibc-tmp/ as source, but this seems to fail with ENOTDIR. > 5) clean up on next reboot Not sure what you mean with that. Could you elaborate? Cheers, Sven -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874o1p83an@turtle.gmx.de
Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Sven Joachim wrote: > 1) remove /lib64 > 2) create /lib64 directory > 3) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to > /lib64/ld-linux-x86-64.so.2 > > 2) and 3) are a bit difficult after the path to the ELF interpreter has > just disappeared. I guess you still want to stick to shell nonetheless > (as opposed to doing these steps in perl, say) ? I wonder if the following would make sense: 1) mkdir /lib64.real 2) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to /lib64.real/ld-linux-x64-64.so.2 3) ln -s lib64.real /lib64.eglibc-tmp 4) mv -f /lib64.eglibc-tmp /lib64 5) clean up on next reboot -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110810184727.ga16...@elie.gateway.2wire.net
Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
On 2011-08-10 19:48 +0200, Aurelien Jarno wrote: > On Wed, Aug 10, 2011 at 07:14:57PM +0200, Sven Joachim wrote: >> On 2011-07-25 14:50 +0200, Santiago Vila wrote: >> >> > reassign 632682 libc6 >> > retitle 632682 we should probably remove /lib64 -> lib symlink (with care) >> > thanks >> > >> > Hi. After discussing about this today, it seems what we really need >> > for multiarch to work is to remove those symlinks, hence this reassign. >> >> Has anyone started working on this yet? >> > > We got some ideas, but AFAIK nobody has started to work on that. I'll have a look at it in the next few days if nobody beats me to it. Just to confirm that my ideas were the same as yours, AFAICS the following needs to be done in the preinst (on amd64), if /lib64 is a symlink: 1) remove /lib64 2) create /lib64 directory 3) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to /lib64/ld-linux-x86-64.so.2 2) and 3) are a bit difficult after the path to the ELF interpreter has just disappeared. I guess you still want to stick to shell nonetheless (as opposed to doing these steps in perl, say) ? Cheers, Sven -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hb5p8684@turtle.gmx.de
Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
On Wed, Aug 10, 2011 at 07:14:57PM +0200, Sven Joachim wrote: > On 2011-07-25 14:50 +0200, Santiago Vila wrote: > > > reassign 632682 libc6 > > retitle 632682 we should probably remove /lib64 -> lib symlink (with care) > > thanks > > > > Hi. After discussing about this today, it seems what we really need > > for multiarch to work is to remove those symlinks, hence this reassign. > > Has anyone started working on this yet? > We got some ideas, but AFAIK nobody has started to work on that. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110810174858.gf28...@hall.aurel32.net
Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
On 2011-07-25 14:50 +0200, Santiago Vila wrote: > reassign 632682 libc6 > retitle 632682 we should probably remove /lib64 -> lib symlink (with care) > thanks > > Hi. After discussing about this today, it seems what we really need > for multiarch to work is to remove those symlinks, hence this reassign. Has anyone started working on this yet? Cheers, Sven -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjp989ym@turtle.gmx.de
Processed: Re: Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Processing commands for cont...@bugs.debian.org: > reassign 632682 libc6 Bug #632682 [base-files] base-files: please provide a /lib64 -> /lib symlink on 64-bit systems Bug reassigned from package 'base-files' to 'libc6'. Bug No longer marked as found in versions base-files/6.4. > retitle 632682 we should probably remove /lib64 -> lib symlink (with care) Bug #632682 [libc6] base-files: please provide a /lib64 -> /lib symlink on 64-bit systems Changed Bug title to 'we should probably remove /lib64 -> lib symlink (with care)' from 'base-files: please provide a /lib64 -> /lib symlink on 64-bit systems' > thanks Stopping processing here. Please contact me if you need assistance. -- 632682: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632682 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.131159821720841.transcr...@bugs.debian.org
