Weird File system SSD behavior

I was trying to help someone with a proprietary system that uses QNX. There was nothing nefarious about what we were trying to do. We just wanted to delete some files from an SSD. I ran into some strange behaviors that I’ve never seen before and I’m wondering if anyone knows anything about them.

I was sent an Intel SSD for the system. I don’t think the brand is relevant, but it might be. It had two partitions, each with a QNX 6 (power-safe) file system on it. It was created with QNX 7, not sure which version. I connected it to my QNX 6.5 system. I was unable to mount it read-write. I kept getting a message that it was read only. I was able to mount it read only and I could see all the files and copy them off.

Is there such a thing as a software read-only switch on an SSD? A lot of devices such as floppy disks and SD cards have such a switch that is mechanical.

The customer tells me that there is a procedure with his software than can import files which writes them to the SSD, so obviously it can be used read-write. I’m not at all sure what is blocking it.

Is there such a thing as a software read-only switch on an SSD? A lot of devices such as floppy disks and SD cards have such a switch that is mechanical.

Now before you ask, I did try to connect this to a QNX 7 system. I put the SSD in a USB enclosure and plugged it in. The system did not see the USB drive at all. My suspicion is that there are bugs in the USB driver code that came with the BSP but I’m not at all sure. It can read thumb drives. I suppose I should try it again with another SSD.

The SSD had a partition on it with a boot file. I tried creating a duplicate by creating partitions and copying the files to the correct location. I sent it back to the customer and it apparently didn’t work. One possible reason is that the system was ARM and the x86 boot code didn’t work. I’m not at all sure of this.

Any thoughts are appreciated.

Hello @maschoen,

I’ve had lot of compatibility problems (depending on brand and model) many years ago. This is not more the case today. But who knows…

Which system ?

I’ve never seen a hardware write lock on any SSD.
Software write lock… maybe : https://www.systutorials.com/docs/linux/man/8-scsi_ch_swp/

Did you use a USB2 port ? If it’s the case you get a power supply issue. Most of the time one USB2 port is not capable to provide enough power to a SSD. Either you have to supply the SSD on it’s own (if it’s possible) or you have to use a “Y” cable to draw power from 2 USB ports.

I asked “Which system ?” because from what I understand, the QNX6 filesystem is endian dependent. Datas are written to the disk with different byte order on big-endian and small-endian systems (however, It is possible to specify the endianess to mkqnx6fs utility). So if you used a system with an endianess different from the original one, this might be a problem. Just an idea…

Another idea : Have you tried to use the sync=optionnal option when mounting the filesystem with QNX 6.5 ? It might be the QNX 6.5 driver badly reports hardware capability as written here (see sync=mode option description) forcing the filesystem as read-only.

Nicolas

Thank you for the reply.

As far as the power issue goes, no. Along with hooking up the SSD via USB, I connected directly to a motherboard connection and the same thing happened, read-only. I did try sync=ignore which did not work either.

Which endian is a question that I never figured out for sure, however I was able to read the file system and copy files off of it. Someone online who took a look at the motherboard claimed it was an Intel chip.

I would think that if the endian-ness was wrong, I wouldn’t be able to do that, however I can see where QNX 6.5 might be smart enough to read, but not write it. I did look at the header on the executable and it looked correct.

If it is a driver problem it would be a weird one. You would think of all the brands that would work, Intel would be one of them. I am able to read and write to at least 2 other brands, Samsung and PNY.

One more idea came along. I found this intriguing image “qnx read only partition key” via google but I could not find any documentation on this. Something like that would be exactly what I would think could cause the problem.

I was not thinking about a SSD driver (which does not really exist) but about a motherboard hardware driver (like a SATA chip).
Only speculations, like all of my other answers…

Apparently there are some SSD’s that can have a read-only bit set to prevent tampering. I doubt this is the kind you have but such SSD’s exist

I also found this thread where someone’s SSD got stuck in read-only mode and they had to manually enable reading again (the SSD can go into this mode if it detects bad blocks). Maybe this is what happened.

Tim

I didn’t mean an SSD driver but rather a SATA driver.

Thanks for the info. The ones I’m dealing with are SSD’s enclosed in a SATA device. That would require SATA to have a way to do this.

My understanding is that all SSD’s go into read only mode when they can’t be written to again.

The only other thing I found was related to GUID partition tables bit 60 sets partition to read only.

QNX can write this type of file system (GPT image instead of an MBR one) but no idea whether it respects the read only bit.
https://www.qnx.com/developers/docs/7.0.0//index.html#com.qnx.doc.neutrino.utilities/topic/d/diskimage.html

So maybe it could have been done this way but I assume you can easily tell if it’s a GPT vs MBR image.

Otherwise I’d try it on a QNX 7 system in case something different in QNX 7 vs QNX 6.5 causes it to go into read only mode (64 vs 32 bit file system maybe).

Tim

Thanks again. I feel like we are so close. Unfortunately it is an MBR partition. :frowning:

