Click on it, and you will advance to the next screen:
By default, the T70 is set to boot in legacy mode, so it will boot any of the four (ext4 legacy, etx4 UEFI, squashfs legacy, squashfs UEFI). If you switch to UEFI boot in BIOS, you would have to use one of the two UEFI images.
As to ext4 vs squashfs, I tend to lean rather hard into squashfs when booting from Flash-based media (USB sticks, CF cards, SD cards, eMMC modules). T70, on the other hand, boots from an mSATA drive, so my preference would be ext4, but it's absolutely fine to choose squashfs here as well. squashfs is more resilient to mishaps like sudden loss of power.
OK, I have to make an admission... It is no secret that Netgate is occasionally criticized by enthusiasts for this and that, and my response to those criticisms usually is, that may be so, but they've got @stephenw10... Oh, and let me use the occasion to say a separate thank-you for writing WGXepc64, which came in handy on more occasions than I can count...
@konus & @frollic , thank you. I wasn't sure what to choose from all the options. The ext4 vs squashfs question is an interesting one. This is the mount table from my existing running box:
root@OpenWrt:~# mount
/dev/root on /rom type squashfs (ro,relatime,errors=continue)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
/dev/loop0 on /overlay type ext4 (rw,noatime)
overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work,xino=off)
/dev/sda1 on /boot type vfat (rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/sda1 on /boot type vfat (rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
tmpfs on /dev type tmpfs (rw,nosuid,noexec,noatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,noatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,noatime)
bpffs on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,noatime,mode=700)
root@OpenWrt:~#
It seems to have a bit of everything - squashfs, ext4 and vfat, so I am not sure which image was used. I therefore downloaded both, but since @konus says he used the ext4 image, I started with that one first and tried copying it to the mSata:
$ sudo dd if=/home/johnc/Downloads/OpenWRT/openwrt-25.12.4-x86-64-generic-ext4-combined-efi.img of=/dev/sda
246335+0 records in
246335+0 records out
126123520 bytes (126 MB, 120 MiB) copied, 26.1936 s, 4.8 MB/s
At this point everything seemed fine and 3 partitions were created on the disk:
$ ls /dev/sd*
/dev/sda /dev/sda1 /dev/sda128 /dev/sda2
However, I then had a look at the partition types with Gparted and ran into this error:
Fdisk shows this:
GPT PMBR size mismatch (246304 != 62533293) will be corrected by write.
The backup GPT table is corrupt, but the primary appears OK, so that will be used.
The backup GPT table is not on the end of the device. This problem will be corrected by write.
Testdisk shows this:
check_FAT: Unusual number of reserved sectors 4 (FAT), should be 1.
Warning: number of heads/cylinder mismatches 2 (FAT) != 64 (HD)
EFI System 512 33279 32768 [EFI System Partition] [kernel]
Linux filesys. data 33280 246271 212992 [rootfs]
Yet the partitions 'kernel' and 'rootfs' auto-mounted normally on my Linux system and I could examine their contents.
I tried this on another two mSata disks and got the same problem. Gparted wouldn't let me do anything, but I was able to wipe the partition table in fdisk after which the error disappeared and I was able to start again. I unplugged the empty disk and plugged it back in and then copied the image to the mSata again and after I did, the error was back.
Since it occurs on multiple mSata drives, its evidently not a problem with the drives. Should I be concerned?
It's probably seeing existing tables on the drive since that image doesn't write the full drive. If you zero out the drive first you shouldn't see that.
But that said it shouldn't stop you booting it.
The backup partition table is stored at the end of the drive. OpenWrt only writes to the first ~120 MB. So there is a mismatch between the main partition table at the start and the backup one at the end. The warning can be ignored and the drive should boot without problems.
Thanks. That actually makes sense. Will be testing this later once I get the mod done.
Is there any advantage to expanding the size of the partition or can the remaining space (which there is quite a lot of) be used for anything else?
It is possible to expand the remaining space but opinions on the best approach seem to vary. I only expand to a size below 1000 MB such that automatic updates with owut / attended sysupgrade still work. This does require you to add the rootfs_size to the config file:
/etc/config/attendedsysupgrade
config owut 'owut'
option fstype 'squashfs'
option rootfs_size '768'
I then add another partition in the remaining disk space using fdisk. However I make sure to leave some spare space between the OpenWrt partitions (end at sector 1610239) and the data partition (mmcblk1p3 starts at sector 2000000).
output fdisk:
Device Boot Start End Sectors Size Id Type
/dev/mmcblk1p1 * 2048 35327 33280 16.3M 83 Linux
/dev/mmcblk1p2 36864 1610239 1573376 768.3M 83 Linux
/dev/mmcblk1p3 2000000 15273599 13273600 6.3G 83 Linux
This data partition can then be added to fstab such that it gets automatically mounted.
/etc/config/fstab
config 'mount'
option target '/mnt/mmcblk0p3'
option uuid 'c5a4e92f-9e12-49d0-9a97-4e1a5e3ed0e4'
option enabled '1'
This works fine for day to day use but you need to be careful with firmware upgrades. During a firmware upgrade the partition table and the OpenWrt partitions are overwritten. This makes it look as if you have lost all the data in partition 3. However re-creating the partition table after the upgrade using fdisk makes the partition and data re-appear. This approach has worked fine for me but you need to keep track of the starting sector of the 3rd partition.
Some people prefer to expand the OpenWrt filesystem to the full disk size however if it is more than 1000 MB you will not be able to do automatic upgrades. I also prefer to have the data in a separate partition from the OS.
There's an unofficial ASU/OWUT server accepting 4GB rootfs:es.
This file did not seem to exist on my msata card. I am looking in the rootfs partition. I therefore created it and added the content you pasted above.
Its interesting that this is using squashfs rather then ext4.
Having some spare space seems to make sense to prevent inadvertent overwriting of the created data partition as well as keeping track of the starting sector to make sure its re-created in the same place. I have seen that before where a partition is re-created and the original data is still there, because all that is happening is that the partition table entry is being deleted and then recreated with the exact same starting point and previous or larger size.
BTW, had to create the fstab in config as well and obviously used the UUID for my actual drive. Fdisk shows a 'Type-UUID' and a 'UUID'. I used the latter.
The config file only gets created after installing owut and / or luci-app-attended-sysupgrade packages. On this system with emmc storage I am using squashfs however you can just set it to ext4 if you want to use that instead.
I get the storage info for fstab from the block-mount package.
apk update
apk add block-mount
block detect
Just to be clear: I make those changes on the 'live' system when it is already running OpenWrt. I don't make any changes to the drive after writing the image with dd.
Well the good news is that I have put the msata card into the T70 and it boots and I can connect via console. I haven't yet been able to mount /dev/sda3 so perhaps something is missing, but the card works in my T70.
~# mount /dev/sda3 /mnt/data
[ 129.076416] F2FS-fs (sda3): Magic Mismatch, valid(0xf2f52010) - read(0x0)
[ 129.084110] F2FS-fs (sda3): Can't find valid F2FS filesystem in 1th superblock
[ 129.092585] F2FS-fs (sda3): Magic Mismatch, valid(0xf2f52010) - read(0x0)
[ 129.100205] F2FS-fs (sda3): Can't find valid F2FS filesystem in 2th superblock
However its a step forward. I was able to add an IP address and gateway and connect to the Internet and then run 'apk update' and 'apk upgrade'.
When I connect to luci I am running into the message which I can't get rid of:
If I select Yes, then it asks me to confirm and save, which I do, but then on the next refresh the message comes back. If I select close, the message just keeps coming back. I don't want to disable it as I would like to be prompted if there is a firmware update available.
Otherwise, so far, so good and I need to sort out the mod next. Once that is done, at some point I am going to want to backup the configuration from the primary box and restore it to this one. Obviously both can't be live on the network at the same time, so the backup will initially have to be checked offline and if all looks OK, I plan to do a substitution test.
There's no sda3 unless you created it, you'll need the fs support packages to be able to access it.
You will need to install additional packages and possibly format the partition. Check the wiki article below for some more info. A lot of the examples use opkg which in 25.12 has been replaced by apk
@frollic , yes I created a partition.
@konus , it looks like those instructions need updating as opkg apparently is no longer supported?
Anyway I ran 'apk add' instead of 'opkg install' once the message appeared informing me to use apk so its not a big deal. I am hopwever a little confused since this seems to apply to USB devices and I am working with an msata partition. I have installed the ext4 driver though.
I don't really understand what the commands for auto-mounting are doing and need to study them a bit more yet, but I will get there.
Yes the example is for a USB drive and uses opkg but the concept should be the same.
Since you have created the partition there are only a few steps left. First you need to install a few packages:
apk update
apk add e2fsprogs block-mount nano
Execute the following command to identify the existing partitions:
cat /proc/partitions
Format the new partition to ext4 format:
mkfs.ext4 /dev/sda3
Run block-detect to show the configuration that is needed for fstab:
block detect
Copy the config 'mount' section which corresponds to your 'sda3' partition to the clipboard.
Open '/etc/config/fstab' with nano text editor:
nano /etc/config/fstab
Move the cursor to the bottom of the text file and paste the contents of the clipboard.
Change enabled from '0' to '1' to make the partition mount automatically at boot.
ctrl + o to save the fstab config file
ctrl + x to quit nano
Reboot the router and when it is back online your partition should be available at /mnt/sda3.
The only program I had missed was nano - which is easier to use than vi of course.
The other step I had missed was formatting the partition in ext4 format, which I have now done using mkfs. I had already created the fstab file using the output of block-detect and changed enabled to 1 and the mount point to /mnt/data and created a directory in /mnt called /mnt/data
I can mount the partition manually, but it does not auto-mount.
I also still have that firmware updates pop-up I mentioned earlier and its rendering luci unusuable so I would appreciate knowing how to clear it.
Did you make changes to the files in /etc/config on the msata drive while it was plugged in to your computer? Did you use Windows or Linux to make changes? It sounds a lot like a either a file permissions issue or possibly a Windows end of line character problem.
ssh into the router and go to /etc/config and then show the properties of all the files:
ls -la
If you made changes to fstab and attendedsysupgrade from your computer the permissions may have changed. On my router it looks like this:
-rw-r--r-- 1 root root 281 Jun 3 20:47 attendedsysupgrade
-rw-r--r-- 1 root root 641 Jun 4 19:38 fstab
Another option is that you have modified the files in Windows and this has added windows end of line characters. Not sure how to fix that from the top of my head, best to do a quick google search.