Fedora 41 -- trona - hardware overhaul

June 10, 2025

Fedora 41 -- new hardware for trona

This has essentially nothing specific to Fedora, but if that upsets you, just move on.

This started with two things. One is/was a 4T HDD that was getting flakey. The other was a better video board (an RTX 3060) for the purpose of running DaVinci Resolve. Then one thing led to another, and we have this list:

Fractal Designs North Case - $139
Seasonic Focus 750W PSU - $130
Noctua NH-U9S CPU cooler - $70
8T WD HC320 Ultrastar drive - $250
Gigabyte RTX 3060 12G - $275
Samsung 990 EVO plus 4T - $259
Crucial T500 1T NVMe - $85
Transcend 256G mSATA - $36
(2) SABRENT PCIe to NVMe - $32

So, we are replacing everything but the motherboard, CPU, and memory.
I'll note on the RTX 3060 that a new Gigabyte board, just like the one I got sells for $354, so I only saved $75 by buying one on Ebay -- but it seems to work fine.

Testing the Power supply

I am always reluctant to connect a new PSU to a motherboard, and Seasonic nicely ships a little "tester" that jumpers the right two pins on the CPU power connector and makes the PSU fire up. It is a fully modular supply, so I also plugged in a Molex cable, as that gives easy access to 5 and 12 volts. I measure those values as good (it is a nice surprise that the Seasonic performs without a load) and I am satisfied.

Move to the new case

This will be the perfect time to install the CPU cooler. The aim will be to get the existing set of parts working in the new case and move on from there. So we do that. We move the motherboard to the new case and install the Noctua cooler. Then we bring the system up using the old video card and only the /u1 disk (along with the system root disk on the old IT SSD). It comes up fine, albeit I did have to edit /etc/fstab to tell it the /u1 disk was not there.

Test that new video card

This is a big event, plugging in the RTX 3060. It works, but with some issues.

I also installed the new 8G drive (the HC320) while I had the system shut down. It shows up as:

Disk /dev/sdd: 7.28 TiB, 8001563222016 bytes, 15628053168 sectors
Disk model: HGST HUS728T8TAL

The problem with the video card is that when I login, resolution changes to 2560x1440. Before I logged in, the resolution looked fine as it displayed a background image I had chosen. This is clearly a linux configuration problem, not any kind of hardware issue. So the Ebay purchase of the 3060 card seems OK. And I am not getting any fan noise. I guess those 3 fans will only get going when the video card gets busy in some way.

The fix for this is simple and easy. I am running Xfce. I go to "Settings" and I see "NVIDIA X server settings". I go in there and find a menu where I can select 3840x2160, click "Apply" and tell it that it looks good and should keep that setting.

The display for my desktop backgrounds is not working. After some trial and error, I discover it is now:

PROP=/backdrop/screen0/monitorDP-2/workspace0/last-image

There were two display port connectors on my new 3060 card, and perhaps I picked the wrong one.

The resolution does not stay "fixed". There is another place to fool with it in "Settings", "Display". And indeed, once I select 3840x2160 here, it sticks.

An online posts suggests looking at:

.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml

But I have not need to do that.

Format and partition that 8G drive

Looking at my 4T drive, I see this:

/dev/sdb1      2048      98303      96256   47M Linux filesystem
/dev/sdb2     98304   31445312   31347009 14.9G Linux swap
/dev/sdb3  31445313 7814037134 7782591822  3.6T Linux filesystem

I had this drive arranged in such a way that I could have set it up to be my boot disk (almost). It lacks a BIOS boot area like this, which I have on my 1T SSD that I do boot from:

/dev/sda1        2048       4095       2048     1M BIOS boot
/dev/sda2        4096   67112959   67108864    32G Linux filesystem
/dev/sda3    67112960 1140854783 1073741824   512G Linux filesystem
/dev/sda4  1140854784 1953523711  812668928 387.5G Linux filesystem

This is all about possible disaster recovery. But as I think about this more, I think that I will have spare SSD to deploy if my system disk fails and I don't need to set up any of that on this 8G disk, which is solely for backups.

I will set up one big partition on /dev/sdd that will be the entire disk. We have to use "parted" as good old fdisk will not create partitions bigger that 2T. I have notes on this from a prior install of a 4T drive.

Typing print at the start gives you a chance to verify that you are working on the correct disk!

print
mklabel GPT
mkpart "u8" ext4 2 -1s
print
quit

