renamed libc-2.22.so

[Preacher]

I did a bad thing, as a 3rd party program requested libc-2.28.
On ssh shell I renamed libc-2.22.so, this broke symbolic link.
Now for almost every command I try I get "error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory".
Web access doesn't work anymore and so new ssh connection.
NAS doesn't boot now after forced shutdown.

Is there a way for accessing root filesystem to fix or any chance for revocery?

[orion]

Boot up from a USB (not sure if it's working)? Put all disks to another Ubuntu PC, then recover the link? Or you might need to re-initialize your NAS (lose your data).

[Preacher]

Thanks for advice, orion, but this is not on hard drives but internal flash. Previously I saw that system is on /dev/sda and other two drives are /dev/sdb and /dev/sdc
So I guess this was changes on /dev/sda which cannot be removed.
The path of library is /lib/libc.so.6

Booting from USB would be great, but is there actually a Linux image that I can put on a stick that will boot?

[orion]

As far as I know, ADM is located onto every disk (mirrored to one partition on each disk). Flash should only store booting stuffs.

USB boot image is quite easy to find. You can simply google "linux rescue image" to download it. However I'm not sure if you model can support boot from USB disk. I only tried x86 system which supports USB boots up. If you cannot make sure of it, you'd better to send a support request to asustor to check it.

EDIT: ARM system is somehow difficult to create a USB boot environment. I think you should consider to recover your NAS with a Ubuntu PC.

[father.mande]

Hi,
... if you have try all things before (try reinstalling A.D.M. via Control Center, etc.)

My suggestion (for Arm system) is :
If you know your previous Raid configuration ... the best way is to use a Linux system with enough free sata or/and usb external to reassemble the Raid and change in partition the erroneous file to the correct one.
The more difficulty is to have the hardware ... after a simple mdadm reassemble, then mount, then check fs is enough to get access (except for encrypted partition)

For your application :
if 2.28 is mandatory (not 2.27 ... because in this case Entware can help you and perhaps have the package you want (2500+) inside) the only running solution is to create a chroot and run your application in it.

ex. Domoticz APKG require a real new library ... so run in an Ubuntu Focal chroot on all architecture supported (x86_64, Armhf, Arm64) ... chroot can be transparent (sharing network with A.D.M.)

Philippe.

[Preacher]

Thanks for helping, so in fact USB boot is not an option as I see.
Recovering shall not be the problem, as disks are no RAID but just two drives standalone..

Actually I downloaded latest ARM_3.5.3.RBH1.img Firmware and looked into it using 7zip.
The two biggest files in it are builtin.tgz (125MB) and initramfs (11MB).
Looking into them shows /usr as root folder in builtin.tgz , everything I find below here looks like ADM.
Inside initramfs I see everything else - the root file system and inside /lib the library I renamed.

When being connected before I found that /dev/sda is internal flash and holds root system. /dev/sdb is first HDD and /dev/sdc second.

So I need to find a solution to access /dev/sda which holds contents of initramfs I guess.

Thanks for hint about APKG, I need to investigate on this as soon as I got system working again.

Dir stucture of firmware Image:

Code: Select all

16.11.2020  19:14            15 984 AS10XXT.dtb
16.11.2020  19:14                91 AS10XXT.dtb.md5sum
16.11.2020  19:14            15 984 AS10XXTE.dtb
16.11.2020  19:14                92 AS10XXTE.dtb.md5sum
17.11.2020  04:54       124 857 289 builtin.tgz
17.11.2020  04:54                78 builtin.tgz.cksum
17.11.2020  04:54                91 builtin.tgz.md5sum
17.11.2020  04:53        10 994 684 initramfs
17.11.2020  04:53                75 initramfs.cksum
17.11.2020  04:53                89 initramfs.md5sum
16.11.2020  19:14         3 097 136 zImage
16.11.2020  19:14                86 zImage.md5sum
              13 Datei(en),    138 981 679 Bytes


builtin.tgz folder /usr:

Code: Select all

17.11.2020  04:53    <DIR>          bin
16.11.2020  21:14    <DIR>          etc.default
17.11.2020  04:53    <DIR>          lib
16.11.2020  20:42    <DIR>          run
17.11.2020  04:53    <DIR>          sbin
16.11.2020  18:58    <DIR>          share
16.11.2020  18:58    <DIR>          tmp
16.11.2020  21:09    <DIR>          toolkit
16.11.2020  18:58    <DIR>          var
16.11.2020  21:09    <DIR>          webman


initramfs:

Code: Select all

17.11.2020  04:53    <DIR>          bin
16.11.2020  18:58    <DIR>          dev
16.11.2020  18:58    <DIR>          etc
29.01.2013  07:16               207 init
17.11.2020  04:53    <DIR>          lib
17.11.2020  04:53    <DIR>          lib64
16.11.2020  18:58    <DIR>          mnt
16.11.2020  18:58    <DIR>          opt
16.11.2020  18:58    <DIR>          proc
16.11.2020  18:58    <DIR>          root
16.11.2020  18:58    <DIR>          run
17.11.2020  04:53    <DIR>          sbin
16.11.2020  18:58    <DIR>          sys
16.11.2020  18:58    <DIR>          tmp
17.11.2020  04:53    <DIR>          usr
16.11.2020  18:58    <DIR>          var


and finally initramfs folder /lib:

Code: Select all

16.11.2020  18:58    <DIR>          firmware
16.11.2020  19:14                15 kernel-modules
17.11.2020  04:53           138 568 ld-2.22.so
22.12.2015  05:01                10 ld-linux-armhf.so.3
22.12.2015  05:01                10 ld-linux.so.3
17.11.2020  04:53            18 192 libanl-2.22.so
22.12.2015  05:01                14 libanl.so.1
22.12.2015  05:22                16 libasan.so
22.12.2015  05:22                16 libasan.so.0
17.11.2020  04:53           155 948 libasan.so.0.0.0
22.12.2015  05:22                18 libatomic.so
22.12.2015  05:22                18 libatomic.so.1
17.11.2020  04:53            14 720 libatomic.so.1.0.0
17.11.2020  04:53            13 844 libBrokenLocale-2.22.so
22.12.2015  05:00                23 libBrokenLocale.so.1
17.11.2020  04:53         1 242 716 libc-2.22.so
22.12.2015  05:01                12 libc.so.6
17.11.2020  04:53           190 096 libcidn-2.22.so
22.12.2015  05:01                15 libcidn.so.1
17.11.2020  04:53            38 496 libcrypt-2.22.so
22.12.2015  05:01                16 libcrypt.so.1
16.11.2020  19:46                20 libdevmapper.so
17.11.2020  04:53           135 416 libdevmapper.so.1.02
17.11.2020  04:53            18 028 libdl-2.22.so
22.12.2015  05:01                13 libdl.so.2
22.12.2015  05:22               132 libgcc_s.so
17.11.2020  04:53           122 360 libgcc_s.so.1
22.12.2015  05:22                16 libgomp.so
22.12.2015  05:22                16 libgomp.so.1
17.11.2020  04:53            55 224 libgomp.so.1.0.0
22.12.2015  05:22                15 libitm.so
22.12.2015  05:22                15 libitm.so.1
17.11.2020  04:53            90 464 libitm.so.1.0.0
16.11.2020  19:37                16 liblzma.so
16.11.2020  19:37                16 liblzma.so.5
17.11.2020  04:53           125 496 liblzma.so.5.0.5
17.11.2020  04:53           439 916 libm-2.22.so
22.12.2015  05:01                12 libm.so.6
17.11.2020  04:53            26 228 libmemusage.so
17.11.2020  04:53            79 828 libnsl-2.22.so
22.12.2015  05:01                14 libnsl.so.1
17.11.2020  04:53            34 680 libnss_compat-2.22.so
22.12.2015  05:01                21 libnss_compat.so.2
17.11.2020  04:53            34 444 libnss_db-2.22.so
22.12.2015  05:01                17 libnss_db.so.2
17.11.2020  04:53            26 244 libnss_dns-2.22.so
22.12.2015  05:01                18 libnss_dns.so.2
17.11.2020  04:53            46 780 libnss_files-2.22.so
22.12.2015  05:01                20 libnss_files.so.2
17.11.2020  04:53            22 160 libnss_hesiod-2.22.so
22.12.2015  05:01                21 libnss_hesiod.so.2
17.11.2020  04:53            80 920 libnss_ldap.so.2
17.11.2020  04:53            46 816 libnss_nis-2.22.so
22.12.2015  05:01                18 libnss_nis.so.2
17.11.2020  04:53            54 992 libnss_nisplus-2.22.so
22.12.2015  05:01                22 libnss_nisplus.so.2
16.11.2020  20:29                18 libparted.so
16.11.2020  20:29                18 libparted.so.2
17.11.2020  04:53           490 832 libparted.so.2.0.0
17.11.2020  04:53            13 808 libpcprofile.so
17.11.2020  04:53            92 668 libpthread-2.22.so
22.12.2015  05:01                18 libpthread.so.0
17.11.2020  04:53           213 312 libreadline.so.6.2
17.11.2020  04:53            83 836 libresolv-2.22.so
22.12.2015  05:01                17 libresolv.so.2
17.11.2020  04:53            26 528 librt-2.22.so
22.12.2015  05:01                13 librt.so.1
17.11.2020  04:53            17 972 libSegFault.so
22.12.2015  05:22                15 libssp.so
22.12.2015  05:22                15 libssp.so.0
17.11.2020  04:53             6 788 libssp.so.0.0.0
22.12.2015  05:22                19 libstdc++.so
22.12.2015  05:22                19 libstdc++.so.6
17.11.2020  04:53           755 612 libstdc++.so.6.0.16
17.11.2020  04:53           780 144 libstdc++.so.6.0.19
17.11.2020  04:53            34 676 libthread_db-1.0.so
22.12.2015  05:01                19 libthread_db.so.1
16.11.2020  19:33                13 libtinfo.so
16.11.2020  19:33                15 libtinfo.so.5
16.11.2020  19:33           130 369 libtinfo.so.5.9
17.11.2020  04:53            18 060 libutil-2.22.so
22.12.2015  05:01                15 libutil.so.1
17.11.2020  04:53    <DIR>          lsb
16.11.2020  18:58    <DIR>          modules


[father.mande]

Hi,
It's strange that you can't solve this using an update of same A.D.M. ??? because libc and link are in the ramfs ... so if you update A.D.M. with same version, you normally solve the link destroy
also a simple reboot ... I don't understand what you have done ???

JBOD is managed using mdadm to as a sort of Raid ... so reassembling JBOD is possible if disk are in the good order
... so on external Linux mount one by one disk to know the name and the order ... then reassemble it.

JBOD is unfortunately the less secure just after Raid0 and at same level than single disk ...

If you have a Windows system, don't try to reassemble Raid, but use a Virtual Machine running Linux and attach disk. (Virtualbox, Vmware player, Qemu, etc.)

Philippe.

[Preacher]

Actually I jusst executed:

Code: Select all

mv libc-2.22.so libc-2.22.so.org


And then everything stopped working.
It was just before midnigt, at midnight, NAS spins up all drive and performs typically something. I heard, that one drive continously spinned up and dowwn, so finally I forced shutdown. When trying to boot, system-LED kept blinking, so in my opinion I bricked the unit, als even after power loss, the NAS bootet immediately.

BUT
Thanks to your information, that root filesystem resides in RAM, I did some more research.
ASUS support saidm that they shall be contacted, if system LED continues blinking after half an hour.
I was courious aboth that, but stayed patient.
AND
What should i say, after approx. 15 minutes blinking, without any noticeable drive activity, the NAS just booted as normal, what I didn't see before.
Now everything, without any further interaction, is working as normal.

I gave a wrong information, my configuration is not JBOD but two individual drives, so no problem when need to mount from a Linux computer.

So guys, thanks for your patience and support, averything's fine.
I was courious, that a device could be bricked that easy.
About 10 years ago I played quite a lot with WL500G router and DD-WRT, from there I knew the concept about initramfs, but they needed to mout root as rw and write changes to /opt

So just a last question: the AS1002T with ARM is quite OK, but has quite a few restrictions because of architecture and performance. So I consider a x86 based NAS.
What is your opinion on the Nimbustor 4 (AS5304T)? Specifications look most promising for me.
ASSUS says, that migration is that easy, just to swap drives to new unit and working again. Is this also valid from ARM to x86 NAS?

Have a nice weekend and thanks again, cheers.

[father.mande]

Hi,

Good news
... delay before your get a working system can be due to forced shutdown and a full disk check before restarting ...

... using disk from ARM to x86_64 system is possible ... follow guides provide by Asustor like this : https://www.asustor.com/online/College_topic?topic=343
BUT a BACKUP is always a good idea ...
BUT checking disk and file system BEFORE moving is also a good idea

... security is normally done by using admin user and not root (except if you know what you do regarding specific architecture of the Linux in a NAS) IT'S NOT A STANDARD DISTRIBUTION.
... you have use root ... and as usual it's NOT recommended

It's only strange that rebooting don't solve (even with a delay) the problem ??? BUT ...

Philippe.

[Preacher]

It's really curious, because I had power cuts at least 20 times and machine always booted instantly.
But good to know, that I cannot brick the machine that easily.

Now I'll wait for the Nimbustore 4 to become cheaper, 550€ is too much currently, as I saw that price already was below 400€.
Then I'll will migrate and add more drives.

I know that working as root is not recommended. But I do so on all the Tinkerboards, Orangepis and so on, as I just login to update to latest version.

Salut et merci pour ton aide!