ok, I did that also. but the thing is that my internal storage is defective. thats why I am using the msata ssd. to be able to boot from there I need some settings changed accordingly. I think thats the reason why a “classic factory reset” is not working for me. maybe there is something to adopt in the medkit somewhere?
Look once again at my first post.
First link: how to install new u-boot.
Second one: how to set msata as main boot device and fix schnapps configuration.
Third: how to import current medkit to schnapps and rollback-to.
Just as a confirmation to future readers who are considering process: I went through it on an IGG Omnia (which is probably the earliest commercially available model). I installed turris-nor-update, reset the U-Boot environment to its default and followed through @drhm’s excellent guide otherwise – I found this to be the most complete and up-to-date resource. Adapting the schnapps config wasn’t required (as pointed out by drhm).
@tmoz, in case you aren’t able to extract a working snapshot from your system you can as well go with the “naked” medkit archive from CZ.NIC and follow the guide from there. That would equal a factory reset.
Hi, luckily my box is up again! the part I struggled most was to ensure the nor-update ran successful. If you do not have a properly running system it is not easy to fetch the right software and run it….
Thanks to all of you- you pointed me to the right direction!
I am, more or less, in the same situation. I run the nor-update on an IGG Omnia which was already booting from ssd, and it messed my uboot.
Here was the bad crc issue:
-Boot 2022.10-rc4-OpenWrt-r16653+119-44ce70f0e2 (Sep 15 2022 - 18:21:35 +0000)
SoC: MV88F6820-A0 at 1600 MHz
DRAM: 2 GiB (800 MHz, 32-bit, 2T, ECC not enabled)
Core: 72 devices, 26 uclasses, devicetree: separate
WDT: Started watchdog@20300 with servicing (60s timeout)
MMC: mv_sdh: 0
Loading Environment from SPIFlash... SF: Detected s25fl164k with page size 256 Bytes, erase size 4 KiB, total 8 MiB
*** Warning - bad CRC, using default environment
I went along and updated uboot and rescue, i have reset the environment, but I still can’t boot from the ssd (neither from mmc which holds an old (3.??) copy of turrisos).
It seems now that there is a BTRFS issue on the ssd that was otherwise bootable before nor-update .
=> scsi scan
scanning bus for devices...
BTRFS: superblock end 69632 is larger than device size 0
Device 0: (0:0) Vendor: ATA Prod.: ADATA SP310 Rev: 5.2
Type: Hard Disk
Capacity: 122104.3 MB = 119.2 GB (250069680 x 512)
=> printenv boot_prefixes
boot_prefixes=/ /boot/
=> printenv boot_targets
boot_targets=mmc0 nvme0 scsi0 usb0 pxe dhcp
=> setenv boot_prefixes / /boot/ /@/boot/
=> setenv boot_targets scsi0 nvme0 mmc0 usb0 pxe dhcp
=> run distro_bootcmd
Device 0: (0:0) Vendor: ATA Prod.: ADATA SP310 Rev: 5.2
Type: Hard Disk
Capacity: 122104.3 MB = 119.2 GB (250069680 x 512)
... is now current device
BTRFS: superblock end 69632 is larger than device size 0
Device 0: unknown device
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
17353 bytes read in 13 ms (1.3 MiB/s)
BootOrder not defined
EFI boot manager: Cannot load any image
Device 0: unknown device
Could not get PHY for mdio@72004: addr 1
dm_eth_phy_connect failed
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
Is there something that I could do or I should go ahead and Re-flash the router?
Well from BTRFS: superblock end 69632 is larger than device size 0
it is maybe that your ADATA SSD is either completely corrupted (worn out) or there could be some problem with boot sector where partition table is stored.
Do you have a backup image of entire SSD with clonezilla or some other imaging software ?
I would suspect that there could be something wrong with SSD. So first I would do suggested image backup of it and then do full overwrite format. You will see if SSD is worn out as you get errors while making backup or when doing full overwrite format. If there is no errors chances are your ssd got corrupted either boot sector (that usually happens when you fiffle with storage config in reforris) or some other problem on BTRFS filesystem on SSD>
You can try connect it on linux computer make backup with either partimage or clonezilla or if you can mount it you could do complete backup with rsync to another drive and then recreate it with medkit and move back /etc/config and install packages from the fresh.
The procedure is quite easy in following steps
- create partition table with BTRFS and SWAP or another partition as you wish by gparted. Just first one has to be BTRFS and format partition
- download latest 6.2.1 omnia medkit from repo.turris.cz
- mount SSD btrfs to some directory a.k. /mnt/ssd
- create subvolume @ by btrfs subvolume create /mnt/ssd/@
- extract medkit by tar zxcf omnia-medkit.tar.gz -C /mnt/ssd/@
(optionally you could repeat the same to creaty factory subvolume @factory by repeating steps 3.-4. just replace @ by @factory)
- unmount ssd and unplug it from computer
- put it back to omnia and power it on
You will have the clean installation with IP: 192.168.1.1
If you was able to mount SSD before formatting and back it up, you could move /etc/config/network and /etc/config/firewall /etc/config/dhcp and copy it to freshly installed medkit you will have minimal working network configuration that you are used to but I would suggest do it fresh config by runngin reforis first and copy those files from backup afterwards together with /etc/config/wireless which could be sufficient to make at least network configuration to what you use befere crash. Of course you will need to restore other files from /etc/config to restore rest of your configuration.
Of course if you have some spare one msata ssd or find out that current one is unreadable better get new on and prepare system on new one.
Thank you, I will try this on the weekend
I was getting this exact error message from U-Boot
BTRFS: superblock end 69632 is larger than device size 0
Turns out I flashed the OpenWRT sysupgrade image to a partition rather than the full disk, and the image contains a partition table with two partitions itself.
Writing the image directly to the mSATA disk (/dev/sda) rather than the partition (/dev/sda1) solved the issue for me.
It seems the newer U-Boot has a somewhat different implementation of BTRFS than the older one. In my case, the fix for this error was not necessarily deleting all but the first partition and extending the first one to the end of the disk. It showed sufficient to slightly enlarge the partition (without touching the filesystem residing on it).
My previous partitioning was:
/dev/sda1 : start= 2048, size= 33554432, type=83
/dev/sda2 : start= 33556480, size= 188743680, type=83
/dev/sda3 : start= 222300160, size= 12141488, type=83
With this partitioning, Omnia could not boot from the mSATA SSD.
I’ve enlarged the boot partition by 4096 sectors and recreated/moved the other partitions to fit and now I can boot flawlessly:
/dev/sda1 : start= 2048, size= 33558529, type=83
/dev/sda2 : start= 33562624, size= 188743681, type=83
/dev/sda3 : start= 222308352, size= 12133296, type=83
Of course, if you have some important data on the other partitions, you need to move them instead of just deleting and recreating slightly shifted. But that was not my case, I only had backups on sda2 and swap on sda3, so I ditched them.
Be aware that the UUIDs of the partitions will change after this operation, so update /etc/config/fstab accordingly. Storage plugin would also be affected if you have it on the mSATA SSD.