Why I chose an N100 over a Raspberry PI5

    If all you want is a home media NAS with no frills like ZFS, redundancy, etc., the RPI 5 is the lower power option, thus better IMO. Of course here, a RPI 4 is probably even better.


    I have a RPI 4 I've been running for ~4 years as a GIT mirror and it has been rock solid. Prior to that I used a RPI 3 and rsync to backup a GIT, which was also solid. That said, I don't yet own a N100 but, I have 3 different small Chinese N100 boxes in the mail from Ali :-). Which ever of the 3 I like best will become my new default Klipper machine (3D printer firmware) and 1 of these N100's should comfortably replace 2 RPI's, this will be very nice for me.


    The increasing flood of these N100 boards has put the RPI 5 into a position where the RPI 5 has become completely irrelevant for me, for when would I buy a RPI 5 instead of a N100 or a ESP32/Pico W/etc.?

    I am running the same mainboard and installed the Proxmox Kernel as you had suggested. Now after booting into the Kernel most of my docker containers do not start.

    What could be the issue here?


    Looks like some kind of permission issue when looking at my portainer log e.g.


    Code
    2024/02/15 01:54PM FTL github.com/portainer/portainer/api/cmd/portainer/main.go:558 > failed starting tunnel server | error="listen tcp 0.0.0.0:8000: socket: permission denied"
2024/02/15 01:55PM INF github.com/portainer/portainer/api/cmd/portainer/main.go:369 > encryption key file not present | filename=portainer
2024/02/15 01:55PM INF github.com/portainer/portainer/api/cmd/portainer/main.go:392 > proceeding without encryption key |
2024/02/15 01:55PM INF github.com/portainer/portainer/api/database/boltdb/db.go:125 > loading PortainerDB | filename=portainer.db
2024/02/15 01:55PM INF github.com/portainer/portainer/api/chisel/service.go:198 > Found Chisel private key file on disk | private-key=/data/chisel/private-key.pem
2024/02/15 13:55:18 server: Reverse tunnelling enabled
2024/02/15 13:55:18 server: Fingerprint jZHMM4IM+yMWam+Af2p6P45FAOuF6hM7uoXih0AvG2E=
2024/02/15 01:55PM FTL github.com/portainer/portainer/api/cmd/portainer/main.go:558 > failed starting tunnel server | error="listen tcp 0.0.0.0:8000: socket: permission denied"
    • Official Post
    Quote from monsen

    I am running the same mainboard and installed the Proxmox Kernel as you had suggested. Now after booting into the Kernel most of my docker containers do not start.

    What could be the issue here?

    I think installing a proxmox kernel shouldn't affect docker or running containers at all, but maybe I'm wrong. ryecoaaron might have a different opinion on this.


    Maybe something to do with the changes you made to the disk configuration here. RE: Change of MB without reinstall possible?

    • Official Post
    Quote from monsen

    I just rebooted to the "old" 6.1.0-0.deb11.13-amd64 Kernel and here the dockers work without problem.

    In that case there is something I am missing.

    • Official Post

    I run the proxmox kernel on all of my systems and have never had a problem with docker but I don't use portainer. So, I can't say why portainer doesn't start which means your other containers won't start (I think). Removing the portainer layer would increase reliability in my opinion.

    omv 7.4.8-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.14 | compose 7.2.5 | k8s 7.3.1-1 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.0.9


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    Thanks 1
    Quote from ryecoaaron

    I run the proxmox kernel on all of my systems and have never had a problem with docker but I don't use portainer. So, I can't say why portainer doesn't start which means your other containers won't start (I think). Removing the portainer layer would increase reliability in my opinion.

    I have already migrated all containers to OMV. They are all OMV "native" with YML files.

    I just left portainer because some things are more comfortable in there (e.g. checking live logs). It is not used for configuration.


    So removing portainer would not change anything.


    Here you can see all containers are running as the should in OMV (the ones that are down, are currently not in use and therfore stopped):


    • Official Post

    I can't explain why they aren't starting then. You would need to look at the docker logs I guess. Maybe your storage isn't ready and docker is starting too soon? The plugin tries to create an override for docker to wait for all of the storage that the code can find. Just guessing though.

    omv 7.4.8-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.14 | compose 7.2.5 | k8s 7.3.1-1 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.0.9


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    I see some weird messages in the boot.log:


    Quote from ryecoaaron

    I can't explain why they aren't starting then. You would need to look at the docker logs I guess. Maybe your storage isn't ready and docker is starting too soon? The plugin tries to create an override for docker to wait for all of the storage that the code can find. Just guessing though.

    I dont think so, because i can also not start them manually after boot.

    Here is e.g. what nextcloud tells me:


    Code
    nextcloud  | s6-ipcserver-socketbinder: fatal: unable to create socket: Permission denied
nextcloud  | s6-ipcserver-socketbinder: fatal: unable to create socket: Permission denied
nextcloud  | s6-ipcserver-socketbinder: fatal: unable to create socket: Permission denied
nextcloud  | s6-ipcserver-socketbinder: fatal: unable to create socket: Permission denied
nextcloud  | s6-ipcserver-socketbinder: fatal: unable to create socket: Permission denied
nextcloud  | s6-ipcserver-socketbinder: fatal: unable to create socket: Permission denied
    • Official Post

    Are you running VMs? The tor service isn't helping especially if your docker traffic uses it.


    The nextcloud output just tells you why the container isn't starting. Doesn't really tell you why docker is having problems.


    Quote from monsen

    I dont think so, because i can also not start them manually after boot.

    If the docker service is having problems with storage (especially if your docker storage is on a usb drive or something mounting slow), then your containers won't start. I assume the containers will start if you restart docker itself?


    Are there any apparmor errors in dmesg?

    omv 7.4.8-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.14 | compose 7.2.5 | k8s 7.3.1-1 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.0.9


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    The tor service must be some old leftover. I just got rid of it. I am not using it.


    Not sure if storage is an issue. The system disk and appdata folders are on an SSD. So there should be no issue.

    Some linked data though (like media files) are on HDD that is connected via an M.2 to SATA device. That could be slow. But i dont think that should prevent the dockers from starting as only some media files and similar are mounted into the dockers.


    Actually i did see some apparmor log messages:



    Also i see there some mentioning of eth0. I have just migrated to a new mainboard and there is no eth0 anymore on this system. Network interface now is enp2s0

    • Official Post

    This looks like apparmor is causing the problem. I would uninstall apparmor or disable it in grub.

    omv 7.4.8-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.14 | compose 7.2.5 | k8s 7.3.1-1 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.0.9


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Official Post
    Quote from ryecoaaron

    This looks like apparmor is causing the problem. I would uninstall apparmor or disable it in grub.

    Yes, that seems to be the problem.

    My question for you is: Why did apparmor not cause problems with the previous kernel but it does with this kernel? I don't see the relationship. From what it seems, apparmor was already installed on that system and did not cause problems with the old kernel.

    That is exactly what i thought chente

    And I have absolutely no answer for you.


    But i can confirm that everything is working fine now after turning off apparmor.


    Maybe this has something to do with UEFI boot and some security stuff being launched by it in conjunction with apparmor?

    • Official Post

    When you install a proxmox kernel, the boot configuration is modified to use the new kernel. Maybe there is the answer.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login