Восстановление fstab astra linux

How to force OS reload of fstab?

I suspect this is caused by systemd’s conversion of /etc/fstab ; traditional mount doesn’t remember the contents of /etc/fstab .

To refresh systemd’s view of the world, including changes to /etc/fstab , run

Sigh. An auto-generated comment in the top of /etc/fstab reminding/advising people it has now been deprecated — and how to update systemd — would go a long way.

Thanks! You can imagine Google returned nothing but ‘mount -a’ hits for this query. Are there any unwanted side-effects when doing this on-the-fly re-gen of the tables? Doesn’t seem to be.

For more, see unix.stackexchange.com/a/236968/5132 and unix.stackexchange.com/questions/90723 . Note that the Debian service that used to run mount -a is nowadays masked.

To elaborate the answer from @Stephen Kitt: for example I have this entry in /etc/fstab :

vnetsvr-home:/etc/skel /etc/skel nfs4 sec=krb5p,noauto,x-systemd.automount,x-systemd.idle-timeout=10min 0 0 

and only doing sudo systemctl daemon-reload doesn’t reloaded the fstab. I have to do:

rpi ~$ sudo systemctl daemon-reload rpi ~$ sudo systemctl restart remote-fs.target 

To reload an entry to mount a local filesystem you should use:

rpi ~$ sudo systemctl daemon-reload rpi ~$ sudo systemctl restart local-fs.target 

I know that these solutions might not work in every linux distro and version. However this method would generally works for all Linux versions.
1- Do your configuration and change the fstab file
2- Use this command to remount the device_file you have changed its configuration in the fstab file:
# mount -o remount [device_file]
This way you will mount the partition with its new configuration read from «fstab» file.
If you removed a partition from «fstab» file, simply umount [device_file] . Be sure, the partition stays unmounted after the reboot.

Any time you can check the result by running mount command.

As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.

Источник

Русские Блоги

Если вы экспериментируете на виртуальной машине, сделайте снимок перед экспериментом. Во время процесса могут возникнуть непредвиденные ситуации (хотя шаги и операции в порядке).

Шаг 1. Сначала удалите все файлы в / etc / fstab и / boot (их можно переместить в другие разделы)

Когда первым шагом будет перезагрузка виртуальной машины, появится следующая ситуация:

