October 23, 2011

Если раздел скукожился...

    Ставил на настольный РС Archlinux и столкнулся с определенной проблемой, чуть не обернувшейся катастрофой для мозга.
       На HDD была разметка разделов, изображенная на рисунке 1,А.

Рисунок 1

    Размер HDD (sda) состовляет 320 гб (625142448 секторов по 512 байт). Размеры прямоугольников, изображающих разделы, непропорциональны.

  1. sda1 ~ 42 гб - раздел для винды;
  2. sda2 ~ 128 мб - раздел /boot;
  3. sda3 ~ 278 гб - расширенный раздел;
  4. sda5 ~ 4 гб - раздел подкачки;
  5. sda6, sda10 ~ 38 и 5 гб соответственно - разделы /, /opt;
  6. sda4, sda7-9 - разделы NTFS, занимающие оставшуюся часть пространства.
    Разделы пронумерованы не по порядку, т.к. когда-то давно создавались под винду, потом уменьшались и перемещались, освобождая место для линукс.
    Проблема возникла следующая: при установке Archlinux решил я, что sda6 и sda10 необходимо объединить в один раздел. С виду задача довольно тривиальна, если судьба данных на разделах не представляет интереса. Я удалил оба раздела и на их месте создал новый. Делал я прямо из менюшки установки с помощью cfdisk. Операция прошла успешно, но я решил все же посмотреть, что вышло. При последующем запуске cfdisk он выдал довольно мрачное сообщение, касающееся /sda7 и перекрытия разделов (partitions overlapping), после чего работать отказался. Просмотр разделов с помощью fdisk показал следующее:
Disk /dev/sda: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xee4eee4e

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63    81899369    40949653+   7  HPFS/NTFS
/dev/sda2        81899370    82156409      128520   83  Linux
/dev/sda3        82156534   173293222    45568344+   5  Extended
/dev/sda4       173293223   216331289    21519033+   7  HPFS/NTFS
/dev/sda5        82156536    89963999     3903732   82  Linux swap / Solaris
/dev/sda6        89964063   173293222    41664580   83  Linux
/dev/sda7       216347418   349461944    66557263+   7  HPFS/NTFS
/dev/sda8       349468623   409464719    29998048+   7  HPFS/NTFS
/dev/sda9       409464783   624992759   107763988+   7  HPFS/NTFS
    Нетрудно увидеть, что sda3 стал заканчиваться перед sda4. Это отображено на рисунке 1 Б). При этом проверка таблицы разделов с помощью fdisk выдавала следующее:
Logical partition 7 not entirely in partition 3
Logical partition 8 not entirely in partition 3
Logical partition 9 not entirely in partition 3
Remaining 172803 unallocated 512-byte sectors
    В этот момент времени действительно было видно, что присутствует некоторое перекрытие, но все еще не было понятно, почему никто не ругается на sda4, ведь он первый шел после "помятого" раздела. Во всяком случае очевидным был тот факт, что проблему решать надо, и необходимо было любой ценой спасать sda9 (по личным причинам).

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

    Интересно вышло с виндой. Ей вообще наплевать на ошибки в таблице разделов и она спокойно может работать дальше, что очень коварно.

    Для дальнейших операций с диском подойдет, наверное, любой *nix Live CD. У меня под рукой было несколько, но выбрал я на крайний случай Ubuntu 10.04.
    Перепробовав все известные мне методы и утилиты, а также следуя советам, разбросанным по всяким интернетам, стало ясно, что проблема просто так совсем не решится. В конце-концов появились 2 идеи. Первая пришла из одной статьи и будет рассмотрена второй по порядку, т.к. изначально она показалась мне довольно стремной. Вторая идея пришла в голову сама. Она хоть и предполагает метод "кирки и лопаты", но зато гает дает полную гарантию если и не в результате, то в своих действиях. Поэтому она будет рассмотрена первой.

    1. EDITING "MRB" MANUALLY
   Да, это редактирование MBR вручную. Да, это первое, что пришло в голову. Мазохизм? Нет. Трудно согласится, что поменять цифру, указывающую размер раздела - дело сложное. Используемые мною программы и утилиты ни при каких условиях не соглашались на такое. Что им мешает - ума не приложу. Поменять 4 байта жалко чтоли...
     Этап 1. Получаем MBR. Для этого понадобится какой-нибудь внешний носитель, например, флешка. Копируем MBR на флешку:
