Samsung Firmware Update Linux

[Cookie Grosky]

Ifound new firmware for my drive on the Samsung web site. I am trying to install it by the instructions in Arch Wiki article Solid State Drive. The loop device is created, but the downloaded iso will not mount:

Reading the samsung pages indicates that Magician software is not available for linux. Use Samsung DCToolkit.

Did you mkdir Samsung_SSD_850_PRO_EXM04B6Q ?? and cp -r /run/media/$USER/CDROM/isolinux /Samsung_SSD_850_PRO_EXM04B6Q etc,etc. as per wiki page.???

As I showed in post #2, there is no directory named Samsung_SSD_850_PRO_EXM04B6Q or anything like that under directory isolinux. Only the four files I listed. That is why I have no idea how to proceed.

OK.

I've now tried it a few times and all goes well until the actual update process (using Magician from AUR) it always fails with cannot find DSRD file. The wiki process went well. I'm trying to update an SSD_EVO_860.

Best of Luck.

There are stories of people seeing decreasing performance as the NAND cells degrade in this TLC SSD. There was a firmware update in October 2014 and then a another one in April 2015 attempting to correct the issue.

After giving up trying to make the USB stick I flashed the image to boot with my BIOS, I resorted to using GRUB2. To boot this mess, place the files somewhere accessible (i.e. /boot partition or USB stick) and run the following commands on the GRUB2 command line:

For this partition, a rarely used 14% full 124GB btrfs partition, the first 20% of the partition had volatile throughput performance. The before and after results were quite repeatable with and more tests can be found on Imgur. The latency was all over across tests since the disk partially in use by some background tasks in Linux, but largely unchanged by the update. I speculate that the volatile performance is in the region of the disk where data is actually stored, the numbers seem to make sense.

The biggest shock of the firmware update is all the new SATA errors my kernel (Arch Linux pkg linux 4.0.1-1) has been spewing on the same interface the SSD is on. I went from a fast drive with minor performance inconsistencies to a consistently (slightly) slower drive with SATA link timeouts. Great!

Compared to hard drives, where deleting a file is only handled at the file system level[1], SSDs benefit from informing the disk controller when blocks of memory are free to be reused. Since the flash cells they are made of are worn out a little with each write operation, the disk controllers use algorithms to share the write operations on all the cells: this process is called wear leveling. Without the NVMe DEALLOCATE, SAS UNMAP or ATA_TRIM command (supported by most SSDs), the disk controller takes more time to do a write operation as soon as there is no empty memory blocks, as it has to shuffle data around to erase a cell before writing to it (see Wikipedia:Write amplification): a TechSpot benchmark shows the performance impact before and after filling an SSD with data.

The util-linux package provides fstrim.service and fstrim.timer systemd unit files. Enabling the timer will activate the service weekly. The service executes fstrim(8) on all mounted filesystems on devices that support the discard operation.

The timer relies on the timestamp of /var/lib/systemd/timers/stamp-fstrim.timer (which it will create upon first invocation) to know whether a week has elapsed since it last ran. Therefore there is no need to worry about too frequent invocations, in an anacron-like fashion.

Instead of issuing TRIM commands once in a while (by default once a week if using fstrim.timer), it is also possible to issue TRIM commands each time files are deleted instead. The latter is known as the continuous TRIM.

Using the default mount options instead of an entry in /etc/fstab is particularly useful for external drives, because such partition will be mounted with the default options also on other machines. This way, there is no need to edit /etc/fstab on every machine.

No LVM operations (lvremove, lvreduce and all others) issue TRIM requests to physical volume(s) by default. This is done to allow restoring previous volume group configuration with vgcfgrestore(8). The setting issue_discards in /etc/lvm/lvm.conf controls whether discards are sent to a logical volume's underlying physical volumes when the logical volume is no longer using the physical volumes' space.

On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time the device was installed, thus restoring it to its factory default write performance. Write performance is known to degrade over time even on SSDs with native TRIM support: TRIM only safeguards against file deletes, not replacements such as an incremental save.

Some motherboard firmware issue a ATA SECURITY FREEZE LOCK command to SATA devices on initialization, setting the drive to frozen mode which transitions it to SEC2 state (security disabled, not locked, frozen). Likewise some SSD (and HDD) are set to this state in the factory already. This can be seen in hdparm and smartctl output:

The above hdparm output shows the device is not locked by a HDD-password on boot and the frozen state safeguards the device against malwares which may try to lock it by setting a password to it at runtime.

If you intend to set a password to a "frozen" device yourself, a motherboard BIOS with support for it is required. A lot of notebooks have support, because it is required for hardware encryption, but support may not be trivial for a desktop/server board. For the Intel DH67CL/BL motherboard, for example, the motherboard has to be set to "maintenance mode" by a physical jumper to access the settings.[10]

When waking up from S3 sleep, the SATA SSD will most likely have reverted to SEC1 state (security disabled, not locked, not frozen), leaving it vulnerable to ATA SECURITY ERASE UNIT commands like those described in /Memory cell clearing.

If the system has multiple storage devices and/or portable USB-drives, another option is to adapt Hdparm#Persistent configuration using udev rule to issue a --security-freeze for all drives (incl. HDD).

As noted in #Frozen mode, setting a password for a storage device (SSD/HDD) in the BIOS may also initialize the hardware encryption of devices supporting it. If the device also conforms to the OPAL standard, this may also be achieved without a respective BIOS feature to set the passphrase. See Self-encrypting drives.

It is possible that the issue you are encountering is a firmware bug which is not Linux specific, so before trying to troubleshoot an issue affecting the SSD device, you should first check if updates are available for:

ALPM is enabled by default since linux-4.16, or may be enabled at runtime by a power saving daemon (e.g. TLP, Laptop Mode Tools). See Power management#SATA Active Link Power Management for more on this.

But the kernel may not automatically detect this capability, and therefore might not use it.Assuming your block device in question is /dev/sdX, you can find out whether that is the case by using the command from sg3_utils:

If in its output you find a line stating "Logical block provisioning: lbpme=0" then you know that the kernel assumes the device does not support "Logical Block Provisioning Management" because the (LBPME) bit is not set.

If this is the case, then you should next find out whether the "Vital Product Data" (VPD) page on "Logical Block Provisioning" of your device tells of supported mechanisms for unmapping data. You can do this using the command:

If the kernel did not detect the capability of your device to unmap data, then this will likely return "full".Apart from "full", the kernel SCSI storage driver currently knows the following values for provisioning_mode:

If you want to enable a "provisioning_mode" automatically when an external device of a certain vendor/product is attached, this can be automated via the "udev" mechanism. First find the USB Vendor and Product IDs:

Updating SSD firmware under Linux is not supported by ADATA. A Windows-only utility called SSD ToolBox is provided by ADATA through their support page and through their ADATA XPG support page to monitor, TRIM, benchmark and update ADATA SSD firmware.

If an update is available, it is performed by running intelmas load -intelssd 0. The PDF user guide suggests that this procedure needs to be performed twice in Linux, with a power cycle in between. The latest firmware for all devices is distributed as part of the MAS Tool itself, so does not need to be downloaded separately.

Although Samsung deems firmware update methods outside of their Magician software as "unsupported", they still can work. The Magician software can create a bootable USB drive containing the firmware update, however Samsung no longer provides the software for consumer SSDs. Samsung also provides pre-made bootable ISO images that can be used to update the firmware. Another option is to use Samsung's magician utility provided by samsung_magician-consumer-ssdAUR. Magician only supports Samsung-branded SSDs; those manufactured by Samsung for OEMs (e.g., Lenovo) are not supported.

Users preferring to run the firmware update from a live USB created under Linux (without using Samsung's Magician software under Microsoft Windows) can refer to [11] for more details. Note that this blog post details creating a bootable USB drive with Master Boot Record (MBR) that some newer motherboards, e.g. Intel NUC no longer support.

If after reboot the firmware version does not change, run root/fumagician/fumagician 2> log and search for errors in the log file. For example, if the log shows 'unzip is not available', install unzip or extract it from the initrd.

Some of the SSD firmware ISO images contain a FreeDOS image instead of an initrd Linux image, so the steps needed to update the SSD firmware differ from above. The following table lists these SSDs (and relevant paths):

I was successful installing linuxtrack (Linux 64bit universal package) and running it from terminal using ltr_gui command. My TrackIR device is recognized. When I click "Install Firmware", and use "Extract from Installer", I select the downloaded file TrackIR_5.3.0.exe (I also tried TrackIR_5.4.2.exe), and Wine begins the effort to extract the files needed, but then there is an error message saying it could not extract the files.

3a8082e126