FlamongOle

Can't hurt if you can't find the solution by saving the configuration, dunno what's going on there as I can replicate it myself

Did you try to restore a backup?

No real defaults there either, just choose whatever feels important. Anyway, what's initial set is listed in the code here: https://github.com/olehj/disklocation/blob/master/disklocation/pages/sqlite_tables.php#L52-L86

There's no real default here, pick whatever you like. Newest implementations are the icons, which "default" to "Unraid", and LEDs to "dynamic". However, "static" would be more default Unraid system wise.

Update 2024.10.28 Commit #334 - BUG: Found the root cause of the blank dashboard issue. A file got symlinked with "null" instead of the actual file (duplicate of #328 and #333). Nothing more than that.

I updated the plugin a bit again: Commit #331 - BUG: (Update 1337) Used wrong datatype in the database for a new function, might have caused an issue where you must manually save the config again. I think this might have caused the issue, the other one you refers to there, should have been fixed in the last installer script. You will see a new database will be updated due to faulty datatype.

Likely due to old existing corrupted database, restoring previous database under "System" tab should fix it.

Update 2024.10.27-1337 Commit #331 - BUG: (Update 1337) Used wrong datatype in the database for a new function, might have caused an issue where you must manually save the config again. Commit #328 - BUG: Added a check for existing cronjobs during installation and removal. Automatic update was likely started the exact time as the database update, and the installer ignored that partly. Also fixed an error where the plugin would be inaccessible if the database are indeed corrupted. Also enabled manual lock file deletion under System tab again, this will only be visible when it exists. Commit #327 - BUG: Backup button disappeared when there were no backups available. Commit #326 - MINOR: Styles for LEDs now restored after reinstallations and upgrades. 2024.10.27 vs 2024.10.27-1145: nothing special, just minor cleanup. Thanks to @Starfiresg1 for providing logs, this helped for debugging! Those with corrupted databases should restore database from backup. You got backup, right? To clear up some other confusions: It should never be required a reboot when installing, removing or reinstalling this plugin - even after failures as this last update. Only hardware changes -might- require it, but often "Force update all" would fix several issues. There's no rollback available, even if you have an older installation file, it will still pull the latest from the master branch on github. I do not package the releases manually. There's just "master" and "devel", at least for now. It's impossible to test all scenarios that might occur and bugs like this will happen, it has happened before, it will happen again. As stated in GPL license, this software comes without any warranty: https://github.com/olehj/disklocation/blob/master/COPYING

You can also try to delete the plugin, and then install this manually for testing: https://raw.githubusercontent.com/olehj/disklocation/devel/disklocation-devel.plg There's something fixed, but dunno if it's related. Any feedback appreciated. @elitexero @Gragorg @Gingertosser @TallMan206

Hmm, this is strange. I can't see why it does not work as it does here. Can someone go to Tools -> PHP Settings -> select "All categories" and Apply that. Then install the plugin, go to dashboard. Then back to PHP Settings and fetch the log for me. I found out why, this will reappear next update, sorry for that.

Update 2024.10.26 Commit #324 - FEATURE: Choose dynamic and static styles for LEDs (minor known bugs: this is not completed entirely, and will reset every update/reinstallations). Commit #323 - FEATURE: Under configuration you can now set to display LEDs in all color coded circular modes instead of Unraid icons. Commit #322 - IMPROVEMENT/MINOR: The "delete all" button and database move/delete requires now an additional checkbox to be performed. Also moved the backup button to a more sensible area. Some SQL syntax tweaks that will hopefully cause less corruption. Commit #321 - MINOR: Sometimes the colors behaved weird when saving custom colors. This happened caused by some variables being loaded after the execution of a function that required the info before.

I know there's some bugs with the custom colors, however it should mostly work. You can first try to press "Reset all custom colors", then you must make sure you don't use the same colors as defined under "Common configuration" for custom colors under "Tray allocations". They can also NOT be in "heat map" mode.

Might be, I couldn't see anything in the diagnostic about exactly that. Anyway, the Unraid team got 3 different diagnostics from me. But most important is that it now works.

It was not used by another pool, it was just unavailable for some reason. It remained on the pool I assigned it too. Anyway, I disabled it now and hope I rather can enable it safer in the future (v7). It's not a crisis and will do for the time being as a cold spare. Thanks anyway for pointing it out. It's a nasty bug regardless.

Look at that! So, no spares in ZFS yet. Thanks @JorgeB!

Now, that looks more promising. I will try to do that right away as I do have a spare drive in a zfs pool. I even see it as "UNAVAIL" too, so something there happened. I will report back as soon as I can confirm this. Thanks!

Unassigned devices is by fact a plugin, even though it's probably "included by standard" by now: /config/plugins/unassigned.devices/ Absolutely everything under /config/plugins/ was removed for one test, including plugins-removed and plugins-error. I have been going through every single file, and there's nothing there that can cause this problem. I even tried one more time now after cleaning up some additional old share configs. It's just doing the same over and over, wiping the flash drive, but only the one UNRAID is on, and only after everything has mounted. Plugins, dockers, VMs can all be ruled out. IPMI is a plugin too, and I don't see how that should by itself call for a "wipefs", makes no sense. Yes, I do use IPMI.

