mag37

joined 2 years ago
[–] mag37@lemmy.ml 3 points 1 month ago* (last edited 1 month ago) (1 children)

Oh havnt heard of this before now. Is there any chance of it being broadcasted digitally too?

[–] mag37@lemmy.ml 17 points 1 month ago* (last edited 1 month ago)

Dumb comic?

Edit: dumb comic\r\n

[–] mag37@lemmy.ml 2 points 4 months ago* (last edited 4 months ago) (1 children)

Nice!

I've never really ran any of the immutable/atomic distros for daily driver so can't give you tips from experience. But this seemed sensible (but a bit in depth, maybe just take parts of it). https://lurkerlabs.com/fedora-silverblue-ultimate-post-install-guide/

And if you're looking at atomic/immutable, also check out Bluefin, Aurora and Bazzite (based on Fedora).

Good luck!

[–] mag37@lemmy.ml 2 points 4 months ago (3 children)

Glad the boot option worked, hope it'll work out with the drivers installed.

[–] mag37@lemmy.ml 4 points 4 months ago (5 children)

And if you have not yet installed RPM-fusion and Nvidia drivers properly - you could take a look at the Graphics section on this writeup: https://github.com/wz790/Fedora-Noble-Setup

[–] mag37@lemmy.ml 3 points 4 months ago* (last edited 4 months ago) (7 children)

Can you edit the kernel parameters in Grub (by pressing E on the Fedora alternative) and try adding nomodeset or nvidia_drm.modeset=0 at the end of the line starting with linux /boot/vmlinuz or similar. Then CTRL+X to start with the new (temporary) parameters.

If that boots (and if you've installed the Nvidia drivers etc) - try forcing a rebuild of kmods and wait 5-10 minutes before restarting.
sudo akmods --force --rebuild
You can see if it's don't by running sudo journalctl -f -u akmods

Maybe you have to remove the kmod prior, can't recall:
dnf remove kmod-nvidia-$(uname -r)

[–] mag37@lemmy.ml 11 points 5 months ago

So true 😂 Both at work and private side projects 👏

[–] mag37@lemmy.ml 1 points 5 months ago

Oh that's very kind of you! There's an AUR package and a brew already, don't know if other packages is necessary tbh :)

Though some people have suggested they'd like a docker container - which I should try to spend some time on in the future.

[–] mag37@lemmy.ml 2 points 5 months ago (2 children)

Oh nice, yeah I havn't thought about suggesting a systemd-service thats neat! If you'd like you could contribute it as a discussion/suggestion/PR if you land on liking it, thatd be lovely.

With the image backups in the next release you could maybe even build some kind of auto rollback functionality.

[–] mag37@lemmy.ml 3 points 5 months ago

Sadly no, only within the scope of the tag specified in the compose.

Renovate, WUD or Diun might be other options for that!

[–] mag37@lemmy.ml 3 points 5 months ago

Thank you. I hope you can find some usefulness in it. You can also do things by compose labels. As well as dynamically at runtime. Either interactively or as arguments.

[–] mag37@lemmy.ml 21 points 5 months ago* (last edited 5 months ago) (3 children)

This question is usually asked a lot.

This started as a project to prove that you could check for updates without first pulling every new image to compare against, while that's not why it kept get getting traction my original answer to this question still seems true:

From Watchtower Docs - Arguments

Due to Docker API limitations the latest image will still be pulled from the registry.

And:

Do not pull new images. When this flag is specified, watchtower will not attempt to pull new images from the registry. Instead it will only monitor the local image cache for changes

It's also a different approach. With dockcheck you'd run it and then make the choice what you'll update there and then. Selectively choosing exactly what containers to update at the moment. Or have it completely unattended auto update a selection of images.

With the notifications, you can get notified and then have a sitdown and auto-update what you choose.

It's just different workflows and options.

The upcoming release will also add a new option to backup the image being updated and then autoprune old backups after N days. To allow for easy rollback if a new image breaks.

 

I just has the honors of writing a guest article on selfh.st about my ever so slowly evolving project, dockcheck.

 

Another few months have passed and thanks to a of user contributions and suggestions a bunch of changes got implemented, big and small.
The two latest changes have been pretty large:

  • Complete rewrite of notification logics
    • Configuration is set through the dockcheck.config
    • Templates used "untouched"
    • Possibility to trigger multiple notification templates through "channels"
  • Restructure the update process
    • First pulls all (selected) images
    • Then recreate all containers that received updates - to avoid unnecessary restarts and strain

https://github.com/mag37/dockcheck

Plenty more changes have been implemented since I posted last, such as:

  • Added a config-file to set user options (same as passing option flags).
  • Added option -u for unattended dockcheck self update (caution!).
  • Added option -I to print urls from url.list to list of containers with updates.
  • Cleaned up and refactored a lot of code;
    • Safer variables and pipefail options.
    • Consistent colorization of messages.
    • Monochrome mode hides progress bar.
    • Exits if pull or recreation of container fails.
  • Cleared up some readme with extra info;
    • Synology DSM
    • Prometheus + node_exporter
    • Zabbix config
    • Rest API script
    • Unraid wrapper script
  • Permission checks;
    • Graceful exit if no docker permissions.
    • pkg-manager installs handles sudo/doas/root properly.
  • Notify-templates; added slack, added markdown support to some templates.

I'm very happy to have a supportive and contributing user base who helps with troubleshooting, suggesting changes and contributing code. Thank you!

view more: next ›