Beiträge von Barney

Can the "winner" be put into a release that does this automatically? Otherwise there will need to be some sort of documented process that people with USB NICs will have to follow.

Zitat von Soma

If you can revert to PRIOR those updates, maybe it's possible to check a diff somewhere/somehow, specially the first one

I thought about doing this but unsure how to go about it, especially since I have installed additional updates since Mar 11th. I continued to update in case one of them fixed the issue.. Is there some sort of tool or plugin that enabled one to pick and choose which items to revert? I guess that wouldn't be possible without having some sort of imaging built into OMV that stores prior releases.

I will volunteer to break one of my NAS to get this sorted out. It's considered a test bed anyway.

Zitat von Soma

Just some thought that cross the mind.

Perhaps something else is needed for lite versions to see the USB NIC since it's Realtek and there's no good stories with that brand on Linux. (AFAIK)

It's strange that the Desktop OS has no issues with it.

Well that was true for Bullseye, where the driver integration seemed only half working (the dongle works but limited to half duplex.) When going to Bookworm/OMV7 the ASUS USB-C2500 worked fine up until the Mar 11 release.

Here are the Mar 11 releases changes that broke the NIC boot. Maybe there is a clue?

dphys-swapfile (20100506-7.1+rpt3) bookworm; urgency=medium * Don't run if root overlay is enabled -- Serge Schneider <serge@raspberrypi.com> Mon, 11 Mar 2024 16:47:00 +0000

linux (1:6.6.20-1+rpt1) bookworm; urgency=medium * Raspberry Pi OS release * Remove unecessary patches * Add rpi featureset * Import Raspberry Pi defconfigs * Allow initramfs generation to be skipped in postinst * Move initramfs-tools to recommends * Install overlays README * Don't sign arm64 kernels * Compress arm64 kernel * Disable unecessary architectures * Use GCC 12 * Add +rpt to abiname * Add epoch support in version string * Linux commit: 6f16847710cc0502450788b9f12f0a14d3429668 -- Serge Schneider <serge@raspberrypi.com> Thu, 07 Mar 2024 14:51:31 +0000

raspi-config (20240228) bookworm; urgency=medium [ Tim Gover ] * Allow EEPROM upgrades [ Simon Long ] * Check wayvnc service to determine status -- Simon Long <simon@raspberrypi.com> Wed, 28 Feb 2024 14:54:21 +0000

raspi-config (20240216) bookworm; urgency=medium [ Simon Long ] * Call panel functions to update wifi country status when setting -- Simon Long <simon@raspberrypi.com> Fri, 16 Feb 2024 13:18:03 +0000

raspi-config (20240214) bookworm; urgency=medium [ Simon Long ] * Remove VNC resolution setting for Wayland -- Simon Long <simon@raspberrypi.com> Wed, 14 Feb 2024 13:04:45 +0000

raspi-config (20240213) bookworm; urgency=medium [ Simon Long ] * Add Wayland switching for x86 images -- Simon Long <simon@raspberrypi.com> Tue, 13 Feb 2024 07:37:56 +0000

raspi-config (20240131) bookworm; urgency=medium [ Simon Long ] * Remove logind power key settings in do_boot_behaviour -- Simon Long <simon@raspberrypi.com> Wed, 31 Jan 2024 12:48:28 +0000

raspi-config (20240130) bookworm; urgency=medium [ Simon Long ] * Add labwc screen blanking -- Simon Long <simon@raspberrypi.com> Tue, 30 Jan 2024 07:43:59 +0000

raspi-config (20240111) bookworm; urgency=medium [ Simon Long ] * Add labwc switching -- Simon Long <simon@raspberrypi.com> Thu, 11 Jan 2024 14:39:54 +0000

raspi-firmware (1:1.20240306+ds-1+rpt1) bookworm; urgency=medium * New upstream version 1.20240306+ds -- Serge Schneider <serge@raspberrypi.com> Wed, 06 Mar 2024 16:42:23 +0000

openmediavault (7.0.2-2) stable; urgency=low * Fix problem when deploying file system quota. * Issue #1725: Add search field to shared folder page. -- Volker Theile <volker.theile@openmediavault.org> Sat, 09 Mar 2024 16:48:27 +0100

I think both models run the same chip, but not perfectly confident on this.

I wonder if you need to run FirstAid, while I do not, is because it did work fine until the update for me so maybe I have a file already configured, while you don't. Seems odd you would have to keep doing that each time though.

It seems like it would be a trivial fix. We just need to get someone interested in helping us figure out what is halting during the boot and why the need to unplug the dongle.

This sounds like it might be related to my issue: RE: RPI updates - Ethernet dongle - Remote Mount

