Holaf
Members
-
Joined
-
Last visited
Everything posted by Holaf
-
I'll have to change my scripts to do so. I will try to include this option in the next version
-
@Bunger try to delete the file named "Delete_this_file_to_clean_virtual_env_and_dependencies_at_next_launch" It will reinstall all dependencies and you should have torch 2.4.1 after that. @ZiRiuS Sorry I don't understand want you want to do with Open WebUI
-
ChatGPT et moi on vote pour une grappe 😎 Et je rajouterais que matrice pour une grappe de disque je trouve que ca va pas du tout 😅
-
Easy diffusion isn't under active devellopment. You can either wait for them to fix this bug or try another WebUI. I you really need it, I found a dirty fix here : https://github.com/easydiffusion/easydiffusion/issues/1851 you can edit this file inside the container : /easy-diffusion/installer_files/env/lib/python3.8/site-packages/diffusers/utils/dynamic_modules_utils.py and remove cached_download from the import line.
-
@Yagami everything looks fine on my side. and effectiveley you just have to set the variable to 03 to select InvokeAI :
-
hello @Yagami I'll try to do a clean install to see if I have the same kind of error. @OddsodzAllMighty I'll take a look at it. BTW, for those interested I add Fluxgym to the container as option 71
-
I you want to try Flux on the last forge you may encounter this error : TypeError: 'NoneType' object is not iterable the solution is to uninstall xformers. The easiest way to do so is to : -remove xformers from the parameters.forge.txt file -clean venv and reinstall dependencies but deleting this file : "Delete_this_file_to_clean_virtual_env_and_dependencies_at_next_launch"
-
Sorry didn't had much time recently. On the latest version the bug preventing A1111 and to launch should be fixed. I also fixed the github workflow that didn't update the "latest" version.
-
When there is a high activity on the server (eg parity check/rebuild) I get a lot of those errors : Jul 22 13:16:26 hlf-data3 kernel: mpt2sas_cm1: log_info(0x31120100): originator(PL), code(0x12), sub_code(0x0100) Jul 22 13:16:26 hlf-data3 kernel: mpt2sas_cm1: log_info(0x31120100): originator(PL), code(0x12), sub_code(0x0100) Jul 22 13:16:26 hlf-data3 kernel: sd 10:0:1:0: device_block, handle(0x000a) Jul 22 13:16:28 hlf-data3 kernel: sd 10:0:1:0: device_unblock and setting to running, handle(0x000a) Jul 22 13:16:28 hlf-data3 kernel: sd 10:0:1:0: Power-on or device reset occurred sometimes it is preceded by read errors : Jul 22 13:06:30 hlf-data3 kernel: md: disk4 read error, sector=193241360 Jul 22 13:06:30 hlf-data3 kernel: md: disk4 read error, sector=193241368 Jul 22 13:06:30 hlf-data3 kernel: md: disk4 read error, sector=193241376 Jul 22 13:06:30 hlf-data3 kernel: md: disk4 read error, sector=193241384 Jul 22 13:06:30 hlf-data3 kernel: md: disk4 read error, sector=193241392 Jul 22 13:06:30 hlf-data3 kernel: md: disk4 read error, sector=193241400 Jul 22 13:06:30 hlf-data3 kernel: md: disk4 read error, sector=193241408 Jul 22 13:06:30 hlf-data3 kernel: md: disk4 read error, sector=193241416 Jul 22 13:06:30 hlf-data3 kernel: md: disk4 read error, sector=193241424 Jul 22 13:06:30 hlf-data3 kernel: md: disk4 read error, sector=193241432 Jul 22 13:06:30 hlf-data3 kernel: md: disk4 read error, sector=193241440 Jul 22 13:06:30 hlf-data3 kernel: md: disk4 read error, sector=193241448 Jul 22 13:06:30 hlf-data3 kernel: md: disk4 read error, sector=193241456 Jul 22 13:06:31 hlf-data3 kernel: sd 10:0:1:0: device_unblock and setting to running, handle(0x000a) Jul 22 13:06:31 hlf-data3 kernel: sd 10:0:1:0: Power-on or device reset occurred I checked drives, cables, and SAS cards. It doesn't looks like it's hardware related. after searching on the net I found that someone had the same behavior on debian12 and it was related to the mpt3sas driver version 43.100.00.00 : It's the exact same version unraid uses (even on the v7 beta). Is there a way to have a kernel with a different version to see it if resolves the issue ? (at least 47.00.00.00) thanks 😊 hlf-data3-diagnostics-20240722-1335.zip
-
@Araso In the latest version I made the change for SwarmUI. I use new folder names, at it will be considered as a new installation. you'll have to replicate to the changes you made when it was called Stable-swarm.
-
Thanks a lot, i'll make the changes this week-end.
-
can you try to delete the file named "Delete this file to reset access rights at next launch" to see if it fixes your issue ?
-
@wiloh95 leave the PUID and PGID by default. The webUI not launching is probably related to something else. Do you see errors in the log ?
-
@Zer0Nin3r I don't see any upscale folder in StableSwarm (If one was needed it should have been created). Can you be a litlle more specific about your issue ? thanks.
-
@River_Tahm do you have errors in the log that could help me understand what is going on ? @Zer0Nin3r i'll take a look as soon as possible
-
can you open a terminal in the container and type this command : nvidia-smi and then tell me if you have an error
-
I don't have this issue 🤔 Did you try to clear venv to see if it's enough to solve this problem ? (take into account that if you installed some python packages via the manager you'll have to reinstall them)
-
@anknv@Aer@rubicon@ippikiookami (and those I forgot 😅) I just pushed a new version that should fix issues with InvokeAI. They removed almost all parameters when launching the UI so the file "parameters.txt" is no longer used and will be renamed. Instead, a default config.yaml file will be placed in the "03-invokeai" folder, you can modify it to suit your preferences. I had a very short time to test, I hope I didn't leave too many bugs 🤞 Fixes I made for auto1111 path and Kohya are now also in the latest version.
-
Thanks a lot, i'll take a look at it
-
I think you should remove (after doing a backup) the /user/mnt/appdata/stable-diffusion/70-kohya/kohya_ss folder. I don't know what he says that you modified two files, but that's why it can't update.
-
I was referring to this part of the log : Remote branch is ahead. Wiping venv for clean packages install Updating 6162193..5bbb4fc ------------------------------------- Cleaning venv Done! ------------------------------------- In the last test version I force the update of local files, and I removed the systematic clean when there is an update. This time I hope it will be ok
-
ohhh ! That's why I thought it was ok 😵💫 A clean venv is launched every time there is an update of the repository. I will remove that and let only the "manual" cleaning.
-
@Araso in the last test version : -corrected a bug where the default output folder for auto111 wasn't linked to the common folder -corrected a bug where the virtual env for koyha was deleted at every launch -renamed the files used for clen env and reset rights (to get rid of spaces) hope this time everything is right
-
Thanks a lot for your feedback, i'll try to fix those two things as soon as possible. And you're rignt for the filenames, i'll change it too
-
@Araso If you want to try the test version, I think I fixed Koyha (not 100% sure since I don't use it) Perhaps you'll have to set up acceleration in the parameters (at least to tell which GPU to use) For your problem of permissions I did what you suggested. There is now two files at the root of the config folder : 'Delete this file to clean virtual env and dependencies at next launch' 'Delete this file to reset access rights at next launch' I think it's pretty clear, and please tell me if it solves your issue.
