I’m trying to format a 980 1tb without luck. At this point, when I try to format the drive, the process crashes. After rebooting, the drive is there, but not formatted or unusable.
I unboxed and setup my vim4 this morning (June 19th).
1 Like
Have you checked to see if there’s a firmware update in OOWOW? It’s separate from the section that lets you flash an image on the drive.
Nope, just started playing with the device a couple of hours ago.
Can you use OOWOW to install this image to check again? vim4-ubuntu-22.04-gnome-linux-5.4-fenix-1.0.11-220607-emmc-develop.raw.img.xz
1 Like
Also, you might want to try checking for a firmware (?) update in OOWOW.
When it drops you into the interface to flash the eMMC, cancel out of that and you’ll get a menu with more options, one of which will be to check for an update to the firmware.
I threw some heatsinks on the SSD I was using and continued to have issues. The heatsink was very much not not either.
I however got slightly different errors (although I haven’t tried to reproduce the errors yet). I see the controller being reset and then everything entering a funny state. I will try to reproduce the errors and get a dmesg capture once I have some time to do so.
1 Like
100% new to this, so please bear with me.
When @numbqq said to use the new image, does that mean I need to completely wipe and reinstall the OS?
edit -
I accidentally reinstalled the OS using the latest available from OW, but I’m still unable to format SSD.
what I’m doing:
open Gparted
select the drive
create partition table (type: gpt)
new partition:
name: storage
file sys: ext4
label: storage
error:
64-bit filesystem support is not enabled. The larger fields afforded by this feature enable full-strength checksumming.
Pass -O 64bit to rectify.<br />Discarding device blocks: done
<br />Creating filesystem with 244190208 4k blocks and 61054976 inodes<br />
Filesystem UUID: 94d86d9e-e24d-45ec-1111<br />
Superblock backups stored on blocks: <br />
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, <br /> 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, <br /> 102400000, 214990848<br /><br />Allocating group tables: done
<br />Writing inode tables: done <br />Creating journal (262144 blocks): done<br />Writing superblocks and filesystem accounting information: 0/7453</i>
Yes. But you can copy your current drive image to your SD-card or other storage with dd and xz first, so that you can restore it if you choose.
Here’s the script I use to create backup images:
# mkimg.sh This script will create a compressed disk image
\ # LGD Sat 18 Jun 2022 10:08:35 AM PDTlsblk
echo -e “\nEnter the device to backup: \c”
read DEV;echo
echo -e “Enter the name of the output fille: \c”
read FNAME;echo
echo -e “$(tput smso)Using input device:$(tput rmso) $DEV\t$(tput smso)Output file:$(tput rmso) $FNAME\n”
echo -e “Is this correct [Ny]? \c”
read; [[ $REPLY != [yY] ]] && exit
echo -e “\n$(tput smso)Enter to begin coping$(tput rmso) “$DEV” to “$FNAME”: \c”
read;echo
dd if=“$DEV” bs=1M conv=noerror conv=sync status=progress >“$FNAME”
xz -T4 -v “$FNAME”
ls -l “$FNAME”
Larry
3 Likes
@LDighera : Thanks, Larry! This is awesome. I assume it should work on any Linux where dd is installed? Will it work if run from the boot drive, on the boot drive? I know Linux puts locks on certain files, but those are system level and shouldn’t stop user files from being backed up, right?
@NullOrEmpty , I went through this a couple times getting started; the VIM4 is advanced enough over something like a Pi that there’s a bit of a learning curve. 
Have you updated the VIM4’s software? This is a different process than flashing the eMMC, and the closest thing I can analogize it to is flashing the BIOS or firmware. I assume that’s what it’s doing? Since everything is still in beta, there aren’t changelogs, but I’m pretty sure hardware support bugfixes can rely on getting the latest firmware.
When you get into OOWOW, it’ll offer to let you flash the eMMC. Cancel out of that and you’ll get a menu with more options. One of them is a software update. I’m guessing you’ll have one available.
@SinisterPisces dd is available on all *nix systems. It is a low-level bit copier, and knows nothing of files.
My little script will copy live/mounted drives, and as such, the data is changing, so there is possibility for issues. But, it works for me.
OOWOW update, just update OOWOW and its not related with OS images like ubuntu
NOTE: last fresh os images provided without oowow update
1 Like
Are there still efforts to improve the NVMe SSD reliability for Fenix kernels on the VIM4? Right now, these drives are unusable.
NVMe still randomly locks and corrupts data on the latest OOWOW Scripts July image from .test, vim4-ubuntu-22.04-server-linux-5.4-fenix-1.0.11-220704-develop.img.xz
I’ve also build a 1.1.1 kernel deb, and tested, resulting in bad superblock after a reboot.
I’m still using the widely compatible Sabrent Rocket 1TB, that I have on boards from Firefly, Radxa and Pine64, with the new M2X.
Temperature at CPU is running under 50 C, and I have separate large sinks on both the NVMe SSD, and the surface of the M2X itself.
On a related note, lm-sensors package isn’t included in the default Fenix builds and images. This would be useful!
Thanks,
— Jeremiah
Sabrent Rocket 1TB SSD has issues, right? As we don’t have such SSD on hand, so we can’t check now. Have you tried other SSD?
1 Like
yes will part still have problem, will be updated later
1 Like
Right now I haven’t. I had a few of these at hand, and they work with mainline kernels well, on VIM3 with MX2 and other mainline SBCs, mostly Armbian/Ubuntu Jammy.
That’s good to know - I’m not alone. I fixed similar PCIe / NVMe issues on 2014 MacBooks with Ubuntu. There were bits set incorrectly in the /sys/ hierarchy.
There still seems to be issues with the NVME drives I have on my VIM4 under the latest khadas release of Ubuntu -22.04-gnome. I’ve tried a Samsung Evo 970 Plus and a Netac N930E Plus, both of which work fine on other devices but have corruption when reading from them on the VIM4. I should also add that it doesn’t make any difference whether they are plugged into the board or a USB3 caddy.
1 Like
Could provide the steps so that we can reproduce on our side?
I’m running vim4-ubuntu-22.04-gnome-linux-5.4-fenix-1.1-220721.img.xz
I’ve got a Netac NVMe drive in a USB3 caddy. The drive is formatted as NTFS and works perfectly in every device I’ve used it on except the VIM4.
On the previous release, the drive would sometimes get picked up but would hang when trying to write anthing to it and sometimes it wouldn’t even show up. It didn’t matter whether it was plugged into the board or the USB in the caddy and it didn’t matter whether it was formatted with ext4 or NTFS - it was completely unusable.
After upgrading to the latest version, the drive seemed to be working fine but last month, I saved all the footage from my dashcam onto the drive using my Windows 11 notebook while we were on holiday. When I got home, I plugged the drive into the VIM4 and copied the files onto my NAS. When I played the files on my desktop computer they were jumping and skipping.
I plugged the drive into my desktop and they played perfectly so I plugged the drive into my QNAP NAS and re-copied them. When I played them on the desktop, they played perfectly.
I’ve just plugged the drive into the VIM4 and it isn’t even being ‘seen’ again. I’ve power cycled the VIM, which didn’t make any difference.
It still works in the NAS and my other computers however.
The drive doesn’t show up using lsusb and syslog contains this
Aug 19 06:31:37 localhost kernel: [ 88.015477@0] usb usb2-port1: attempt power cycle
Aug 19 06:31:41 localhost kernel: [ 92.179466@0] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
Aug 19 06:31:47 localhost kernel: [ 98.535687@0] usb usb2-port1: attempt power cycle
Aug 19 06:31:52 localhost kernel: [ 103.311660@0] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
Aug 19 06:31:52 localhost kernel: [ 103.311826@0] usb 2-1: the parent’s name is usb2
Aug 19 06:31:52 localhost kernel: [ 103.311868@0] usb usb2-port1: Device no response
Aug 19 06:31:56 localhost kernel: [ 107.383754@0] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
Aug 19 06:32:14 localhost kernel: [ 124.980104@0] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
Aug 19 06:32:24 localhost kernel: [ 135.308297@0] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
Aug 19 06:32:31 localhost kernel: [ 141.764446@0] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
Aug 19 06:32:36 localhost kernel: [ 147.332565@0] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
Aug 19 06:32:38 localhost Thunar[5986]: thunar-volman: There is no device with the sysfs path “/sys/devices/platform/soc/fde00000.crg3drd/xhci-hcd.0.auto/usb2/2-1”.
Unfortunately, the drive has a load of stuff on it that I don’t want to lose so I can’t do destructive testing with it ATM.
I’ve just tried a more powerful PSU and a different USB C cable but it didn’t make any difference. I tried a 64GB USB3 thumb drive which mounts, reads and writes perfectly. so the problem isn’t the USB socket. I removed the NVME drive from the USB caddy and plugged it into the socket on the board and it mounted fine. I’ll try writing and reading some stuff on it and let you know what happens.
1 Like