No way I'm posting my backup. But again, this is already answered. Please read my initial post. It clearly says I have tried multiple drives and ports. That means that /dev/sdb was not the same between the swaps. About all my points in the first post is a fresh install, just different configs. Without plugins, there's no configuration to be done in the plugin you suggest even. As I said, I removed and purged all of it. This is a system which ran without issue for so long, and suddenly started to act up. It feels weird if this is hardware related at all. But I don't understand why wipefs would run at all, it makes no sense.

Everything you just asked, is already answered. But I can clarify that, yes, it is FAT32, drive called uppercase UNRAID. No, it's not an HDD. It's not a problem that I can boot it, it's that Unraid runs wipefs after everything has booted up, meaning: it can't boot next time! Startup scripts are not available once the plugins are all gone/disabled. Yes, I have something small in the "go" file which has been identical since I started using Unraid. Nothing that should run or activate wipefs anyhow.

I honestly have no clue if this is a bug or if there's something really weird with my setup .. suddenly. I haven't really changed anything, but now after every boot, the Unraid flash drive gets wipefs'd and then Unraid runs in emulated mode. Everything works, until next boot and nothing gets stored if I try to save settings (I save them manually from a 1 day old backup directly in the config files if required for my debugging). This is probably the interesting bit of the logs from the drive itself - this is output from first start of the array under "Maintenance mode" which works fine, drive still accessible and all. Then when I start the array the operational way, it will start wipefs: BOOT: Oct 23 20:35:01 Odin kernel: sd 7:0:0:0: [sdb] 125313283 512-byte logical blocks: (64.2 GB/59.8 GiB) Oct 23 20:35:01 Odin kernel: sd 7:0:0:0: [sdb] Write Protect is off Oct 23 20:35:01 Odin kernel: sd 7:0:0:0: [sdb] Mode Sense: 43 00 00 00 Oct 23 20:35:01 Odin kernel: sd 7:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Oct 23 20:35:01 Odin kernel: sdb: sdb1 Oct 23 20:35:01 Odin kernel: sd 7:0:0:0: [sdb] Attached SCSI removable disk Starting maintenance mode: Oct 23 20:36:03 Odin emhttpd: Samsung_Flash_Drive_0391923080011130-0:0 (sdb) 512 125313283 Oct 23 20:36:04 Odin emhttpd: import flash device: sdb Oct 23 20:36:04 Odin emhttpd: read SMART /dev/sdb Starting normal mode: Oct 23 20:40:30 Odin emhttpd: read SMART /dev/sdb Oct 23 20:40:33 Odin emhttpd: Samsung_Flash_Drive_0391923080011130-0:0 (sdb) 512 125313283 Oct 23 20:40:33 Odin emhttpd: import flash device: sdb Oct 23 20:40:34 Odin emhttpd: read SMART /dev/sdb Oct 23 20:43:04 Odin emhttpd: shcmd (550): /sbin/wipefs -af /dev/sdb1 Oct 23 20:43:04 Odin root: /dev/sdb1: 8 bytes were erased at offset 0x00000052 (vfat): 46 41 54 33 32 20 20 20 Oct 23 20:43:04 Odin root: /dev/sdb1: 1 byte was erased at offset 0x00000000 (vfat): eb Oct 23 20:43:04 Odin root: /dev/sdb1: 2 bytes were erased at offset 0x000001fe (vfat): 55 aa Oct 23 20:43:04 Odin emhttpd: writing MBR on disk (sdb) with partition 1 offset 64, erased: 0 Oct 23 20:43:05 Odin emhttpd: re-reading (sdb) partition table Oct 23 20:43:05 Odin emhttpd: error: mkmbr, 2196: Device or resource busy (16): ioctl BLKRRPART: /dev/sdb Oct 23 20:43:10 Odin emhttpd: shcmd (552): /usr/sbin/cryptsetup luksFormat /dev/sdb1 --key-file=/root/keyfile Oct 23 20:43:10 Odin root: Cannot use device /dev/sdb1 which is in use (already mapped or mounted). What I have tried: rolled back to Unraid version 6.12.11 2 different kernels (unraid original + intel gpu kernel) disabled all plugins (-all-, even my own, including purging of configs) disabled dockers (VM's I don't use and are disabled). different USB ports (both USB 2.0) different USB drives enabled and disabled "destructive mode" in "Unassigned devices" plugin tried to use both the windows usb creator on my work laptop, the real manual way on my computer including the usb creator for linux (which didn't like 64GB drive), but doesn't matter, all methods behaved the same. Most of these are a desperation of making it work, but it seems like it's software related beyond user related inputs. I have no idea at this point, and don't see anything logic in the logs either (I have attached the diagnostic file). Once I shutdown the system, I must recreate the USB flash drive again, copying my backup back onto it, running make_boot script etc. before I can start it. Reboots will just hang with an empty flash drive. I have NO idea why it want to run wipefs on the flash drive, it makes absolutely no sense when the drive is even working as expected.

Non stable releases are not supported. This will be looked into when that happens.

Did you also mess with choosing a SMART controller yourself? Either under "Disk Settings" for global, or under the device itself? I can't see why it shouldn't work otherwise. Please check anyway, in case you have set it to "ATA" and not let it be automagic.

Go to "Disk Settings" and select "Automatic" instead of "ATA" which is likely incorrect anyway (most HDD's today uses SATA which is part of the SCSI controller).

Not currently, no

Some SMART data is there. What did you try to do?