I get the warning"

Warning: You requested a partition from 2000kB to 8002GB (sectors 3906..15628053167).
The closest location we can manage is 2000kB to 8002GB (sectors 3906..15628053134).
Is this still acceptable to you?

It warns me that it is not ideally aligned for best performance, but it always warns about that, and nobody knows what it really wants. We accept the above and till it to ignore the latter. Now we do this:

mkfs -t ext4 /dev/sdd1

My plan is to mount this on /u8 (since it is an 8T drive) and let /u1, /u2 and so forth be various SSD that I will be adding. I need to turn off my old cron backup script, which is run from /etc/cron.daily as "tjt_backup". This simply runs /u1/Backup/trona_mirror. I edit the latter and comment it out for now.

I am going to try this, which will undoubtedly run all night:

cd /u1
umask 0
tar cf - . | ( cd /u8 ; tar xpf - )

I tried this once before, peeked at it while it was running and saw file permissions and ownerships I did not like, but I suspect that if I had let it finish, everything would have been OK. We will be more patient this time

I let it run overnight, and here we are about 15 hours later and it is still running! It finished at 9:12 AM after being started at 4PM the day before, so 17 hours more or less. Indeed, all the ownerships and permissions look correct. So /u8 is now 39 percent full. The original /u1 was 77 percent full. We moved .77 * 4 = 3.08 terabytes.
We saw these warnings:

tar: ./tom_archive/.adobe/Acrobat/9.0/Synchronizer/Commands: socket ignored
tar: ./tom_archive/.adobe/Acrobat/9.0/Synchronizer/Notification: socket ignored
tar: ./rails_user/.gnupg/S.gpg-agent: socket ignored
tar: ./rails_user/.gnupg/S.dirmngr: socket ignored
tar: ./Projects/Garmin/Files/GPX: time stamp 2027-12-31 11:00:06 is 80657648.418159069 s in the future
tar: ./tom_f23_pristine/.gnupg/S.gpg-agent: socket ignored
tar: ./home/tom/.cache/google-chrome/Default/Cache/Cache_Data: file changed as we read it
tar: ./home/tom/.cache/JetBrains/IdeaIC2023.1/.port: socket ignored
tar: ./home/tom/.cache/keyring-XSE7CZ/control: socket ignored
tar: ./home/tom/.config/google-chrome/Default: file changed as we read it
tar: ./home/tom/.dropbox/command_socket: socket ignored
tar: ./home/tom/.dropbox/iface_socket: socket ignored
tar: ./home/tom/.thunderbird/y4he6kw8.default: file changed as we read it
tar: ./home/tom/.ServiceHub/48afd0feb0/a0300bac87: socket ignored
tar: ./home/tom/.ServiceHub/48afd0feb0/1840613F80: socket ignored
tar: ./home/tom/.ServiceHub/48afd0feb0/48afd0feb0: socket ignored
tar: ./home/tom/.ServiceHub/48afd0feb0/b0b9805361: socket ignored
tar: ./home/tom/.ServiceHub/48afd0feb0/1840612BA3: socket ignored
tar: ./home/tom/.adobe/Acrobat/9.0/Synchronizer/Commands: socket ignored
tar: ./home/tom/.adobe/Acrobat/9.0/Synchronizer/Notification: socket ignored

There were no suspicious messages or warnings in the logfile, only this when the system booted and discovered the new 8T drive:

Jun 10 14:52:59 trona kernel: ata8: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Jun 10 14:52:59 trona kernel: ata8.00: ATA-9: HGST HUS728T8TALE6L4, V8GNW9U0, max UDMA/133
Jun 10 14:52:59 trona kernel: ata8.00: 15628053168 sectors, multi 16: LBA48 NCQ (depth 32), AA
Jun 10 14:52:59 trona kernel: ata8.00: Features: NCQ-sndrcv NCQ-prio
Jun 10 14:52:59 trona kernel: ata8.00: configured for UDMA/133

Uninstalling Davinci Resolve

What is this doing here you ask?

cd /u1/Resolve/DaVinci_18.6
./DaVinci_Resolve_18.6.6_Linux.run -u

Does an M.2 drive need a heatsink?

It never hurts. People say that if the drive didn't come with a heatsink, then it doesn't need one. People say unless you are running a server and reading and writing to it constantly, no you don't. Others say anything 5.0 (or even 4.0) needs one, and any module that claims 5000+ transfer speeds needs one.

First excitement with an M.2 nvme SSD

I place my Samsung 990 EVO plus into my Sabrent PCIe to NVMe adapter and plug it into my system in the slot closest to my RTX 3060 card. When I boot up linux, I see:

fdisk -l
Disk /dev/nvme0n1: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: Samsung SSD 990 EVO Plus 4TB
ls -l /dev/nv*
crw------- 1 root root 237,   0 Jun 11 18:15 nvme0
brw-rw---- 1 root disk 259,   0 Jun 11 18:15 nvme0n1

The "nvme0" device is a character (raw) device, and is not what we want to partition or format. The other is a block device. We will need to use parted to fiddle with it

parted /dev/nvme0n1
print
mklabel GPT
mkpart "u1" ext4 0 -1s
print
quit

We get the usual stupid parted warnings:

Warning: You requested a partition from 0.00B to 4001GB (sectors 0..7814037167).
The closest location we can manage is 17.4kB to 4001GB (sectors 34..7814037134).
Is this still acceptable to you?
Yes/No? yes
Warning: The resulting partition is not properly aligned for best performance: 34s % 2048s != 0s
Ignore/Cancel? i

This is incredibly lame and stupid. I decide to search and learn about this. I find this article:

Parted is stupid

The hot tip in here is to use percentages, like this:

mkpart "u1" ext4 0% 100%
print
 1      1049kB  4001GB  4001GB  ext4         u1

This works. No errors. And now we see this:

crw------- 1 root root 237,   0 Jun 11 18:15 /dev/nvme0
brw-rw---- 1 root disk 259,   0 Jun 11 18:35 /dev/nvme0n1
brw-rw---- 1 root disk 259,   2 Jun 11 18:35 /dev/nvme0n1p1
fdisk -l
/dev/nvme0n1p1  2048 7814035455 7814033408  3.6T Linux filesystem

So now, let's format it and start a copy to it:

mkfs -t ext4 /dev/nvme0n1p1
mkdir /u3

cd /u1
umask 0
tar cf - . | ( cd /u3 ; tar xpf - )

We start it at "Wed Jun 11 06:40:49 PM MST 2025".
We finish at "Thu Jun 12 10:46:40 AM MST 2025".

Switch to the SSD

I power the system down (after editing fstab) and remove the ailing 4T HDD. I insert a second NVMe drive (the Crucial T500) in another PCIe to NVME adapter. Then up we come. It now sees:

crw------- 1 root root 237, 0 Jun 12 16:49 /dev/nvme0
brw-rw---- 1 root disk 259, 0 Jun 12 16:49 /dev/nvme0n1
crw------- 1 root root 237, 1 Jun 12 16:49 /dev/nvme1
brw-rw---- 1 root disk 259, 1 Jun 12 16:49 /dev/nvme1n1
brw-rw---- 1 root disk 259, 2 Jun 12 16:49 /dev/nvme1n1p1

For whatever reason, my 4T SSD has become nvme1, so it comes up in emergency mode and I have to make that change to the fstab. But now I am up and want to set up the Crucial SSD.

fdisk -l
Disk /dev/nvme0n1: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: CT1000T500SSD8
fdisk /dev/nvme0n1
-- make new partition, primary, start 2048, end at last sector
mkfs -t ext4 /dev/nvme0n1p1
-- edit fstab
mount /u2

Check the drive temperatures

nvme smart-log /dev/nvme0 (Crucial)
nvme smart-log /dev/nvme1 (Samsung)

I see with both drives doing not very much:

root@trona:/u2# nvme smart-log /dev/nvme1 | grep Temp
Temperature Sensor 1			: 134 °F (330 K)
Temperature Sensor 2			: 105 °F (314 K)
root@trona:/u2# nvme smart-log /dev/nvme0 | grep Temp
Temperature Sensor 1			: 95 °F (308 K)

The 134 temperature worries me (I removed the heat sinks), but I read that the operating range for these is 0-70C. And 70C is 158F. We are now at about 57C. This is OK, but bears watching.

A copy from SSD to SSD

This is my /u1/Projects directory. It took 11 minutes to move 200G of data. So moving 1T would take 5 times as long (55 minutes).

Compare this to the 16 hours for 3T above. This is 5.3 hours per terabyte. So going SSD to SSD is 5 times faster.

Have any comments? Questions? Drop me a line!

Adventures in Computing / tom@mmto.org