New answers tagged

0

It seems that the cause is the permission setup of the /tmp directory! Resetting the access mode helped: chmod 1777 /tmp


0

I resolved that situation on TrueNAS SCALE and OpenMediaVault, which both build on Debian by removing every file md* inside ls -R /usr/share/initramfs-tools/*|grep ^md and update the init update-initramfs -u and now no more time waiting for mdadm which randomly mount raid's ps: I also took the time to remove every file which was pointed at btrfs, dm, lvm, ...


2

Systemd come with systemd-fsck, it can be enabled to check the FS at boot: sudo systemctl enable systemd-fsck-root.service or sudo systemctl enable systemd-fsck@.service See man systemd-fsck


2

You can set the individual ext* file systems to require an fsck on every mount using tune2fs -c 1 /dev/sda1 # replace with each device name fsck.xfs is a no-op. It just returns true. No fsck.zfs exists. I haven't checked for other file system types. No systemd service is required.


2

Create the file /etc/systemd/system/MyFsckScript.service (feel free to replace "MyFsckScript", don't change the rest) with the following content: [Unit] Description=Filesytem check Documentation=man:fsck(8) Before=local-fs.target [Service] ExecStart=/sbin/fsck REPLACETHISBYYOURDRIVE [Install] Alias=fsck.service Now run: systemctl enable fsck and ...


0

To run a command on startup via crontab, you should use @reboot string: see info crontab string meaning ------ ------- @reboot Run once, at startup.


4

The impact of your startup scripts and the resulting setup will mostly affect interactive shells; to determine the resulting resource consumption, you don’t need to go to huge lengths. Open a terminal window, so that your default shell starts with its default setup, then start a shell without loading the startup scripts, and from that shell, run ps -F: $ ...


0

If you are using systemd, you can do this by running (as root or with sudo): systemctl enable rfkill-unblock@all


Top 50 recent answers are included