Windows will not boot with this method. By renaming the file back to bootmgfw.efi windows will boot again but now linux won’t boot. There is no clean solution, other than switch to different computer that doesn’t have this issue. Because of issues like this I don’t recommend dual booting. Installing only Windows or only Linux is more manageable for not-tech-savvy people.
In windows EFI partition, there will be an EFI/Microsoft/bootmgfw.efi file, I usually rename it to bootmgfw.efi.bak and that allows grub to load.
I have observed that many laptops are hard-coded to boot windows whenever possible. Even with windows bootentry missing, firmware will skip Grub set to first priority and start windows. Only way to make them start Grub is to rename bootmgfw.efi to a different name.
For me the value of podman is how easily it works without root. Just install and run, no need for sudo or adding myself to docker group.
I use it for testing and dev work, not for running any services.
Technically, containers always run in Linux. (Even on windows/OS X; on those platforms docker runs a lightweight Linux VM that then runs your containers.)
And I wasn’t even using Docker.
How I lost a Postgres database:
Just did some basic testing on broadcast addresses using socat, broadcast is not working at all with /32 addresses. With /24 addresses, broadcast only reaches nodes that share a subnet. Nodes that don’t share the subnet aren’t reachable by broadcast even when they’re reachable via unicast.
Edit1: Did more testing, it seems like broadcast traffic ignores routing tables.
On 192.168.0.2, I am running socat -u udp-recv:8000,reuseaddr - to print UDP messages.
Case 1: add 192.168.0.1/24
# ip addr add 192.168.0.1/24 dev eth0
# # Testing unicast
# socat - udp-sendto:192.168.0.2:8000 <<< "Message"
# # Worked
# socat - udp-sendto:192.168.0.255:8000,broadcast <<< "Message"
# # Worked
Case 2: Same as above but delete 192.168.0.0/24 route
# ip addr add 192.168.0.1/24 dev eth0
# ip route del 192.168.0.0/24 dev eth0
# # Testing unicast
# socat - udp-sendto:192.168.0.2:8000 <<< "Message"
2024/02/13 22:00:23 socat[90844] E sendto(5, 0x5d3cdaa2b000, 8, 0, AF=2 192.168.0.2:8000, 16): Network is unreachable
# # Testing broadcast
# socat - udp-sendto:192.168.0.255:8000,broadcast <<< "Message"
# # Worked
Here is a trick that has been tried and tested over the years: Install another distro, and use that to install Arch. This way, you can rely on an already working linux distro till your Arch install works the way you want.
Hmm… Maybe I should adjust my priorities.
I was confused for a moment, because intuitively a CPU fan would look in the same direction as it blows air, so it should look into the heatsink. The fan looking away from the heatsink seems weird to me.
Or the owner installed the fan in the wrong direction.
1 a : to propel oneself in water by natural means (such as movements of the limbs, fins, or tail) b : to play in the water (as at a beach or swimming pool) 2 : to move with a motion like that of swimming : glide a cloud swam slowly across the moon 3 a : to float on a liquid : not sink b : to surmount difficulties : not go under sink or swim, live or die, survive or perish— Daniel Webster 4 : to become immersed in or flooded with or as if with a liquid potatoes swimming in gravy 5 : to have a floating or reeling appearance or sensation
https://www.merriam-webster.com/dictionary/swim
Apparently, swimming inherently requires a liquid.
TPM stores the encryption key against secure boot. That way, if attacker disables/alters secure boot then TPM won’t unseal the key. I use clevis to decrypt the drive.
Thank you… I had to learn kubernetes for work and it was around 2 weeks of time investment and then I figured out I could use it to fix my docker-compose pains at home.
If you run a lot of services, I can attest that kubernetes is definitely not overkill, it is a good tool for managing complexity. I have 8 services on a single-node kubernetes and I like how I can manage configuration for each service independent of each other and also the underlying infrastructure.
don’t create one network with Gitlab, Redmine and OpenLDAP - do two, one with Gitlab and OpenLDAP, and one with Redmine and OpenLDAP.
This was the setup I had, but now I am already using kubernetes with no intention to switch back.
I was writing my own compose files, but see my response to a sibling comment for the issue I had.
If one service needs to connect to another service then I have to add a shared network between them. In that case, the services essentially shared a common namespace regarding DNS. DNS resolution would routinely leak from one service to another and cause outages, e.g if I connect Gitlab container and Redmine container with OpenLDAP container then sometimes Redmine’s nginx container would access Gitlab container instead of Redmine container and Gitlab container would access Redmine’s DB instead of its own DB.
I maintained some workarounds, like starting Gitlab after starting Redmine would work fine but starting them other way round would have this issue. But switching to Kubernetes and replacing the cross-service connections with network policies solved the issue for me.
As someone who is operating kubernetes for 2 years in my home server, using containers is much more maintainable compared to installing everything directly on the server.
I tried using docker-compose first to manage my services. It works well for 2-3 services, but as the number of services grew they started to interfere with each other, at that point I switched to kubernetes.
All these are just silly stereotypes that almost nobody fits into.
Never tried that, though a quick search got me this: https://superuser.com/questions/1471937/how-can-i-add-a-bcd-boot-entry-for-linux-in-windows-boot-manager-in-efi