Шаг 2. После перезапуска войдите в программу загрузки grub напрямую. В этот раз мы перезапустим систему и войдем в режим восстановления. Я не буду рассказывать здесь, как войти в режим восстановления. В блоге (http://www.178linux.com/83078) Есть подробное описание, как войти в режим спасения.

При входе в режим восстановления он будет отличаться от предыдущего, потому что мы удалили файл / etc / fstab, поэтому система не может смонтировать корневой и / boot раздел

Но это не имеет значения, просто нажмите ОК, чтобы перейти к следующему шагу, а затем откройте оболочку.

Шаг 3. Восстановите / etc / fstab

Поскольку файла / etc / fstab нет, система не может помочь нам смонтировать раздел, поэтому нам нужно сначала восстановить файл / etc / fstab, то есть рукописный файл / etc / fstab, для которого необходимо смонтировать как минимум два раздела: корневой и / boot. Перед записью файлов мне нужно знать, какой раздел является корневым, а какой — / boot. Вы можете использовать команду fidsk -l, чтобы проверить раздел.

Трудно судить, какой раздел что делает, но если вы точно знаете, какой раздел делает, то можете напрямую записать файл / etc / fstab. Теперь давайте создадим каталог для временного монтирования раздела, давайте посмотрим / Какой из них корень, dev / sda2 или / dev / sda3.

Разделы root, / boot и swap найдены, теперь вы можете спокойно писать файл / etc / fstab

Формат записи файла / etc / fstab:

Имя раздела или устройства Монтируемый каталог Параметры файловой системы по умолчанию (установлено по умолчанию) 0 0 (последние два лучше всего установить на 0)

Шаг 4: Восстановите загрузку

Затем перезапустите систему, после входа в режим восстановления позвольте системе автоматически смонтировать рут для нас и перейдите к следующему шагу для восстановления

Когда мы входим в режим восстановления, мы можем вырезать корень, команда cut root: chroot / mnt / sysimage

В это время вы можете начать восстановление каталога / boot. Прежде всего, мы должны знать файлы, необходимые для запуска системы: ядро ​​Linux (правильная версия), gurb, grub.conf

Сначала смонтируйте компакт-диск, а затем установите ядро ​​(вы также можете напрямую скопировать файл ядра с компакт-диска)

Установите команду ядра: rpm -ivh / mnt / Package / номер-версии ядра (можно заполнить клавишей табуляции) .rpm

После успешного создания ядра установите grub, команду: grub-install / dev / sda

Требуется некоторое время, чтобы установить gurb, терпеливо подождать и посмотреть, есть ли программа gurb после завершения

До сих пор отсутствует файл /boot/grub/grub.conf, который требует, чтобы мы написали вручную

default 0 # По умолчанию выбрать первый элемент
timeout 3 # Выберите, чтобы подождать 3 секунды, затем введите параметр по умолчанию
title Linux-CentOS6.9 # Имя параметра меню
kernel /vmlinuz-2.6.32-696.el6.x86_64 root = / dev / sda2 # версия ядра и корневое расположение
initrd /initramfs-2.6.32-696.el6.x86_64.img #init

Источник

Общие сведения

В данной статье рассматривается способ восстановления загрузочных файлов (содержимого каталога /boot) в ситуации, когда из-за их повреждения нормальная загрузка ОС стала невозможной. Восстановление включает в себя следующие этапы:

• загрузка с инсталляционного диска с последующим переходом в «режим восстановления»;
• необязательное резервное копирование содержимого каталога /boot;
• подключение к каталогу /boot временной файловой системы, имеющей свободное место;
• перегенерация файла initrd;
• замена старого файла на новый;

Типичная ситуация, в которой могут потребоваться такие действия: неудачно завершившееся обновление при недостатке места в дисковом разделе /boot. После такого неудачного обновления система перестает загружаться и, как правило, выводит ошибку:

- - - [ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknow-block(0,0)

Возникновения ошибки нехватки места характерно для систем, установленных с использованием LVM, поэтому далее в примере рассматриваются действия с системой, установленной с использованием LVM. Действия для других вариантов установки аналогичны, отличаться будут только названия дисковых разделов.

Загрузка в режиме восстановления

Для загрузки в режиме восстановления требуется инсталляционный диск (USB-накопитель) ОС Astra Linux Special Edition очередное обновление 1.6.
Порядок действий:

1. Вставить инсталляционный диск в привод;
2. Загрузиться с инсталляционного диска;
3. Выбрать «Режим восстановления»:

Проследовать по пунктам (нажимая Enter) до выбора корневой файловой системы, где выбрать . /root:

Затем выбрать запуск оболочки так же в /dev/16-lvm-vg/root:

После выполнения указанных действий должен загрузиться терминал с синим фоном:

Нажать CTRL+ALT+F2 и нажать Enter, после чего должен открыться терминал на черном фоне:

Резервное копирование каталога /boot

Резервное копирование каталога /boot не обязательно.

Копирование выполняется в каталог /home, в папку boot-backup, в случае успешного восстановления загрузки системы не забудьте его удалить.

Для создания резервной копии выполните в терминале команду:

Дождитесь завершение работы команды.

Освобождение места в каталоге /boot

Проверить содержимое каталога /boot:

итого 226516
drwxr-xr-x 3 root root 4096 апр 10 21:40 .
drwxr-xr-x 25 root root 4096 апр 13 17:27 ..
-rw-r—r— 1 root root 1492731 июн 20 2018 abi-4.15.3-1-generic
-rw-r—r— 1 root root 1467894 июн 20 2018 abi-4.15.3-1-hardened
-rw-r—r— 1 root root 215263 июн 20 2018 config-4.15.3-1-generic
-rw-r—r— 1 root root 215941 мар 4 16:10 config-4.15.3-2-generic
drwxr-xr-x 5 root root 4096 апр 10 21:40 grub
-rw-r—r— 1 root root 46731042 апр 10 21:40 initrd.img-4.15.3-1-generic
-rw-r—r— 1 root root 45810528 апр 10 21:39 initrd.img-4.15.3-1-hardened
-rw-r—r— 1 root root 46182771 апр 10 21:40 initrd.img-4.15.3-2-generic
-rw-r—r— 1 root root 44873873 апр 10 21:40 initrd.img-4.15.3-2-hardened
-rw——- 1 root root 8038256 июн 20 2018 old-vmlinuz-4.15.3-1-generic
-rw——- 1 root root 7214960 июн 20 2018 old-vmlinuz-4.15.3-1-hardened
-rw-r—r— 1 root root 0 июн 20 2018 retpoline-4.15.3-1-generic
-rw-r—r— 1 root root 0 июн 20 2018 retpoline-4.15.3-1-hardened
-rw——- 1 root root 3969624 июн 20 2018 System.map-4.15.3-1-generic
-rw——- 1 root root 3186040 июн 20 2018 System.map-4.15.3-1-hardened
-rw——- 1 root root 3995440 мар 4 16:10 System.map-4.15.3-2-generic
-rw——- 1 root root 3174738 мар 4 16:10 System.map-4.15.3-2-hardened
-rw——- 1 root root 8144672 мар 4 16:10 vmlinuz-4.15.3-2-generic
-rw——- 1 root root 7190304 мар 4 16:10 vmlinuz-4.15.3-2-hardened

В примере выше видно, что в каталоге /boot хранятся две версии ядра — 4.15.3-1 и 4.15.3-2, и каждая версия представлена в двух вариантах — generic и hardened. Удалить ненужные файлы можно командой rm. Например, если не используется ядро hardened, то удалить все файлы, относящиеся к этому ядру:

Создание initrd

Новый initrd создать командой:

При этом вместо номера 4.15.3-2 использовать номер имеющегося в системе ядра, которое предполагается использовать.

Необязательное создание гарантированного свободного места

Монтирование tmpfs в каталог /boot

Для того, чтобы смонтировать в каталог /boot чистую файловую систему, имеющую свободное место, выполните команду:

После выполнения монтирования старое содержимое каталога /boot станет недоступно, и каталог будет представляться пустым.

Создание и перемещение initrd

Новый initrd в примонтированной файловой системе создать такой же командой:

При этом вместо номера 4.15.3-2 использовать номер имеющегося в системе ядра, которое предполагается загружать в дальнейшем.
Так как после отмонтирования времнной файловой системы всё её содержимое будет утеряно, нужно сохранить новый сформированный initrd, например, скопировав его в каталог /home командой:

Замена initrd

Отмонтировать tmpfs от каталога /boot командой:

Заменить старый файл initrd.img-4.15.3-2-generic на новый командой:

Если для копирования недостаточно места — повторить удаление ненужных файлов, после чего повторить операцию копирования.

Перезагрузка системы

После замены файла initrd обязательно выполнить команду:

Действия после успешной перезагрузки

Дальнейший порядок действия зависит от причины, вызвавшей неисправность.

В частности, в случае незавершённой установки обновления, следует завершить установку обновления командой:

Источник

Quick way to restore or reload /etc/fstab settings?

I’m working with a complex /etc/fstab on a RHEL 6.x-based server. The system has a variety of mount options in use across eight partitions, including several bind mounts. I’m testing options and their effect on the image I’m working on. e.g. options like nodev , nosuid , noexec , nobarrier and several XFS filesystem parameters are in place. While I know it’s possible to remount with specific options, is there a quick way to revert all mounts to the persistent settings hardcoded in /etc/fstab ? For instance sysctl -p loads the /etc/sysctl.conf values and applies them. Is there a mount equivalent? Edit: An example config:

# # /etc/fstab # UUID=e6ca80cd / ext4 noatime,nobarrier 1 1 UUID=a327d315 /boot ext4 defaults 1 2 UUID=333ada18 /home ext4 noatime,nobarrier,nodev 1 2 UUID=7835718b /tmp ext4 nodev,nosuid,noexec 1 2 UUID=4dd2e9d4 /usr ext4 defaults 1 2 UUID=c274f65f /var ext4 noatime,nobarrier 1 2 UUID=5b5941e0 /var/log ext4 defaults 1 2 UUID=3645951a /var/log/audit ext4 defaults 1 2 UUID=3213123c /vol1 xfs noatime,logbufs=8,nobarrier 1 2 UUID=1ee1c070 swap swap defaults 0 0 # Bind mount for /tmp /tmp /var/tmp none bind 0 0 tmpfs /dev/shm tmpfs nodev,nosuid,noexec 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 

Of course, a developer asks for execute permissions on /tmp in order to install an application. I’m finding that the remount option does not work on this system without specifying the device and (re)mountpoint. This is a security-hardened server, so the issues I’m seeing may be SElinux-related or a result of the bind mounts, or maybe even the presence of negated options (noexec versus exec).

Источник