yi-hack-MStar
yi-hack-MStar copied to clipboard
roleoroleo
no /etc/resolv.conf after flash
hi
some days ago my camera (on older version 0.4.0 or 0.4.1) started to boot-loop. i upgraded to 0.4.3, which seemed to work, but no some other troubles started: (no more bootloop):
- i cannot connect via official yi home app i think the reason is that my / partition got full and i have now "no space left on device".
ln -s /tmp/resolv.conf /etc/resolv.conf
ln: /etc/resolv.conf: No space left on device
i no longer am able to flash to an older version, the cam simply reboots and very fast boots into 0.4.3 i CAN use the web-interface i can ssh into the cam
etc is:
/home/app # ls -l /etc/
total 5
lrwxrwxrwx 1 root 0 20 Aug 30 21:31 TZ -> /home/yi-hack/etc/TZ
drwxrwxr-x 3 root 0 0 Mar 4 2019 Wireless
lrwxrwxrwx 1 root 0 10 Aug 30 21:31 back.bin -> /fake/file
lrwxrwxrwx 1 root 0 26 Aug 30 21:31 hostname -> /home/yi-hack/etc/hostname
lrwxrwxrwx 1 root 0 10 Aug 30 21:31 hosts -> /tmp/hosts
drwxrwxr-x 2 root 0 0 Aug 30 21:31 init.d
-rwxrwxr-x 1 root 0 51 Mar 4 2019 inittab
lrwxrwxrwx 1 root 0 24 Aug 30 21:31 passwd -> /home/yi-hack/etc/passwd
-rw-r--r-- 1 root 0 1267 Aug 30 21:31 profile
tmp:
/home/yi-hack/etc # ls -l /tmp/
total 100
-rw------- 1 root 0 9 Jan 1 1970 MTK
lrwxrwxrwx 1 root 0 23 Jan 1 1970 audio -> /home/app/audio_file/us
prw------- 1 root 0 0 Jan 1 1970 audio_in_fifo
-rw------- 1 root 0 0 Jan 1 1970 audio_in_fifo.requested
-rw------- 1 root 0 222 Sep 16 15:06 debug_alarm.txt
-rw------- 1 root 0 0 Jan 1 1970 debug_oss.txt
-rw------- 1 root 0 137 Sep 16 14:57 debug_p2p.txt
-rw------- 1 root 0 24 Sep 16 15:17 dns1
-rw------- 1 root 0 2 Sep 16 15:17 done
-rw------- 1 root 0 13 Sep 16 15:17 gw1
prwx------ 1 root 0 0 Sep 16 14:57 h264_high_fifo
-rw-r--r-- 1 root 0 32 Sep 16 15:21 hosts
-rw------- 1 root 0 0 Jan 1 1970 httpd.conf
-rw------- 1 root 0 18112 Sep 16 15:21 log.txt
-rw------- 1 root 0 0 Jan 1 1970 log_oss.txt
srwx------ 1 root 0 0 Jan 1 1970 logsock
-rw------- 1 root 0 14 Sep 16 15:17 mask
-rwx------ 1 root 0 2592 Jan 1 1970 mmap.info
-rw------- 1 root 0 624 Sep 16 14:57 onvif_srvd.conf
-rw------- 1 root 0 65 Sep 16 15:17 resolv.conf
drwxr-xr-x 6 root 0 32768 Jan 1 1970 sd
drwx------ 4 root 0 80 Sep 16 14:57 var
-rwxrwxrwx 1 root 0 190 Jan 1 1970 wpa_supplicant.conf
i CAN fake a working dns by creating /tmp/hosts, but i dont know which ips i would need to e.g connect via app (and maybe reflash stock)
i COULD use upgrade_firmware, if i knew what parameters i would need.
any suggestions?
the cam is a home dome 1080 h201c: Firmware Version | 0.4.3 Base Version | 4.6.0.0A_201908271549 Model Suffix | h201c
yours josef
a start might be:
47.254.14.172 api.eu.xiaoyi.com
47.88.215.13 monitor-log.xiaoyi.com
123.57.245.215 hch.xiaoyi.com
47.254.149.252 log.eu.xiaoyi.com
199.195.117.143 www.onvif.org
things i checked already:
- try to downgrade to 0.4.2 by placing
- free some space in / (by deleting iperf) after rebooting - which is quite fast - i always end with 0.4.3
suggestions: maybe minimize writes to / (eg.: no removing/linking of /etc/resolv.conf but create the link in the base-image and stop removing /etc/resolv.conf the same with writing to /etc/hosts (which is a link to a nonexistant file under /tmp/hosts, at least on my cam). eg when faking
echo "127.0.0.1 api.eu.xiaoyi.com" >> /etc/hosts
You don't need to create a link for resolv.conf The rootfs partition should already contain the link.
If you copy the files in the sd (home_xxx and sys_xxx), the cam loads them and overwrites the firmware. But you can't use the same version because the bootloader stores the hashes.
So, if you want to reload the same hack, downgrade it and upgrade again.
You don't need to create a link for resolv.conf The rootfs partition should already contain the link.
there is /home/app/init.sh, which at every boot deletes an existing /etc/resolv.conf and creates a link to /tmp/resolv.conf this no longer works in my installation, as i have the "no space left on device".
If you copy the files in the sd (home_xxx and sys_xxx), the cam loads them and overwrites the firmware. But you can't use the same version because the bootloader stores the hashes.
i tried that (with both older versions of your releases and even the original firmware). the system reboots and very quick - without flashing - gets into 0.4.3 and the "no space left on device....)
So, if you want to reload the same hack, downgrade it and upgrade again.
tried that, did not work. it used to work (and works on several other cameras (6 of the same type)), therefore i'm quite sure that i did nothing wrong (besides somehow get into the no space left-problem).
my situation after a fresh reboot with yi-hack for MStar platform - v. 0.4.3:
- no /etc/resolv.conf
- no flash after booting with different versions of sys_* and home_*
- dmesg directly after booting:
_ _ _
_ _|_|___| |_ ___ ___| |_
| | | |___| | .'| _| '_|
|_ |_| |_|_|__,|___|_,_|
|___|
-----------------------------------------------------
yi-hack for MStar platform - v. 0.4.3
-----------------------------------------------------
/home/yi-hack # dmesg
[CPLD_PERIPH] CPLD_PERIPH module inited
[PWN] mstar_pwm_config duty_ns=0, period_ns=100000
reg=0x1F003490 clk=12000000, period=0x78
reg=0x1F003488 clk=12000000, u32Duty=0x0
ssp---hi_ssp_init
[gpio] Disable SPI0 function
ssp---hi_ssp_init ok!
usbcore: deregistering interface driver rtl8188fu
==20150512==> hub_port_init 1 #0
Plug in USB Port1
usb 2-1: reset high-speed USB device number 2 using soc:Mstar-ehci-1
usbcore: registered new interface driver rtl8188fu
MSYS: DMEM request: [ISP_MLOAD]:0x000088E0
ERROR: Bus[1] in ms_i2c_xfer_write: Slave dev NAK, Addr: 0x60, Data: 0x31 0x7
ERROR: Bus[1] in ms_i2c_xfer_write: Slave dev NAK, Addr: 0x60, Data: 0x31 0x7
ERROR: Bus[1] in ms_i2c_xfer_write: Slave dev NAK, Addr: 0x60, Data: 0x31 0x7
ERROR: Bus[1] in ms_i2c_xfer_write: Slave dev NAK, Addr: 0x6e, Data: 0xf0
ERROR: Bus[1] in ms_i2c_xfer_write: Slave dev NAK, Addr: 0x6e, Data: 0xf0
ERROR: Bus[1] in ms_i2c_xfer_write: Slave dev NAK, Addr: 0x6e, Data: 0xf0
ERROR: Bus[1] in ms_i2c_xfer_write: Slave dev NAK, Addr: 0x6e, Data: 0xf0
[HVSP1] Size must be align 16, Vsize=1080, Pitch=1920
[HVSP1] Buffer is single, Vsize=1080, Pitch=1920
MSYS: DMEM request: [SCL_MCNR_YC]:0x003FC000
MSYS: DMEM request: [SCL_MCNR_M]:0x000FF000
[HVSP1]: MCNR YC: Phy:22ae0000 Vir:c2ae0000
[HVSP1]: MCNR CIIR: Phy:0 Vir:0
[HVSP1]: MCNR M: Phy:22ee0000 Vir:c2ee0000
MSYS: DMEM [FGPALDCDMAP]@0x00000000 not found, skipping release...
MSYS: DMEM request: [FGPALDCDMAP]:0x00020000
MSYS: DMEM request: [DLC_MEM]:0x00000400
[DRVSCLDMA] Double Buffer Status :0
[HVSP1] Size must be align 16, Vsize=1080, Pitch=1920
[HVSP1] Buffer is single, Vsize=1080, Pitch=1920
MSYS: DMEM request: [VSPL-I0P0B0]:0x0005A000
MSYS: DMEM request: [VSPL-I0P0B1]:0x0005A000
MSYS: DMEM request: [VSPL-I0P0B2]:0x0005A000
MSYS: DMEM request: [VSPL-I0P2B0]:0x0005A000
MSYS: DMEM request: [VSPL-I0P2B1]:0x0005A000
MSYS: DMEM request: [VSPL-I0P2B2]:0x0005A000
[email protected]:r&d analysis.
[LDC]ISP_IN lost:0
MSYS: DMEM request: [MS-00]:0x00357000
MSYS: DMEM request: [MS-01]:0x00357000
MSYS: DMEM request: [MS-02]:0x00357000
MSYS: DMEM request: [VENC-32]:0x000FF000
[LDC]ISP_IN lost:0
mrqc_set_rqcf - skip set RQCT_CFG_SEQ
mrqc_set_rqcf - skip set RQCT_CFG_SEQ
MSYS: DMEM request: [S0:VENCDMOUT]:0x00006400
[email protected]:r&d analysis.
MSYS: DMEM request: [VSPL-I0P1B0]:0x0005A000
MSYS: DMEM request: [VSPL-I0P1B1]:0x0005A000
MSYS: DMEM request: [VSPL-I0P1B2]:0x0005A000
MSYS: DMEM request: [VENC-48]:0x00025800
mrqc_set_rqcf - skip set RQCT_CFG_SEQ
mrqc_set_rqcf - skip set RQCT_CFG_SEQ
MSYS: DMEM request: [S1:VENCDMOUT]:0x00005600
MSYS: DMEM request: [S1:VENCDMP0]:0x00056400
MSYS: DMEM request: [S1:VENCDMP1]:0x00056400
MSYS: DMEM request: [VSPL-I0P3B0]:0x00016800
MSYS: DMEM request: [VSPL-I0P3B1]:0x00016800
MSYS: DMEM request: [VSPL-I0P3B2]:0x00016800
[PID_LIST] pid_list_init ok, [ ver=Feb 26 2019, 14:28:36 ]
[SCLIRQ]chang time :26355
/home/yi-hack # ls -l /tmp/sd/
total 9728
-rwx------ 1 root 0 3 Sep 27 2021 VER.txt
-rwx------ 1 root 0 7969060 Sep 16 2021 home_h201c
-rwx------ 1 root 0 161 Oct 6 2021 hosts
drwx------ 2 root 0 32768 Sep 17 2021 log
drwx------ 104 root 0 98304 Oct 6 2021 record
-rwx------ 1 root 0 7168 Sep 29 2021 ssh.tar
-rwx------ 1 root 0 1625764 Sep 16 2021 sys_h201c
-rwx------ 1 root 0 584 Jun 15 20:20 system.conf.old
-rwx------ 1 root 0 607 Jun 15 20:20 system.conf.old2
drwx------ 3 root 0 32768 Jan 14 2021 yi-hack
/home/yi-hack # md5sum /tmp/sd/sys_h201c /tmp/sd/home_h201c
f5620deae6a523229a1db30a4339c46e /tmp/sd/sys_h201c
7d75180fc3a207d553df85e3b3a7f052 /tmp/sd/home_h201c
those are the original files from #380
This is strange. The upgrade procedure is made by the bootloader. If the sd card is correctly detected, the upgrade must start.
Try this: h201c_0.4.3.tar.gz I removed iperf and changed init.sh
the sd-card should have been correctly used as i can record on that and remove/add files. as i'm currently on 0.4.3 your fresh h201c_0.4.3.tar.gz wont help, as its the same version and therefore cannot get flashed. i would need some other version.
anyway. i will try to format the sd and start fresh.
your fresh h201c_0.4.3.tar.gz wont help, as its the same version and therefore cannot get flashed. i would need some other version.
The bootloader checks the hash, not the version. And the files are different. It should work.
holy cow! whatever it was: i now have a completly working camea again. steps:
- repartition (remove partition and recreate) sd-card with a 12G partition
- format fat32
- add your new files
- boot up the camera
- i think i have recognised two distinct flashes, a shorter first on and a longer second one
- the camera rebooted and did their left/right look
- voila, working thanks i'm very grateful
/home/yi-hack # df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 1.9M 1.8M 48.0K 98% /
tmpfs 29.7M 1.8M 27.9M 6% /dev
/dev/block/mtdblock3 12.2M 10.8M 1.4M 88% /home
tmpfs 32.0M 104.0K 31.9M 0% /tmp
/dev/block/mmcblk0p1 11.7G 66.2M 11.6G 1% /tmp/sd
/home/yi-hack # ls -l /etc/ /tmp/sd/
/etc/:
total 5
lrwxrwxrwx 1 root 0 20 Oct 7 15:20 TZ -> /home/yi-hack/etc/TZ
drwxrwxr-x 3 root 0 0 Mar 4 2019 Wireless
lrwxrwxrwx 1 root 0 10 Oct 7 15:20 back.bin -> /fake/file
lrwxrwxrwx 1 root 0 26 Oct 7 15:20 hostname -> /home/yi-hack/etc/hostname
lrwxrwxrwx 1 root 0 10 Oct 7 15:20 hosts -> /tmp/hosts
drwxrwxr-x 2 root 0 0 Oct 7 15:20 init.d
-rwxrwxr-x 1 root 0 51 Mar 4 2019 inittab
lrwxrwxrwx 1 root 0 24 Oct 7 15:20 passwd -> /home/yi-hack/etc/passwd
-rw-r--r-- 1 root 0 1267 Oct 7 15:20 profile
lrwxrwxrwx 1 root 0 16 Oct 7 15:20 resolv.conf -> /tmp/resolv.conf
/tmp/sd/:
total 24272
-rwx------ 1 root 0 12284537 Oct 7 15:28 h201c_0.4.3.tar.gz
-rwx------ 1 root 0 10816240 Oct 7 15:21 home_h201c
drwx------ 2 root 0 8192 Oct 8 15:37 log
drwx------ 3 root 0 8192 Oct 8 15:41 record
-rwx------ 1 root 0 1717492 Oct 7 15:21 sys_h201c
drwx------ 3 root 0 8192 Jan 14 2021 yi-hack
thanks
holy cow! whatever it was: i now have a completly working camea again. steps:
- repartition (remove partition and recreate) sd-card with a 12G partition
- format fat32
- add your new files
- boot up the camera
- i think i have recognised two distinct flashes, a shorter first on and a longer second one
- the camera rebooted and did their left/right look
- voila, working thanks i'm very grateful
/home/yi-hack # df -h Filesystem Size Used Available Use% Mounted on /dev/root 1.9M 1.8M 48.0K 98% / tmpfs 29.7M 1.8M 27.9M 6% /dev /dev/block/mtdblock3 12.2M 10.8M 1.4M 88% /home tmpfs 32.0M 104.0K 31.9M 0% /tmp /dev/block/mmcblk0p1 11.7G 66.2M 11.6G 1% /tmp/sd /home/yi-hack # ls -l /etc/ /tmp/sd/ /etc/: total 5 lrwxrwxrwx 1 root 0 20 Oct 7 15:20 TZ -> /home/yi-hack/etc/TZ drwxrwxr-x 3 root 0 0 Mar 4 2019 Wireless lrwxrwxrwx 1 root 0 10 Oct 7 15:20 back.bin -> /fake/file lrwxrwxrwx 1 root 0 26 Oct 7 15:20 hostname -> /home/yi-hack/etc/hostname lrwxrwxrwx 1 root 0 10 Oct 7 15:20 hosts -> /tmp/hosts drwxrwxr-x 2 root 0 0 Oct 7 15:20 init.d -rwxrwxr-x 1 root 0 51 Mar 4 2019 inittab lrwxrwxrwx 1 root 0 24 Oct 7 15:20 passwd -> /home/yi-hack/etc/passwd -rw-r--r-- 1 root 0 1267 Oct 7 15:20 profile lrwxrwxrwx 1 root 0 16 Oct 7 15:20 resolv.conf -> /tmp/resolv.conf /tmp/sd/: total 24272 -rwx------ 1 root 0 12284537 Oct 7 15:28 h201c_0.4.3.tar.gz -rwx------ 1 root 0 10816240 Oct 7 15:21 home_h201c drwx------ 2 root 0 8192 Oct 8 15:37 log drwx------ 3 root 0 8192 Oct 8 15:41 record -rwx------ 1 root 0 1717492 Oct 7 15:21 sys_h201c drwx------ 3 root 0 8192 Jan 14 2021 yi-hackthanks
What allocation unit size has you used when formatting sd flash in FAT32? @cheese1
holy cow! whatever it was: i now have a completly working camea again. steps:
- repartition (remove partition and recreate) sd-card with a 12G partition
- format fat32
- add your new files
- boot up the camera
- i think i have recognised two distinct flashes, a shorter first on and a longer second one
- the camera rebooted and did their left/right look
- voila, working thanks i'm very grateful
/home/yi-hack # df -h Filesystem Size Used Available Use% Mounted on /dev/root 1.9M 1.8M 48.0K 98% / tmpfs 29.7M 1.8M 27.9M 6% /dev /dev/block/mtdblock3 12.2M 10.8M 1.4M 88% /home tmpfs 32.0M 104.0K 31.9M 0% /tmp /dev/block/mmcblk0p1 11.7G 66.2M 11.6G 1% /tmp/sd /home/yi-hack # ls -l /etc/ /tmp/sd/ /etc/: total 5 lrwxrwxrwx 1 root 0 20 Oct 7 15:20 TZ -> /home/yi-hack/etc/TZ drwxrwxr-x 3 root 0 0 Mar 4 2019 Wireless lrwxrwxrwx 1 root 0 10 Oct 7 15:20 back.bin -> /fake/file lrwxrwxrwx 1 root 0 26 Oct 7 15:20 hostname -> /home/yi-hack/etc/hostname lrwxrwxrwx 1 root 0 10 Oct 7 15:20 hosts -> /tmp/hosts drwxrwxr-x 2 root 0 0 Oct 7 15:20 init.d -rwxrwxr-x 1 root 0 51 Mar 4 2019 inittab lrwxrwxrwx 1 root 0 24 Oct 7 15:20 passwd -> /home/yi-hack/etc/passwd -rw-r--r-- 1 root 0 1267 Oct 7 15:20 profile lrwxrwxrwx 1 root 0 16 Oct 7 15:20 resolv.conf -> /tmp/resolv.conf /tmp/sd/: total 24272 -rwx------ 1 root 0 12284537 Oct 7 15:28 h201c_0.4.3.tar.gz -rwx------ 1 root 0 10816240 Oct 7 15:21 home_h201c drwx------ 2 root 0 8192 Oct 8 15:37 log drwx------ 3 root 0 8192 Oct 8 15:41 record -rwx------ 1 root 0 1717492 Oct 7 15:21 sys_h201c drwx------ 3 root 0 8192 Jan 14 2021 yi-hackthanks
What allocation unit size has you used when formatting sd flash in FAT32? @cheese1
i dont know which unit size i had. i formated with gparted under linux and did not pay attention to that seting (if there was such a setting). i would recommend the default, which windows itself sets, whatever that is.
holy cow! whatever it was: i now have a completly working camea again. steps: What allocation unit size has you used when formatting sd flash in FAT32? @cheese1
i dont know which unit size i had. i formated with gparted under linux and did not pay attention to that seting (if there was such a setting). i would recommend the default, which windows itself sets, whatever that is.
I tried from linux gparted but it doesn't work neither :(
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}