res2001

node.js сама умеет в веб-сервер.
На линуксе по умолчанию никаких веб серверов не установлено. Все ставится отдельно.

apt update - просто обновляет список доступных в подключенных репозитариях пакетов.
Без этого обновления пакетный менеджер не знает какие пакеты устарели и требуют обновления, а так же не знает о новых добавленных пакетах.
Перед установкой нового пакета лучше всего выполнить apt update, но можно и не выполнять, ничего особо страшного не будет.
Вообще есть смысл регулярно выполнять sudo apt update & sudo apt upgrade - это приведет к обновлению всех требующих обновления пакетов.

Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend

Сюдя по всему у вас где-то в другом окне параллельно идет обновление или установка. Когда вы запускаете apt и/или графическую утилиту обновления, то они блокируют базу данных установленных пакетов и параллельный запуск может приводить к подобным ошибкам. Просто дождитесь, когда все установки закончатся.

Набросаю схематично вариант без forfiles.
Имеем текстовый файл file.txt со списком имен файлов, которые не надо удалять - одно имя файла на каждой строке.
Получить список всех файлов в каталоге можно с помощью dir /b
Далее этот список отфильтровать, исключая файлы, содержащиеся в file.txt, примерно так:
dir /b c:\test\* | findstr /v /g:file.txt
На выходе по идее должен быть список файлов, которые надо удалить.
Эту команду запихнуть в

for /f "tokens=* delims=" %%a in ('dir ... ^| findstr ...') do (del %%a)

В принципе все.
Проверить все сейчас не могу, т.к. под рукой нет винды, поэтому только общая идея, компоновать придется самому.
За подробностями:

dir /?
for /?
findstr /?
del /?

Рекомендую сначала выполнить связку dir | findstr вручную в консоли и добиться, что бы выдавался нужный результат (список файлов для удаления), только затем все это оформлять в батник.

У меня был некоторый опыт с uboot, правда для другой ОС

Если у вас какая-то стандартная покупная плата, то возможно в uboot уже есть готовый config. Обычно производители плат в документации указывают как собрать uboot под их плату (если они поддерживают uboot), либо это можно нагуглить в интернете.
Если же плата самодельная, то берете самый близкий для вашей платы config (вы же брали за основу какой-то референс дизайн платы, вот эту плату и берите за основу), переименовываете его и вносите в него соответствующие изменения.
Бывает, что вместе с config'ом требуется вносить изменения и в dts, они в uboot лежат в ./arch/<platform name>/dts. Название используемых dts лежит в переменной CONFIG_DEFAULT_DEVICE_TREE и/или в CONFIG_OF_LIST в config файле.

Config файл - это просто набор параметров, которые превращаются в набор инструкций #define при сборке.
С dts все сложнее. Там целый язык описания железа.

Для сборки uboot рекомендую следующую последовательность:
1. Заведите для сборки отдельный пустой каталог. Он будет текущим каталогом для всех дальнейших команд
2. Пусть каталог где лежит сам uboot хранится в переменной UBOOT_DIR. Архитектура процессора вашей платы (например arm) в переменной ARCH. Префикс для кросскомпилятора в CROSS (например arm-linux-gnueabihf-). Имя выбранного defconfig файла в переменной DEFCONFIG (имя указываете вместе с суффиксом _defconfig)
3. Очистка каталога сборки:

make -C $UBOOT_DIR ARCH=$ARCH CROSS_COMPILE=$CROSS distclean

Эта команда пригодится при пересборках в случае изменения конфигурации
4. Подготовка конфигурации для сборки:

make -C $UBOOT_DIR ARCH=$ARCH CROSS_COMPILE=$CROSS $DEFCONFIG

5. Сборка: make -C $UBOOT_DIR ARCH=$ARCH CROSS_COMPILE=$CROSS

