сбойным блокам не удается обнаружить поврежденный контроллер диска
Хотя на самом деле вы не можете запустить полноценный тонкий клиент, вы можете сделать следующее лучшее - туннелировать весь свой X сеанс. Я нашел это решение в LinuxJournal .
xinit /usr/bin/xterm -- :1 &
ssh -fY remotehost /usr/bin/i3
(замените / usr / bin / i3 любым оконным менеджером, который вы предпочитаете)
xterm действительно может быть чем угодно, но xterm - это всего лишь установка 3 МБ на Arch Linux. Я также установил:
- xorg-xhost
- xorg-server
- xorg-xinit
(мне, возможно, на самом деле не требовалось xorg-xhost для его запуска).
Теперь у меня i3wm со всеми моими привязками клавиш, и он работает так же, как если бы я сидел за компьютером (плюс, конечно, небольшая задержка).
Кэш, который я упоминаю в своем редактировании, также может быть кешем, управляемым ОС, кешем, который находится в ОЗУ. Следующий сценарий также объясняет симптомы:
- некоторая часть ОЗУ с дальним адресом неисправна. ОС загружается в начало ОЗУ и поэтому не затрагивается
- позже при чтении/записи больших объемов данных на диск в конечном итоге используется вся оперативная память, включая неисправную часть
- badblocks использует лишь небольшой объем ОЗУ (вряд ли будет неисправным )и отключает кеш ОС для своего дискового ввода-вывода, поэтому это не влияет
- md5sum, с другой стороны, при «чтении» диска фактически считывает данные, кэшированные ОС, что иногда ошибочно.
Таким образом, для других читателей, имеющих те же симптомы, что и у меня :, выполните memtest.