sudo dd if=/dev/sda of=/media/ALEXAD_ER/mbr.bak bs=512 count=1
    ALEXAND_ER - имя флешки, mbr.bak - имя файла с MBR.
    После этого делаем еще одну копию, например, mbr2.bak. Открываем её в каком-нибудь HEX-редакторе, например, в ghex. Далее переходим на 446-й байт (0х1ВЕ), к 64-байтной таблице разделов.

Рисунок 2

    Структура записей в этой таблице достаточно хорошо расписана на Вики. Интерисующая нас запись помечена зеленым, а поле, отвечающее за размер раздела, обведено красным. Поскольку таблица загружается прямо в оперативную память, то порядок байт в ней сразу изменен на обратный. Т.о. 0xB1A26E05 следует записывать как 0x056EA2B1, т.е., 91136689. В предыдущих 4-х байтах зранится адрес сектора начала раздела: 0x04E59BF6 = 82156534. Отсюда следует, что раздел заканчивается на секторе 91136689+82156534=173293223. Интересно, что sda4 именно на нем начинается. Решив изменить границу раздела до 625142448-го сектора, я в поле размера записал вместо 0x056EA2B1 число 0xBA4E5D20 (542985914 секторов по 512 байт = ~278 гб). После этого сохраняем mbr2.bak и записываем его содержимое на место MBR:
sudo dd if=/media/ALEXAD_ER/mbr2.bak of=/dev/sda bs=512 count=1
    На этом я решил закончить, но потом понял, что сильно ошибся. Под виндой Paragon Partition Manager показал следующую картину:

Рисунок 3

    И вот тут-то я два раза конкретно стормозил. Казалось бы, что до окончания проблемы оставались считанные минуты, то тут я отсрочил этот момент ещё. Я не обратил внимание на то, что последняя запись в таблице MBR не заполнена нулями, сообщая о том, что 4-й раздел не предусмотрен. На рисунке 2 явно видно, что после 3-го раздела, расширенного, идет 4-й, NTFS. Странно, но я этого не заметил. Ну это еще несколько простительно - HEX-код вполне мог просто поплыть в плазах. Но рассматривая данные Partition Manager, я стормозил конкретно. Посмотрев на invalid-раздел в конце sda, мне показалось, что это неправильно определились свободные 72 мб. Нет, я не заметил, что там было 20.5 Гб, а также, я не заметил, что внутри sda появились свободные все те же 20.5 Гб. В этот момет вполне вероятно, что достаточно было заполнить последнюю запись в MBR нулями, но нет, я стормозил и решил удалить invalid-раздел с помощью Partition Manager. И сразу же получил BSOD. Как серпом... После этого таблица разделов после sda2 совсем с ума сошла. Немного поразмыслив, решил, что после такой ошибки последняя надежда - это 2-й метод.

    2. PARTITION TABLE FROM SCRATCH
     Этот метод предполагает полную перезапись таблицы всех разделов. Его я откопал в статье "Partition-Rescue HOWTO". Хоть было очевидно, что данные с разделов никуда не делись и лежат спокойно на своих местах, идея об удалении таблицы разделов и перезаписи её по старым секторам с помощью fdisk выглядела очень стрёмной. Даже слишком. К счастью, самую первую распечатку fdisk (до редактирования MBR) я сохранил на флешку (так же как и вторую). В принципе, даже если бы я их не сохранил, можно было бы воспользоваться утилитой "gpart", которая читает MBR, ищет старые EBR и может помочь восстановить старую разметку. За угадывание старой разметки ей, конечно, спасибо, а вот восстанавливать это дело я её не доверил бы. Хотя бы потому, что она не нашла злополучный sda4 (хоть и остальные нашла). Короче говоря, с помощью fdisk я создал пустую таблицу разделов и разметил новые назделы по старым секторам, указывая типы разделов. Очень важно размечивать по секторам, а не по цилиндрам, т.к. на одном цилиндре куча секторов и на нужный невозможно будет попасть. После переразметки таблица стала выглядеть следующим образом:
Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63    81899369    40949653+   7  HPFS/NTFS
/dev/sda2        81899370    82156409      128520   83  Linux
/dev/sda3        82156534   625142447   271492957    5  Extended
/dev/sda4       173293223   216331289    21519033+   7  HPFS/NTFS
/dev/sda5        82156536    89963999     3903732   82  Linux swap / Solaris
/dev/sda6        89964063   173293222    41664580   83  Linux
/dev/sda7       216347418   349461944    66557263+   7  HPFS/NTFS
/dev/sda8       349468623   409464719    29998048+   7  HPFS/NTFS
/dev/sda9       409464783   624992759   107763988+   7  HPFS/NTFS
    Все прошло успешно, и даже Gparted с Live LD все нормально показывал, а разделы нормально монтировались, и старые данные успешно отображались. При этом проверка таблицы разделов с помощью fdisk выдавала следующее:
Remaining 172803 unallocated 512-byte sectors
    Единственное, что пришлось сделать еще, так это с CD-диска винды запустить mbrfix, а после неё chkdsk. После этого даже винда нормально поднялась.
     Данные, естественно, никуда не пропали.

Ментальный глюк - веб-лифт

    Нужно было подняться на 5-й этаж. Захожу в лифт. Стою секунды две, после чего понимаю, что как-то медленно происходит процесс подъема, вернее не происходит вообще. Короче, превышение времени отклика с зависанием (это при том, что я просто зашел и ничего не нажимал). Смотрю на кнопки на панели и понимаю, что вижу клавишу F5. Сразу возникает мысль "надо обновить, чтоли". Нажимаю. Вуаля - все заработало. Проехав несколько этажей, осознаю, что эта клавиша совсем не "F5", и нажал я совсем не на "обновить"...
    Позже сфоткал (кнопки обычные в лифте) и на компе добавил буквы для передачи ощущений, чтобы выглядело так, как мне  сперва показалось:


Archlinux + pacman autocomplete (bash)

    Чтобы в pacman'е работало автодополнение, необходимо поставить пакет "bash-completion":
pacman -S bash-completion
    После этого в файле "~/.bashrc" добавить следующее:
complete -cf sudo
complete -cf man
     И, наконец, перезапустить терминал.

Gentoo bash color scheme

    Чтобы в терминале цветовая схема была как в Gentoo, в файл
/etc/bash.bashrc
    нужно поместить содержимое этого скрипта по [ссылке].

Archlinux + KDE + Ubuntu fonts

    Год посидел на Ubuntu. Для работы очень хороша. Правда, несколько огорчает нынешняя тенденция развития в сторону Unity. Смотришь на 11.10 - начинаешь понемного чувствовать себя блондинкой. Захотелось больше линукса, чем няшных "тыцалок и выпадалок". Поставил Archlinux. Причем вместе с х-ами и с первого раза. Хэндбук порадовал очень. На гентушный похож.
   Но дело не в этом. Захотелось мне привычные шрифты поставить, а именно, из Ubuntu Font Family.  Покопавшись в том же хендбуке, нашел то, что и хотел.
   Ставим шрифты:
pacman -S ttf-ubuntu-font-family
    Выглядят вполне хорошо. Не плывут, не размазываются. Красота.

October 22, 2011

Authentication is required to mount

    Чтобы при обращении к внешним носителям не выскакивало сообщение "Authentication is required to mount ..." необходимо сделать следующее:

1. открыть с правами администратора файл:
/usr/share/polkit-1/actions/org.freedesktop.udisks.policy
2. в секциях action, имеющих следующие id:

a) org.freedesktop.udisks.filesystem-mount
b) org.freedesktop.udisks.filesystem-mount-system-internal
c) org.freedesktop.udisks.filesystem-umount-others (не всегда обязательно)

    значение элемента <allow_active> изменить с auth_admin на yes, например:
<action id="org.freedesktop.udisks.filesystem-mount">
  <description>Mount a device</description>
  <description xml:lang="da">Montér en enhed</description>
  <message>Authentication is required to mount the device</message>
  <message xml:lang="da">Autorisering er påkrævet for at montere et fil system</message>
  <defaults>
    <allow_any>no</allow_any>
    <allow_inactive>no</allow_inactive>
    <allow_active>yes</allow_active>
  </defaults>
</action>
   
    Следует отметить, что после обновления системы, возвожно, эту операцию придется выполнить вновь.