To summarize: I have two NAS boxes running OMV on RPI4 and Bookworm. Both NAS have the same ASUS USB-C2500 dongle and worked well under Bookworm, until an update to mostly RPI related was issued on Mar 11th. Since that day, I have to unplug and re-plug the dongle (I refer to this as the "dongle dance") during the OMV boot process in order to complete the boot sequence and get to the OMV UI. If I do not unplug/re-plug the dongle, the OMV will not boot but I can still get at the RPI command line (direct, not SSH which won't work until OMV finishes the boot sequence with the dongle dance.)

Once the dongle dance is performed, I get full bandwidth duplex mode. I am confident the issue has nothing directly to do with the Realtek driver and it's more of a OMV bootup sequence issue that halts until I perform the dongle dance. It was perfectly fine (no dongle dance needed) until the Mar 11th release.

I have looked at all the logs I can think of. The problem is the logs do not reference the dongle drivers at all without doing the dongle dance. So I can't tell what part of the process is broken but the CLI is telling me there is no connection to the router because there is no ethernet.

I've been patiently waiting for someone else to run into this as it seems there is not many in the 2.5 Ghz dongle community. These are not my primary media servers so I can live with it for awhile, it's only annoying.

Zitat von chente

Fortunately I see that you were wrong and that Seagate has a tool for Linux as you stated later. That changes things a bit.

I wasn't one who originally stated there was no Linux support. I went by what the OP stated. I don't spend time on the external website.

I also get the sense that I will always be "wrong" no matter what I say to you.

Well this is interesting, I decided to poke around the Seagate website and found there is a Linux version of Seatools. I have no idea if it's the same as Windows.

Zitat von chente

In my opinion what Seagate (and all other hard drive manufacturers) should do is be a little more transparent and adapt their firmware so that the SMART results are completely useful. If Seagate is not doing this it is because it is not interested in doing so. You just have to think a little to realize why, it would be too easy to request an RMA.

I just don't understand why you are interpreting my first message as somehow Seatools lacking transparency. If anything, it's TOO TRANSPARENT by keeping a count on correctable errors and seek errors, which are normal in any HDD.

Zitat von chente

However you are suggesting that SMART is not a reliable tool for determining the status of a Seagate hard drive.

Nope, that isn't what I said. I said it was the INTERPRETATION of SMART results that lead to people calling support. I did say that Seagate will track correctable errors in the RAW category, which winds up making people freak out and claim a failing drive.

It wasn't my intent to suggest that the lack of Seatools for Linux is because Seagate doesn't want to support people running Linux. I'm only stating fact, Seatools is only officially supported as a Windows platform tool. I don't make those decisions and that's just the way it is.

Big customers who are using the drives in server farms and their own high end products have their own custom tools and in some cases, the firmware on the drive is custom to accommodate those tools. Guess where the internal resources are going first to code the firmware and assist with tools?

Honestly I wouldn't make any purchasing decision based on the software OS the service tools are written. (conjecture alert) - Most home users probably don't even know what SMART is. Does WD and Toshiba have a diagnostic tool written for Linux? (I honestly don't know as I don't purchase their drives.)

Zitat von chente

I'm sorry, but I think your arguments fall under their own weight.

Well they are not "arguments", this is fact from being in the same part of the building with the very people who work on SMART code for new product. It's your right not to believe anything I say of course.

Zitat von gderf

I was satisfied, but I did insist on getting what they should have just done from the start.

Disclosure: I work for Seagate but not in customer support but I do know some stuff about SMART. I am not an expert so I won't answer any questions but I do feel I have a different perspective to share.

Incorrect or invalid SMART interpretations are one of the biggest issues with "no problem found" failure returns. Often it comes down to third party software that isn't following the protocol and starts throwing red flags with the presence of raw counts. That is why Seagate support is asking people to run the Seatools software because it's written in a way to separate garden variety errors from catastrophic issues.

SMART does a great job, maybe too good of a job, in recording ANY and ALL aspects of drive operation. For example, raw and seek errors are a natural occurrence with disc drives and not a sign the drive is failing. The drive ECC is designed to correct normal bit errors and the user can sleep fine. Unfortunately people dump their SMART history and panic because they see numbers all over the place. Bad third party software will interpret these numbers and flag them as a problem when they really are not a problem.

If there is an inordinate amount of raw errors in a particular sector, the drive will map the sector out and reallocate accordingly. I have drives that reallocated early in their life and never was a problem thereafter. I had other drives that kept reallocating sectors until SMART finally flagged the drive as failing. Why would correctable errors start showing up after factory pass? It could simply be the conditions they are operating under at the end user. Just running in an elevated temperature environment can expose a weak area of the media that ordinarily is fine at lower temps.

I get the fact that Seatools is Windows only and not everyone wants to bother finding a Windows box and a USB/SATA adapter. Unfortunately that is the best software to determine if the drive has an onset of a lethal condition.

I'm not passing judgement about the situations I have read here, just informing people that you should be careful in the interpretation of SMART dumps and why Seatools is considered the proper way to diagnose the drive by Seagate Support.

Can you also report GPU temp? (Or maybe that is the 2nd core referenced by the OP.)

On some occasions, I connect a four bay QNAP TR-400 DAS to my RPI via USB and OMV handles it just like any other pluggable USB storage. I cannot vouch for any other interface though (SAS or Thunderbolt.)

Zitat von mardeona

Just to follow up, I managed to upgrade to OMV6 successfully without any issues (thankfully!) but I still can't see the network card.

I wonder where my message got lost. I stated that I fought this issue on OMV6 for months and the ultimate fix was move to OMV7.

That switch is only rated to 100 Mb/s so all you'll ever yield is 12.5 MB/s and realistically that 11 MB/s is reasonable. Can you get your hands on a cheap 1000 Mb/s switch? You'll see 115 MB/s with that.

To add to gderf, if you already littered OMV5 with a bunch of drivers for the Realtek, I'm not sure what happens with those drivers with in-place upgrades. I didn't want to deal with any fallout from my mess so I did a full do-over and installed OMV from scratch (so I can only vouch for that.)

I feel your only solution is to move to OMV7. I fought the Realtek 8125/26/52/56 2.5 Ghz driver issue for months on OMV6 and finally got fed up enough to move to OMV7. Works perfectly under OMV 7, full bandwidth is realized (280 MB/s) although I still have an annoying initialization problem that started after an update (as documented here: RE: RPI updates - Ethernet dongle - Remote Mount)

Zitat von gderf

Targets NAS users with only two storage ports and no PCiE slot?

My assumption is the ethernet ports would be the connections for the raid but that requires a back end drive bay that has similar.