1.4.0 Release Candidate 1

[Snoopy8]

This looks correct, but this works for me. I'm curious, are you using the domain name (aka fully qualified domain name FQDN) or the IP address of your NAS? I always used IP and that works. Can you confirm if you're using IP or FQDN? Also, what NAS are you using?

The fact that it works after and not during boot up means Snakeoil REST is starting too early before something is ready but right now it's hard to pin down what that service is.

Edit: I tried switching to FQDN and it still works.

Using Sydnology DS923 running latest DSM version. Using IP address. Was working with SO 1.3 Intel Ubuntu 22.04. NOT working with SO 1.3 Bookworm, SO 1.4 Ubuntu 24.01 (Intel NUC Element 11th Gen i7, Pi5).

[agent_kith]

Using Sydnology DS923 running latest DSM version. Using IP address. Was working with SO 1.3 Intel Ubuntu 22.04. NOT working with SO 1.3 Bookworm, SO 1.4 Ubuntu 24.01 (Intel NUC Element 11th Gen i7, Pi5).

Will have to search the Internet for this one. Worse come to worse if I cannot fix this in systemd, will just add something in code to address this.

[Primare11]

I looked for that since you stated "Add JRiver Media Center repo for auto install/uninstall" in the change log, but I can't find JRiver anywhere in the "Available Music Software (Expert)" or in the "Music Software" (after activation).

Arrgh, You are right, I forgot to add a few more tweaks to enable them! When it's working (RC-2 and beyond), you can install/uninstall 32 and 33 from Snakeoil->Software.

I also found some minor bugs:
- After installing the lowlatency kernel, it is not possible to activate it in the "Current Boot Kernel", you get an error saying "Linux Kernel Tweaks, grub.template is missing".

Whoops. Filing a ticket to fix that.