I tried it on the only QNX 7 system I have right now and the USB didn’t detect the drive at all. I thought it was a driver problem but a previous post suggests a solution. Next time I’m going to use a power hub. It’s possible there wasn’t enough juice to power the drive.

It’s definitely a 64 bit QNX 7 as I found out by looking at a program header. There’s a byte that indicates 32 or 64 in the first few bytes of the file.

I’ve made a test with a SATA SSD connected to a ARM 32bit based board.

  • Partitioned the SSD with QNX7.1 (using fdisk, partition type : 179)
  • Formatted the SSD with QNX7.1 (qnx6 format)
  • Added a file on the SSD with QNX 7.1
  • Switched OS to QNX 6.6
  • Read the file with QNX 6.6
  • Modified the file with QNX 6.6 successfully

This is not QNX 6.5 and both OS versions are 32bit so the test is not completely valid.

There’s more to come here. I received a 2nd disk from the customer. There’s lots of new information here. First of all, like the first SSD it only mounts read-only on QNX 6.5. I again tried to connect it to an ARM board with QNX 7.1. The usb command sees the drive but devb-umass does not create a new /dev/hd#. I suspect that there is a configuration file in which this SSD device is not listed causing this problem. There never seemed to be the case on QNX 6 so I am not sure, but definitely disturbed by it.

I’m now trying to copy the SSD to another SSD. When I tried to do this with QNX 6.5 using USB enclosures, after about 1% the copy stalled. I did this twice. The problem was in devb-umass. The shell screen was frozen until I killed devb-umass which needed signal. = 9. I’ve never seen this QNX 6 system act this way.

I have been successful doing the copy using a Mac computer. It’s been running for about 4 hours and still isn’t done. When it is complete I hopefully will know if the read-only feature is hardware or software.
the
Both the previous and current SSD say Intel on drive however the USB command displays JMicron. I don’t know what this is about.

Last extra weird thing. For some odd reason, the creater of this SSD decided to insert three non printing characters into the WAV filenames. These three characters are 0xEF, 0x80, and 0x7A. Other than making it really hard to replace these files, I have no idea why they would do such a weird thing.

More later when the copy comples.

I’ve learned a lot since my last posting.

You can’t do a sector copy of an SSD to another one unless they have the same virtual geometry, head/track/cyliinder. This doesn’t seem to be a standard.

I finally figured out, more or less, why I’m having trouble mounting the partions read-write. The MBR partition table on the system’s disk has a 4 byte field called UEFI disk signature which is not zeros. The system must be UEFI. Why QNX 6.5 won’t mount the partions read-write doesn’t make any sense to me, but that seems to be the case. Zeroing out this signature does not help. Anyone have any ideas on this?

The 4 byte UEFI disk signature is just a unique number so that multiple disks can be identified correctly by UEFI and presented to the O/S. I am not surprised that zeroing that out does nothing.

If you google around you can find a few threads where others have run in to ‘read-only’ SSD / USB drives that they can’t format etc. This sounds similar to what you are running into and there is no clear solution for what to do (some people can’t even seem to format or use fdisk in Linux to fix the issue especially with SSDs)

On the other hand, I have a question for you. If you can read the QNX partition just fine in 6.5 (ie all files), then why are you trying to do a disk image copy? Why not just put a 2nd blank SSD in your USB enclosure, format it etc and then just do a cp command from the root directory to copy over the entire file system. Then you’ll have a read/write system on your new SSD. The only issue may be that the blank SSD isn’t UEFI since it’s in a USB enclosure so you may have to fiddle with that a bit to make it UEFI (or do the format/copy process on a UEFI machine instead of the USB enclosure) or else it may not work in the original system.

Tim

You are always perceptive Tim. Here’s a little more info before I answer your question.
The read only partion has nothing to do with the particular SSD hardware. I know this because I bought a new SSD of a different brand and was able to create a QNX 6 partition on it that could be mounted read/write. But when I did a sector by sector copy, the new SSD had the same problem. The mount command refused to mount it read-write but allowed it be mounted read only.

I found that this problem was specifically connected to something in the first sector. Neither zeroing out the UEFI signature nor changing the partition parameters alone would allow read-write access, but the combination of the two did. Whatever the exact pattern or formula that was, it seems like it was coded into the mount command. The QNX 6 file systems are pretty weird so I don’t really know that this is true.

In answer to your question, I did try creating the new SSD the other way, putting partitions on it, initializing them and just copying the files using cp. As you suspect this would not boot on the target system. Since it is in Texas and I am in California, it would not be practical for me to try fiddling with the UEFI signature as that would require a lot of mailing an SSD back and forth.

I should however say that the problem does seem to be solved as during my investigation I discovered that the file names had weird invisible embedded characters 0xEF, 0x80 and 0x7F in the middle of the file names. Knowing this the customer was able to accomplish what he wanted with a provided utility which replaced the factory default files with his own.