raspi-copies-and-fills package gone AWOL?

[mtimc]

Hullo

I'm trying to build from the github builder (https://github.com/RPi-Distro/pi-gen). Unfortunately, one of the packages (raspi-copies-and-fills, which implements optimised low-level memory functions for the ARM processors) is no longer on archive.raspberrypi.org.

Is this a deliberate removal of the package?

tia

Tim

[ShiftPlusOne]

See viewtopic.php?f=28&t=235586

It was pulled ASAP to minimize the damage done. It should be back up with the offending commit reverted shortly.

Edit: It should be back up now.

[junpet]

Hi. I'd like to ask a little help. Yesterday I tried to update my system. There were only this package to update and my system now fails to boot. How can I remove this package, so I can start my system again? I have another sd card, so I could find and edit/remove the necessary files.
Thank you very much!

[DougieLawson]

If you can boot a rescue system or mount the SDCard in any other Linux computer then
sudo rm /mnt/etc/ld.so.preload solves the problem.

You can build a rescue system with another SDCard, a copy of plain Raspbian and a USB SDCard reader.

[junpet]

If you can boot a rescue system or mount the SDCard in any other Linux computer then
sudo rm /mnt/etc/ld.so.preload solves the problem.

You can build a rescue system with another SDCard, a copy of plain Raspbian and a USB SDCard reader.

Thank you very much! I used another sd card and deleted the file you mentioned. I've tried to boot, and I got this. Can you help me a little more? I press enter but nothing happens. Thank you again!

[DougieLawson]

Boot from the rescue system again. Insert the SDCard and run

for X in 1 2 5 6; do sudo umount /dev/sda$X; sudo fsck -f -y /dev/sda$X; done

That should make it bootable.

[junpet]

Boot from the rescue system again. Insert the SDCard and run

for X in 1 2 5 6; do sudo umount /dev/sda$X; sudo fsck -f -y /dev/sda$X; done

That should make it bootable.

Thank you! You're a lifesaver! I had to change sda to sdb and uncomment the sda line in /etc/fstab, and it started. Working like before. I'll be more careful in the future.
Thank you again! Have a nice day/evening/night!

[mtimc]

See viewtopic.php?f=28&t=235586

It was pulled ASAP to minimize the damage done. It should be back up with the offending commit reverted shortly.

Edit: It should be back up now.

It is indeed there now. However, postinst looks broken to me. It includes this stanza

Code: Select all

    configure)
      FPRELOAD=/etc/ld.so.preload
      if [ -f "$FPRELOAD" ]; then
        sed -i 's/libcofi_rpi/libarmmem/' "$FPRELOAD"
      fi
      echo "/usr/lib/arm-linux-gnueabihf/libarmmem-\${PLATFORM}.so" >> "$FPRELOAD"
    ;;

which causes all subsequent programs that use

Code: Select all

glibc

to complain thus:

Code: Select all

ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.

[ShiftPlusOne]

However, postinst looks broken to me.

Broken in what way? The line in ld.so.preload looks correct to me. Why ld.so is complaining, I'm not sure. Ae you definitely running this on a pi?

[incognitum]

Two concerns:

1) You now seem to have separate libraries for ARMv6 and ARMv7 systems. What about people that want to use same SD card or nfsroot for multiple type of Pi?

2) Currently when someone opens a chroot shell in the piserver GUI, piserver temporary renames ld.so.preload to something else while the shell is running, because the library gave problems when ran under qemu in the past.
However this has the side effect that if someone runs "apt-get upgrade", your postinst script is not able to update ld.so.preload.
And the package upgrade does seem to delete the old libarmmem.so, causing problems. See: https://github.com/raspberrypi/piserver/issues/52

[ShiftPlusOne]

1) You now seem to have separate libraries for ARMv6 and ARMv7 systems. What about people that want to use same SD card or nfsroot for multiple type of Pi?

The appropriate one is loaded using that ${PLATFORM} trick.

2) Currently when someone opens a chroot shell in the piserver GUI, piserver temporary renames ld.so.preload to something else while the shell is running, because the library gave problems when ran under qemu in the past.
However this has the side effect that if someone runs "apt-get upgrade", your postinst script is not able to update ld.so.preload.
And the package upgrade does seem to delete the old libarmmem.so, causing problems. See: https://github.com/raspberrypi/piserver/issues/52

I'll look into it.

In the long term, qemu 4 will have a fix that will get rid of the message, until then we'll need to make sure piserver and the postinst script work together.

[mtimc]

However, postinst looks broken to me.

Broken in what way? The line in ld.so.preload looks correct to me. Why ld.so is complaining, I'm not sure. Ae you definitely running this on a pi?

I'm running this in a qemu emulator on x86, using a fork from http://bit.ly/2uelq0D in a fedora vm with suitable binfmt settings to get the right binaries running in the right virtualised environments. I've been doing it like this since Jul 2017 and it's been fine.

Is that not a new line in the packing - sorry, I don't know where the packaging repo is, so I cannot `blame` it.

[mtimc]

Looking at an older image, I can see that the change is the ${PLATFORM} token.

If I remove the version (0.6) on that old image (which has:

Code: Select all

cat /etc/ld.so.preload
/usr/lib/arm-linux-gnueabihf/libarmmem.so

)

And then download and install v 0.10, I get:

Code: Select all

cat /etc/ld.so.preload
/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so

which is the same as I was getting in the build process. However, glibc isn't barfing when it reads the file, so, presumably, the variable ${PLATFORM} is defined in its environment. I cannot spot where.

[mtimc]

Looks like $PLATFORM is special to ld. Clearly something's not passing this through in my qemu environment.

[ShiftPlusOne]

I filed the issue here when I initially saw it:
https://bugs.launchpad.net/qemu/+bug/1813034

The fix should be available in Qemu 4, but that won't be ready any time soon. For now, while you're using qemu, comment the line out.