Recently, amd64-fbsd profile has been updated. As a result, baselayout to create a lib directory empty. We need to add the code to migrate for users who are using the previous profile. Please revert to Revision 1.8 profile for a while if we take time to resolve. Reproducible: Always Steps to Reproduce: 1. emerge baselayout (in chroot environment do it) Actual Results: (chroot) # ls Shared object "libutil.so.9" not found, required by "ls" (chroot) # exit ( exit from chroot environment) # ls -lha /chroot/lib | grep lib drwxr-xr-x 2 root wheel 512B Sep 29 16:58 lib drwxr-xr-x 5 root wheel 1.5k Sep 20 15:58 lib64 drwxr-xr-x 2 root wheel 512B Aug 25 07:59 libexec # ls -lha /chroot/lib total 16 drwxr-xr-x 2 root wheel 512B Sep 29 16:58 . drwxr-xr-x 19 root wheel 512B Sep 29 16:58 .. # ls -lha /chroot/usr | grep lib drwxr-xr-x 2 root wheel 512B Aug 25 07:55 lib drwxr-xr-x 33 root wheel 14k Sep 23 18:25 lib64 drwxr-xr-x 5 root wheel 512B Aug 25 07:07 libdata drwxr-xr-x 7 root wheel 1.0k Aug 25 08:10 libexec # ls -lha /chroot/usr/lib total 64 drwxr-xr-x 2 root wheel 512B Aug 25 07:55 . drwxr-xr-x 16 root wheel 512B Sep 29 16:58 .. -r--r--r-- 1 root wheel 2.2k Aug 25 07:55 Scrt1.o -r--r--r-- 1 root wheel 1.9k Aug 25 07:55 crt1.o -r--r--r-- 1 root wheel 833B Aug 25 07:55 crti.o -r--r--r-- 1 root wheel 568B Aug 25 07:55 crtn.o -r--r--r-- 1 root wheel 2.0k Aug 25 07:55 gcrt1.o -r--r--r-- 1 root wheel 1.4k Aug 25 07:55 libssp_nonshared.a Recovery methods 1. boot using the installation media of FreeBSD. 2. Live CD select 3. Mount the root partition of G/FBSD (eg. mount /dev/ufs/gfbsdroot /mnt) 4. cd /mnt 5. mv lib lib.err 6. ln -s lib64 lib 7. cd usr 8. mv lib lib32 9. ln -s lib64 lib 10. chroot /mnt ( check if into G/FBSD environment)
Created attachment 325326 [details, diff] sample patch for baselayout-2.2.ebuild Dirty patch. This patch modified to migrate to lib from lib64. The original ebuild have only migrate code to lib from lib32. In addition, create new symbolic link lib64 --> migrated lib dir. This is a safeguard to the package you have previously compiled the required lib64 dir. When you emerge -e world to rebuild all the packages, it should no longer required. NOTE, I will not be able to reply this week. I can not reply quickly.
We have following in profiles/arch/amd64-fbsd/make.defaults > # Vanilla FreeBSD has: lib for native 64 bits libs, lib32 for 32-bits emulation. > # Let's do this too as this also happens to be more standard among other linux > # distros. > # Adjust multilib dirs for multilib-strict. > LIBDIR_amd64_fbsd="lib" > MULTILIB_STRICT_DIRS="/lib32 /usr/lib32 /usr/kde/*/lib32 /usr/qt/*/lib32 /usr/X11R6/lib32" > SYMLINK_LIB="no" However, it doesn't seems that the baselayout ebuild support such directory location: it assume lib should have 32 bits libs when ${SYMLINK_LIB} != yes. abalier, I think we should: 1. Revert the amd64-fbsd profile change 2. Modify baselayout to support FreeBSD's lib* dirs location. 3. Apply LIBDIR change. How do you think of it? I might miss something since I'm not using amd64-fbsd.
Removing the baselayout check for *gentoo-freebsd* should work better, amd64-fbsd is still rather new so i thought it is still time to go with the lib/lib32 layout which is closer to upstream. Migration path I did is: - rm lib, mv lib64 lib, ln -s lib lib64, emerge -e world everything worked out except baselayout and I need to check if the above works.
(In reply to comment #3) > Removing the baselayout check for *gentoo-freebsd* should work better, > amd64-fbsd is still rather new so i thought it is still time to go with the > lib/lib32 layout which is closer to upstream. I agree changes to the layout lib/lib32. > Migration path I did is: - rm lib, mv lib64 lib, ln -s lib lib64, emerge -e > world > everything worked out except baselayout and I need to check if the above > works. Your upgrade path might work (I have not tested). However, general user must have known about this problem before upgrading. In addition, it is necessary to prepare in your way. General user uses "emerge -u baselayout" or "emerge -uDN world" to upgrade .
(In reply to comment #3) > Migration path I did is: - rm lib, mv lib64 lib, ln -s lib lib64, emerge -e > world > everything worked out except baselayout and I need to check if the above > works. I failed was upgraded by using your method . baselayout is check if /usr/lib32 exist. And, it will prompt you to migrate and die. To create new stage files will need to fix this bug. >>> Emerging (1 of 1) sys-apps/baselayout-2.2 * baselayout-2.2.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * Your system profile has SYMLINK_LIB=no, so that means you need to * have these paths configured as follows: * directories: /usr/local/lib * The ebuild will attempt to fix these, but only for trivial conversions. * If things fail, you will need to manually create/move the directories. * You need to merge /usr/lib32 into /usr/lib * ERROR: sys-apps/baselayout-2.2 failed (setup phase): * non-empty dir found where there should be none: /usr/lib32 * * Call stack: * ebuild.sh, line 89: Called pkg_setup * baselayout-2.2.ebuild, line 20: Called multilib_layout * baselayout-2.2.ebuild, line 112: Called die * The specific snippet of code: * die "non-empty dir found where there should be none: ${prefix}lib32" * * If you need support, post the output of `emerge --info '=sys-apps/baselayout-2.2'`, * the complete build log and the output of `emerge -pqv '=sys-apps/baselayout-2.2'`. * The complete build log is located at '/var/tmp/portage/sys-apps/baselayout-2.2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-apps/baselayout-2.2/temp/die.env'. * Working directory: '/var/tmp/portage/sys-apps/baselayout-2.2' * S: '/var/tmp/portage/sys-apps/baselayout-2.2/work/baselayout-2.2' >>> Failed to emerge sys-apps/baselayout-2.2, Log file: >>> '/var/tmp/portage/sys-apps/baselayout-2.2/temp/build.log' * Messages for package sys-apps/baselayout-2.2: * Your system profile has SYMLINK_LIB=no, so that means you need to * have these paths configured as follows: * directories: /usr/local/lib * The ebuild will attempt to fix these, but only for trivial conversions. * If things fail, you will need to manually create/move the directories. * You need to merge /usr/lib32 into /usr/lib * ERROR: sys-apps/baselayout-2.2 failed (setup phase): * non-empty dir found where there should be none: /usr/lib32 * * Call stack: * ebuild.sh, line 89: Called pkg_setup * baselayout-2.2.ebuild, line 20: Called multilib_layout * baselayout-2.2.ebuild, line 112: Called die * The specific snippet of code: * die "non-empty dir found where there should be none: ${prefix}lib32" * * If you need support, post the output of `emerge --info '=sys-apps/baselayout-2.2'`, * the complete build log and the output of `emerge -pqv '=sys-apps/baselayout-2.2'`. * The complete build log is located at '/var/tmp/portage/sys-apps/baselayout-2.2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-apps/baselayout-2.2/temp/die.env'. * Working directory: '/var/tmp/portage/sys-apps/baselayout-2.2' * S: '/var/tmp/portage/sys-apps/baselayout-2.2/work/baselayout-2.2'
Confirmed gross bug. I followed standard handbook recipe to install, did not change anything in /etc/portage, did not change profiles, did not pass go and did not collect $200. Simply rebooted, ran 'emerge -u system' and got every binary on the box broken. You can get everything back if you understand the problem and have a clue and/or a rescue CD. But, for 'Grandma' (who admittedly is probably not a big consumer of amd64-fbsd) it'll be hard even to look into it, since 'ls', 'bash', etc. are all broken.
Created attachment 326460 [details, diff] sample patch for baselayout-2.2.ebuild patch update
Applied a much simpler patch, I dont think its worth crippling baselayout ebuild with a migration path since very few people had installed the old way and new stages will be setup correctly. please test!
(In reply to comment #8) > Applied a much simpler patch, I dont think its worth crippling baselayout > ebuild with a migration path since very few people had installed the old way > and new stages will be setup correctly. ok. How about sends mail of guidance of migration on a mailing list ? > please test! I tried new baselayout-2.2.ebuild. I was able to make new stages of 9.1_rc2 with my script (stages_builder.sh on bsd-overlay). In addition, I have confirmed that baselayout can be installed without problems in the environment of the migrated. Step which I have confirmed 1. wget -O /tmp/migrate_libdir.sh "http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-bsd.git;a=blob_plain;f=scripts/migrate_libdir.sh;hb=HEAD" 2. bash /tmp/migrate_libdir.sh 3. emerge sys-apps/baselayout note, added scripts/migrate_libdir.sh on bsd-overlay. removed baselayout from bsd-overlay. added migration chapter in installation section on wiki (while until you upload new stages) added this bug in troubleshooting section on wiki.
(In reply to comment #9) > (In reply to comment #8) > > Applied a much simpler patch, I dont think its worth crippling baselayout > > ebuild with a migration path since very few people had installed the old way > > and new stages will be setup correctly. > ok. > How about sends mail of guidance of migration on a mailing list ? > yep, sounds a good idea > > please test! > > I tried new baselayout-2.2.ebuild. > > I was able to make new stages of 9.1_rc2 with my script (stages_builder.sh > on bsd-overlay). > In addition, I have confirmed that baselayout can be installed without > problems in the environment of the migrated. > > Step which I have confirmed > 1. wget -O /tmp/migrate_libdir.sh > "http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-bsd.git;a=blob_plain; > f=scripts/migrate_libdir.sh;hb=HEAD" > 2. bash /tmp/migrate_libdir.sh > 3. emerge sys-apps/baselayout > > note, > added scripts/migrate_libdir.sh on bsd-overlay. > removed baselayout from bsd-overlay. > added migration chapter in installation section on wiki (while until you > upload new stages) > added this bug in troubleshooting section on wiki. perfect, let's close this bug then :)
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > Applied a much simpler patch, I dont think its worth crippling baselayout > > > ebuild with a migration path since very few people had installed the old way > > > and new stages will be setup correctly. > > ok. > > How about sends mail of guidance of migration on a mailing list ? > > > > yep, sounds a good idea I sent an email to gentoo-bsd mailing list.
