Jerry Vonau
Jerry Vonau
Given this was tagged for 8.0 in 2020 why the sudden interest in networking a year later when this is a 8.0 objective?
there years later, is it good enough?
Close https://github.com/learningequality/kolibri/issues/9455#issuecomment-1136062000
connection the the source page 
is this still relevant? seems like an upstream bug
Further history #723
TimeoutSec=0 would be a good addition for the revised unit file.
https://linuxconfig.org/how-to-force-fsck-to-check-filesystem-after-system-reboot-on-linux `sudo tune2fs -c 1 /dev/mmcblk0p2` triggers to always fsck on boot for debugging ``` jerry@NM-64-desktop-RasPiOS:~ $ sudo systemctl status systemd-fsck-root.service * systemd-fsck-root.service - File System Check on Root Device...
> ``` > Active: failed (Result: exit-code) since Mon 2022-09-19 16:29:24 CDT; 20min ago > Main PID: 254 (code=exited, status=1/FAILURE) > ``` > > @jvonau the failure of `iiab-expand-rootfs.service` above...
Methodology: jvonau@kickass:/mnt/scratch/git/iiab$ `sudo nano /media/jvonau/rootfs/etc/systemd/system/iiab-expand-rootfs.service` alter to match PR [sudo] password for jvonau: jvonau@kickass:/mnt/scratch/git/iiab$ `sudo nano /media/jvonau/rootfs/usr/sbin/iiab-expand-rootfs` alter add echo jvonau@kickass:/mnt/scratch/git/iiab$ `sudo chroot /media/jvonau/rootfs` root@kickass:/# `systemctl disable iiab-expand-rootfs` Removed /etc/systemd/system/multi-user.target.wants/iiab-expand-rootfs.service....