- In the "Mount Points Configuration" there is two mount types that say NFS (it is obvious which one is what since the "Mount Options" explanation below showing NFS or NTFS.

Double whoops. Also filing a ticket to address this.

Many thanks 

[Snoopy8]

Using Sydnology DS923 running latest DSM version. Using IP address. Was working with SO 1.3 Intel Ubuntu 22.04. NOT working with SO 1.3 Bookworm, SO 1.4 Ubuntu 24.01 (Intel NUC Element 11th Gen i7, Pi5).

Will have to search the Internet for this one. Worse come to worse if I cannot fix this in systemd, will just add something in code to address this.

Don't know whether this can help, for Intel NUC SO 1.4 RC1 ?
 

Code:

sudo systemd-analyze blame
[sudo] password for cs:
3.178s nmbd.service
707ms dev-mapper-ubuntu\x2d\x2dvg\x2dubuntu\x2d\x2dlv.device
594ms snapd.seeded.service
401ms apparmor.service
388ms systemd-resolved.service
333ms polkit.service
299ms e2scrub_reap.service
293ms snapd.service
246ms apport.service
229ms systemd-timesyncd.service
224ms systemd-networkd.service
216ms lighttpd.service
183ms systemd-binfmt.service
163ms systemd-logind.service
152ms proc-sys-fs-binfmt_misc.mount
151ms [email protected]
139ms rsyslog.service
120ms systemd-tmpfiles-setup-dev.service
111ms systemd-udev-trigger.service
111ms systemd-tmpfiles-setup.service
105ms grub-common.service
  96ms samba-ad-dc.service
  90ms dev-hugepages.mount
  89ms dev-mqueue.mount
  89ms sys-kernel-debug.mount
  87ms sys-kernel-tracing.mount
  87ms systemd-tmpfiles-setup-dev-early.service
  79ms keyboard-setup.service
  79ms kmod-static-nodes.service
  79ms lvm2-monitor.service
  78ms [email protected]
  77ms modprobe@dm_mod.service
  76ms ModemManager.service
  76ms [email protected]
  75ms modprobe@efi_pstore.service
  71ms [email protected]
  69ms systemd-udevd.service
  68ms run-rpc_pipefs.mount
  68ms smbd.service
  67ms ssh.service
  66ms [email protected]
  66ms systemd-journal-flush.service
  65ms systemd-journald.service
  65ms systemd-modules-load.service
  64ms systemd-sysctl.service
  62ms thermald.service
  54ms systemd-remount-fs.service
  52ms multipathd.service
  52ms sysstat.service
  48ms console-setup.service
  48ms rpc-statd-notify.service
  46ms finalrd.service
  43ms systemd-user-sessions.service
  42ms dbus.service
  31ms boot-efi.mount
  29ms grub-initrd-fallback.service
  27ms lxd-installer.socket
  26ms swap.img.swap
  26ms sys-fs-fuse-connections.mount
  25ms sys-kernel-config.mount
  24ms [email protected]
  23ms systemd-fsck@dev-disk-by\x2duuid-5cf4a3b8\x2d509e\x2d4141\x2da83f\x2de21>
  23ms plymouth-read-write.service
  22ms setvtrgb.service
  21ms systemd-fsck@dev-disk-by\x2duuid-7743\x2d1A83.service
  20ms systemd-update-utmp.service
  19ms systemd-random-seed.service
  19ms ufw.service
  16ms plymouth-quit.service
  16ms rpcbind.service
  13ms boot.mount
  11ms plymouth-quit-wait.service
   8ms snapd.apparmor.service
   5ms sysstat-collect.service
   3ms systemd-update-utmp-runlevel.service
   3ms avahi-daemon.service
   2ms snapd.socket
  17us blk-availability.service
lines 56-78/78 (END)

 

Code:

sudo systemd-analyze critical-chain
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.

└─multi-user.target @5.088s
  └─smbd.service @5.020s +68ms
    └─nmbd.service @1.819s +3.178s
      └─basic.target @1.807s
        └─sockets.target @1.807s
          └─snapd.socket @1.804s +2ms
            └─sysinit.target @1.776s
              └─systemd-resolved.service @1.388s +388ms
                └─systemd-tmpfiles-setup.service @1.262s +111ms
                  └─local-fs.target @1.185s
                    └─cpusets.mount @2.964s
                      └─local-fs-pre.target @775ms
                        └─systemd-tmpfiles-setup-dev.service @652ms +120ms
                          └─systemd-tmpfiles-setup-dev-early.service @539ms +87>
                            └─kmod-static-nodes.service @381ms +79ms
                              └─systemd-journald.socket @346ms
                                └─system.slice @264ms
                                  └─-.slice @264ms

[agent_kith]

Don't know whether this can help, for Intel NUC SO 1.4 RC1 ?

Not helping much. I have tweaked the service file to include nfs-client.target and nss-lookup.target in RC-2.

If RC-2 didn't work for you, edit the service file (/etc/systemd/system/snakeoil-rest.service) and change the word "After" to "Requires". Reboot and see if it works.

Your NUC is not using a USB network dongle by any chance? Even if it is USB it should be after network-online.target, so unsure what's happening.

FWIW I'm using TrueNAS and mount the volume via NFSv3 and it works for me both in arm64 and amd64 (I'm using Ubuntu server though)

[Snoopy8]

Your NUC is not using a USB network dongle by any chance? Even if it is USB it should be after network-online.target, so unsure what's happening.

Using built in NIC for both NUC and Pi5

FWIW I'm using TrueNAS and mount the volume via NFSv3 and it works for me both in arm64 and amd64 (I'm using Ubuntu server though)

On Synology DSM, NFS enabled from v2 to v4. On SO, folders mounted as NFSv4. I did try mounting option of NFSv3, but still required manual mounting after reboot.

Never had this problem with SO 1.3 (and earlier versions) on Ubuntu 22.04. What changed with SO 1.3 Pi5 Bookworm and SO 1.4 Ubuntu 24.01?

[agent_kith]

On Synology DSM, NFS enabled from v2 to v4. On SO, folders mounted as NFSv4. I did try mounting option of NFSv3, but still required manual mounting after reboot.

Never had this problem with SO 1.3 (and earlier versions) on Ubuntu 22.04. What changed with SO 1.3 Pi5 Bookworm and SO 1.4 Ubuntu 24.01?

The problem should be Linux itself (i.e. Ubuntu). However I can't recreate this problem as I am using TrueNAS here. In RC-2, snakeoil-rest server should start after nfs-client target now, and that in theory should fix things. But if not I will have to add some hacks in Snakeoil to work around this.. Will see how it goes..