Несколько полезняшек:
1. Вы можете задавать дополнительную опцию для make: -O <путь>
Она задает каталог, в котором будет происходить сборка. Этот каталог make создаст сама. Это бывает удобно, если работаете сразу с несколькими конфигами.
2. В uboot встроен конфигуратор конфигов :) Конфигурация происходит в текстовом режиме с помощью меню, присутствуют подсказки для опций и т.п. Когда вы создали начальную конфигурацию в п.4 выдайте команду:

make -C $UBOOT_DIR ARCH=$ARCH CROSS_COMPILE=$CROSS menuconfig

Тут то же можно добавлять опцию -O для выбора каталога с конфигурацией. После исправления конфигурации, не забудьте ее сохранить.
Дальше нужно дать команду:

make -C $UBOOT_DIR ARCH=$ARCH CROSS_COMPILE=$CROSS savedefconfig

Она создаст на основе текущей конфигурации defconfig файл в каталоге сборки. Этот файл можно переименовать в <имя платы>_defconfig и подложить в каталог с конфигами uboot и в дальнейшем использоавть его для сборки.
3. В каталоге с uboot дайте комаду make help для получения списка возможных опций.
4. Обычно я собираю uboot под линукс, но та же схема вполне работает и в WSL под виндой. Набор кросс-компиляторов есть в портах (в WSL исопльзовал дистрибутив ubuntu).

Желаю удачи!

Вся маршрутизация зашита в логику работы стека TCP/IP. Управляется таблицей маршрутизации. За доступ в интернет отвечает в таблице маршрутизации запись о маршруте по умолчанию. Таких маршрутов может быть несколько с разными метриками (приоритетами). Используется тот маршрут у кого приоритет выше.
Так же и таблиц маршрутизации может быть несколько - это вариант как раз для ситуации, когда есть несколько каналов в интернет и нужно сделать балансировку нагрузки или отказоустойчивость (или гибридную схему). С помощью грамотной настройки фаервола и дополнительных скриптов можно все это организовать. Это уже придется делать самому, или использовать сторонний софт/железо. Но инструменты для подобных вещей есть.

Если интернет не доступен по заданному маршруту, то пакеты все равно будут отправляться и будут где-то пропадать. Так что ответов не будет или будет ответ с ошибкой. Соединения будут отваливаться либо по тайм-ауту, либо по ошибке.

В линукс обычно исполняемые файлы лежат в /bin, /sbin, /usr/bin, /usr/sbin.
Иногда в /usr/local/bin, /usr/local/sbin.
Еще некоторый софт ставит себя в /opt и там в собственном подкаталоге создает похожую иерархию каталогов.
Найти программу по имени можно с помощью команды whereis <имя программы>
Или с помощью find / -name <имя программы>
find будет работать дольше т.к. будет сканировать все что сможет. whereis сканирует только каталоги указанные в PATH, поэтому работает гораздо быстрей.

SMART всегда возвращает физическое состояние диска. Фактически состояние SMART хранится на контроллере диска, так что ПО тут значения не имеет.
У вас начались переназначения секторов. Это происходит, когда какие-то сектора на диске выходят из строя, в этом случае доступ к ним блокируется контроллером и вместо них назначаются другие (резервные) сектора. Резервных секторов ограниченное количество.
Пока что у вас только 3 переназначения (VALUE), предельное количество переназначений 36 (THRESH). Когда количество переназначений достигнет этого числа, то переназначать уже будет нечего, тогда контроллер диска будет возвращать ошибки чтения в ОС.
Еще какое-то время диск может пожить. Но не известно как быстро он исчерпает все переназначения.
Так что лучше слить с него все что можно и заменить.

Задержки могут быть вызваны переназначением секторов, т.к. прежде чем пометить сектор сбойным, контроллер пытается несколько раз его прочитать - вдруг получится. Поэтому задержки очень вероятны. Видимо диск у вас сыпется, но большая часть секторов еще кое-как читается (возможно не с первой попытки), т.к. переназначений еще мало. Но переназначения рано или поздно пойдут лавиной, тогда с диском уже ничего нельзя будет сделать.