cat /sbin/block EL@�4p4 4@4@4@@t@t@t▒▒p�@�@�▒p�@�@�▒▒@@een�An�An��`�@�@�``dt�Qdt�Rn�An�An���/lib/ld-musl-mips-sf.so.1 ��A��R���� @P @ @ @P �@� � pApp5m�Ap @`ppp@p pap'pa@��p2An�▒o���o���@@o���o���@|CaF!%Z&*#5\/HBJLRS8_17UK ^32M4WI?V,'Y+;@[Q`]>T ▒( 1��Ap0▒�C=�@` ]�����jPC▒E�J� ���Ap4▒�g���@P >��@a����@a���Ap8▒$,28�?�FAp�ywvQr*8W�k�p�^eF@P3��An�ovb3L�v�|��o▒[i(`2CUlblibblkid-tiny.so__RLD_MAPblkidtiny_free_probeprobe_blockmkblkdev_finiblkidtiny_new_probeclosedirfputsstrlen__errno_locationstderrsprintfopendirmemsetstrtokstrncmpcallocstrrchr__stack_chk_failreaddirmallocmemcpy__stack_chk_guardstrcpylibuci.souci_get_errorstruci_to_blobuci_loaduci_set_confdiruci_alloc_contextmkdirstrchrglobfreefclosestrdupfdopenunlinkbasenameblobmsg_add_fieldblobmsg_parseglobfgetssnprintflibubox.soulogulog_thresholdblob_buf_initavl_strcmp__calloc_avlist_flushulog_openvlist_initvlist_addfcntlfopenpipegetenvwaitpidlibubus.soubus_freeubus_lookup_idubus_connectubus_invoke_fdlibblobmsg_json.solibjson-c.so.2exitlibgcc_s.so.1__register_frame_info__deregister_frame_infolibc.sodirnameexecldup2sleeprmdirumount2swapoffumasklstatstrstrdlopenstrcasii�Ap~Ap4~Ap8)~An�H~An�An�An�An�An�An�An�An�igetAn�e__libc_start_mainoptindoptargGLIBC_2.0� An� An� An�An�An�An�An�An�An�An�An�An�An�▒An�▒An�oAoAAo Ao!Ao"Ao▒#Ao$Ao %Ao$&Ao('Ao,(Ao0*Ao4+Ao8,Ao<-Ao@.AoD/AoH0AoL1AoP2AoT4AoX5Ao\6Ao`7Aod8Aoh9Aol:Aop;Aot<Aox=Ao|>Ao�?Ao�@Ao�AAo�BAo�CAo�DAo�FAo�GAo�IAo�JAo�KAo�LAo�MAo�NAo�OAo�PAo�QAo�RAo�SAo�TAo�UAo�VAo�WAo�XAo�YAo�ZAo�[Ao�\Ao�]Ao�^Ao�_Ao�`'��▒��<@'9� � <@'9O� � ��▒��'� '��Я�<A����p0��%����,��▒����
well, it's probably a binary ?
This thread needs to be deleted. Don't post binary code. It only makes sense to a CPU.
so, what shall be done? hard reset or wipe && sysupgrade... suppose it souldn`t be there, otherwise...?
why wouldn't it be there ?
never mind, del it, just wonder, if it`s ok or not
Learn about the difference between binary executables and text files by reading up on the internet.
NO. It's not ok to delete.
I also suggest not attempting to use command line utilities and only administering your Openwrt using the web interface. You're going to break it if you try to use command line tool without knowing what you're doing.
To directly answer the OP's inquiry.
/sbin/block is a file on OpenWrt.
root@OpenWrt:~# /sbin/block -h block: Usage: block <info|mount|umount|detect> root@OpenWrt:~# block -h block: Usage: block <info|mount|umount|detect>
This file work in the mounting/unmounting of drive partitions. Deleting it may make your device unstable.
BTW @suppus, welcome to the community!
Please refrain from posting binary (executable) code in the future.
/sbin - see:
... and if you're trying gain flash space by deleting files that came with the image, it won't work.
tried to modify sbin/block to mount LVM2_member on boot, just small preinit script add, and find that inside, after all check dates of modif and find a mass of files modified same date same min about a month ago contained some mess...
so the question actually was, - if i make 'umount /overlay && jffs2reset && reboot now' - it helps, or not?
Humans cannot [generally] "modify" an executable file. I really think you should research what you're doing before you break something.
To be clear
block is a program that you run/execute, not an editable config file. There is no need to modify this file.
Is this related to the
/sbin/block - or is this another unrelated inquiry?
That seems like a command to reset the OpenWrt.
On a jffs2 system, the
firstboot script is the recommended way to reset to the original default configuration. This will also remove any packages that are not part of the ROM (they were installed later).
I don't think that
block supports LVM2 (though have never tried); you will need your own script. If all your drives are LVM2 you wouldn't need
block at all.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.