Closed chfoo closed 1 month ago
Any chance we could include https://github.com/ArchiveTeam/Ubuntu-Warrior/issues/21 in the mix? Whether as to help fix https://github.com/ArchiveTeam/Ubuntu-Warrior/issues/22 or just as a general enhancement for those using VMware based systems?
The PR at https://github.com/ArchiveTeam/Ubuntu-Warrior/pull/23 may be reuseable, but it looks like there's some big-ish differences in how images are built in this version :)
https://github.com/ArchiveTeam/Ubuntu-Warrior/issues/5 is still seemingly relevant too...
Importing directly into esxi doesn't work
Will have a play and see if the workarounds for the older version still work on the newer...
Any chance we could include ArchiveTeam/Ubuntu-Warrior#21 in the mix? Whether as to help fix ArchiveTeam/Ubuntu-Warrior#22 or just as a general enhancement for those using VMware based systems?
Adding open-vm-tools should be doable. I will add them soon.
For the unexpected shutdowns, the logic in version 3 appears to be incorrect and powers off the VM when it shouldn't. This new version properly queries the Docker container's health value and the seesaw-kit's reboot/shutdown requests.
ArchiveTeam/Ubuntu-Warrior#5 is still seemingly relevant too...
Importing directly into esxi doesn't work
Will have a play and see if the workarounds for the older version still work on the newer...
Trying it on my ARM based mac into Fusion...
Will try it on an intel device incase it's something related to that
Will try it on an intel device incase it's something related to that
Exactly same error.
Seems that OVF 2.0 doesn't work well (from a google)?
f16a3b8db53c92e80f722d007118549a715c9b25
If I grab an older release (archiveteam-warrior-v4.0-alpha.1-20230524-170225.ova), it behaves the same way in https://github.com/ArchiveTeam/Ubuntu-Warrior/issues/5
It then complains about it being not being an arm guest, which is understandable
Maybe it would be simpler to provide VMDK disk images as well and instructions on how to set up port forwarding.
More than happy to help with testing/documentation :)
A VMDK disk image is uploaded now. (It's compressed to a zip file so don't forget to unzip first.)
Thanks!
Seems ESXi doesn't like the disk as is...
https://kb.vmware.com/s/article/1028943
vmkfstools -i archiveteam-warrior-v4.0-beta.2-20230608-042837.vmdk archiveteam-warrior-v4.0-beta.2-20230608-042837-esxi.vmdk
seems to work, if you then use that instead of the downloaded file.
Might be worth adding that to the docs (related to my request in https://github.com/ArchiveTeam/warrior4-vm/issues/2)
This is probably a request for a different project... I don't know where that GUI comes from. But it would be nice if it just didn't say to connect on localhost :)
eth0
from ip addr show
does give me the info I want (on the console).
Happy to file a request in the correct repo if you can point me in the right direction
I was going to say, it seems even with open-vm-tools installed, it isn't showing the networking info in the ESXi ui.
But after the machine has been up a few minutes, that's showing (I think that usually what happens with other new images anyway)... Yay, thanks!
Swapped over to using this (for now) rather than the older 3.2 image :)
You might want to mark some of the issues in the description as done, as they now are done
Thank you for testing!
This is probably a request for a different project... I don't know where that GUI comes from. But it would be nice if it just didn't say to connect on localhost :)
It is from this project. The message is just copied from version 3 which just assumes port forwarding is being used. I don't think we figured out how to automatically detect which VM network is being used yet.
Forked the IP display request into #5
https://github.com/ArchiveTeam/Ubuntu-Warrior/issues/22 definitely seems to be fixed.
Just logged into my "new" warrior, and noticed the upload/download figures were < 10GB each (but were well over 100).
Looks like it rebooted ~10 hours ago...
Not sure where this report wants to go..
2023-06-28 15:58:17,596 - seesaw.warrior - DEBUG - git operation: hint: Pulling without specifying how to reconcile divergent branches is
hint: discouraged. You can squelch this message by running one of the following
hint: commands sometime before your next pull:
hint:
hint: git config pull.rebase false # merge (the default strategy)
hint: git config pull.rebase true # rebase
hint: git config pull.ff only # fast-forward only
hint:
hint: You can replace "git config" with "git config --global" to set a default
hint: preference for all repositories. You can also pass --rebase, --no-rebase,
hint: or --ff-only on the command line to override the configured default per
hint: invocation.
Already up to date.
2023-06-28 15:58:17,598 - seesaw.warrior - DEBUG - Install complete hint: Pulling without specifying how to reconcile divergent branches is
hint: discouraged. You can squelch this message by running one of the following
hint: commands sometime before your next pull:
hint:
hint: git config pull.rebase false # merge (the default strategy)
hint: git config pull.rebase true # rebase
hint: git config pull.ff only # fast-forward only
hint:
hint: You can replace "git config" with "git config --global" to set a default
hint: preference for all repositories. You can also pass --rebase, --no-rebase,
hint: or --ff-only on the command line to override the configured default per
hint: invocation.
Already up to date.
ArchiveTeam/Ubuntu-Warrior#22 definitely seems to be fixed.
Just logged into my "new" warrior, and noticed the upload/download figures were < 10GB each (but were well over 100).
Looks like it rebooted ~10 hours ago...
Thanks for testing, it looks like reboot requests for seesaw-kit is working.
Just rebuilt mine with the new archiveteam-warrior-v4.0-20230722
image in a few minutes. All seems good! :)
This is issue is for tracking past issues for first stable release of version 4.
Issues from version 3 that are being addressed: