It would be because cron runs as the root user.

Castget probably looks at the file path $HOME/.castgetrc. For your regular user, $HOME is probably /home/myamazingusername. For the root user, $HOME is probably /root .

You can get a root terminal session by running sudo -i in a terminal console window. You can try running castget there to see what happens.

Sudo -n:

-n, --non-interactive
  Avoid prompting the user for input of any kind.  If a
  password is required for the command to run, sudo, will
  display an error message and exit.

It’s just a nice thing to put in non-interactive scripts that use sudo. Sometimes you can end up with scripts that just wait endlessly for a password that will never be input because the script is being run non-interactively. The flag probably isn’t needed for a cron job, because root probably can sudo as any user without a password, but it doesn’t hurt either.

EDIT: I didn’t know that there are user crontab entries as well. If you just used crontab -e without using sudo, then you don’t need to worry about the job being run as root.

In line with the advice that running as root would likely not run with the correct file permissions (and would not read the correct config files), you probably want to run castget as your desktop user. Something like sudo -u mydesktopuser -n -- castget -c

Four contrarians walk into a bar. The first one says “ouch, I stubbed my toe on a chair”. The second one says “there is no actual bar, because this is a joke”, the third one says “no it is real, I’ll have one real beer, please”. The fourth one walks away.

But more seriously: yikes.

I see. I suspect that the Ultra Series 1 model is being treated as a previous-generation product and won’t get restocked, but I could be wrong. I think if you really want, you can make an Ultra Series 1 laptop from parts. They have the chassis and the two higher end Ultra Series 1 mainboards in stock. Though at the price you might prefer to just pre-order the 13 pro.

🫢

Maybe I don’t understand, but I see it in stock and I was able to add it to my cart. Are you outside the US?

The first thing is to do is to understand what you’re looking at. Read this:

systemd-analyze blame¶

This command prints a list of all running units, ordered by the time they took to initialize. This information may be used to optimize boot-up times. Note that the output might be misleading as the initialization of one service might be slow simply because it waits for the initialization of another service to complete. Also note: systemd-analyze blame does not display results for services with Type=simple, because systemd considers such services to be started immediately, hence no measurement of the initialization delays can be done. Also note that this command only shows the time units took for starting up, it does not show how long unit jobs spent in the execution queue. In particular it shows the time units spent in “activating” state, which is not defined for units such as device units that transition directly from “inactive” to “active”. This command hence gives an impression of the performance of program code, but cannot accurately reflect latency introduced by waiting for hardware and similar events.

For example: I have passphrase disk encryption (no TPM encryption), and the time I take to enter the passphrase is added to many entries in systemd-analyze blame. Here is the output of systemd-analyze blame if I wait 2 minutes to enter my disk encryption passphrase:

2min 12.640s sys-module-fuse.device
2min 12.618s sys-devices-platform-MSFT0101:00-tpm-tpm0.device
2min 12.618s dev-tpm0.device
2min 12.551s dev-ttyS0.device
2min 12.551s sys-devices-pnp0-00:00-00:00:0-00:00:0.0-tty-ttyS0.device
2min 12.550s dev-ttyS2.device
...

So, I guess my advice is that systemd-analyze blame is not always going to be a clear indicator that a particular service is holding your boot times back. The .device entries in particular probably just represent how long after boot that the device became active. And unfortunately the systemd-analyze tools do not always lead you to the underlying delay.

$ systemd-analyze critical-chain dev-tpm0.device
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

dev-tpm0.device +2min 12.618s

$ systemd-analyze critical-chain dracut-initqueue.service
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

dracut-initqueue.service +2min 11.123s
└─systemd-udev-trigger.service @770ms +158ms
  └─systemd-udevd-varlink.socket @760ms +65us
    └─system.slice
      └─-.slice

If you are trying to deal with an issue that is causing significant delays in your boot time, journalctl --boot can sometimes be helpful. For the example boot above where I waited 2 minutes before entering the disk encryption passphrase:

Jul 31 14:09:39 mycomputer kernel: Linux version 7.1.5-201.fc44.x86_64 (mockbuild@9b86e96a386140128351588d751166fd) (gcc (GCC) 16.1.1 20260515 (Red Hat 16.1.1-2), GNU ld versi>
... (a lot of log lines within a few seconds, but then I find a big jump) ...
Jul 31 14:09:44 mycomputer kernel: [drm] pre_validate_dsc:1667 MST_DSC dsc precompute is not needed
Jul 31 14:11:48 mycomputer systemd-cryptsetup[551]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/...
... (and then there are a lot of log lines in the following seconds after the above line) ...