(I realize these instructions may feel like being suddenly thrown into the deep end of the swimming pool, to sink or swim. If these instructions don't seem detailed enough for you, I'd strongly encourage you to seek someone with more Linux experience near you, and try fixing it together with them.)
If you don't have a backup you could restore, the easiest way to recover would probably be to manually extract & place the old libraries back, and once the system is runnable chrooted, downgrade any updated library packages using the package manager.
.deb packages can be extracted manually with ar x package.deb, which results in three files: control.tar.xz containing pre/post install/remove scripts (if any) and metadata for the package manager, and data.tar.xz containing the actual files, packaged using relative paths in such a way that if you extract the data.tar.xz in the system's root directory, the files will automatically extract to their intended locations.
In this specific case, you would boot into your alternative system, mount the root filesystem of the damaged primary system, and then extract the data.tar.xz from the appropriate glibc package in the directory that would be the root directory of the primary system. In other words, if you mount the primary root filesystem to /mnt, you would extract the data.tar.xz with something like:
cd /mnt
tar xvf /where/ever/data.tar.xz
You should also read the /var/log/dpkg.log of the primary system (i.e. /mnt/var/log/dpkg.log when the root filesystem of the primary OS is mounted to /mnt). That file should have lines like
<timestamp> upgrade <package name>:<arch> <old version> <new version>
which will tell you exactly which package versions were there before you started your unfortunate upgrade attempt, and also if your glibc upgrade caused other library packages to be upgraded too: if it did, you might have to revert those too.
Once the correct versions of the necessary libraries have been restored, you could test the primary system by chrooting into it. Assuming the root filesystem of the primary system is mounted to /mnt:
mount --rbind /dev /mnt/dev
mount --rbind /sys /mnt/sys
mount -t proc proc /mnt/proc
chroot /mnt
After these commands, the shell session you entered the chroot command should now be able to operate within the environment of the primary system, essentially as if the primary system was running in a minimal fashion ("single-user mode"). You should run ldd /sbin/init and verify that it reports no missing libraries, and perhaps do the same with any essential system binaries.
At this point, you should also be able to use the package manager to carefully revert the failed upgrades, so the package manager's idea of currently-installed files will again match the reality (so you won't have dependency problems later). If the dpkg.log indicated that packages were removed during the upgrade, you should probably reinstall the removed packages, just so that you can get back to the exact configuration that existed before the upgrade.
If you did a manual update-initramfs -u after your upgrade attempt, or if the timestamp of the initrd.img-<kernel version> file(s) in the /boot of the primary installation indicate that they have been updated during your upgrade attempt, you might need to run update-initramfs -u -k <kernel version> in the chrooted shell session to rebuild the primary system's initramfs with the good libraries again.
If you managed to revert all the library packages that got updated in your glibc upgrade attempt, your primary system should now be back in the pre-upgrade state, and bootable again.
Updating GLIBC without upgrading the rest of the distribution at the same time is generally a bad idea: GLIBC is normally the cornerstone that is relied on by essentially all executable binaries on the system, and many library files will depend on it too.
The distribution builder has chosen a set of core system library versions (including GLIBC) and built and configured them to work well together. If you replace any one of these libraries with a package intended for some other distribution (or even another major version of the same distribution), these interdependencies will be in jeopardy, and things may not work as intended, or at all (as you discovered).
quietsplashor any similarly looking options, try to boot.Attempted to kill init!probably means the (post-initramfs?)initprocess fails to run because the dynamic loader now cannot find compatible versions of the required libraries for it. Like the newest answer to the question linked in the OP says "If you need to upgrade glibc, the safest solution may be to upgrade your Linux distribution, since most software depends on glibc." The easiest way to recover would probably be to manually extract & place the old libraries back, and once the system is runnable chrooted, downgrade any updated library packages using the pkg manager.