Перенос/ресайз NTFS-тома с одного диска на другой средствами Linux

Задача, перетащить раздел NTFS на новый винт с увеличением размера. Скажем, со старого мелкого /dev/sda1 в новый большой /dev/sdb2.

# Обратите внимание, в конце указан источник!
ntfsclone --overwrite /dev/sdb2 /dev/sda1

# Если нужно спасать раздел с бедблоками, тогда
ntfsclone --rescue --overwrite /dev/sdb2 /dev/sda1

# Перенос закончен, теперь — увеличим старый размер на весь новый раздел
ntfsresize /dev/sdb2


Всё. В Ubuntu 14.04 эти утилиты оказались «из коробки».

Опыт обновления очень старой неподдерживаемой Ubuntu (12.10 Quantal до 14.04 LTS Trusty)

Довольно давно ставил Ubuntu на USB-флешку, в таком виде обновил разок, да так и пользовался, всё не доходили руки обновить. Даже как-то несколько дней полноценно работал, загрузившись с неё, когда были подозрения на близкую смерть SSD, а разбираться было некогда (ибо надо было работать :D)

В общем, сегодня я начал собирать домашний бэкап-сервер (AMD AM1, miniITX, корпус на 6 HDD), для теста загрузился с неё (кстати, забавно — на столе валялись только БП, материнка, много меньше этого БП и… всё), проверил систему, собрал и решил обновить до 14.04, благо, она достаточно стабильна.

Опаньки. Во-первых, apt-get update вообще нормально не завёлся. Тонна 404-х ошибок. Ковырялся я, ковырялся, и наткнулся в итоге на что-то типа

# do-release-upgrade

Проверка наличия новой версии Ubuntu
Ваша версия  Ubuntu больше не поддерживается.
Traceback (most recent call last):
  File "/usr/bin/do-release-upgrade", line 92, in <module>
    "%(url)s\n") % { 'url' : url }
ValueError: unsupported format character '?' (0xa) at index 55


Дальше я, наверное, час плясал, экспериментировал и обновлялся. Все ошибки и эксперименты уже и не вспомню, так что выкладываю ключевые элементы процесса :)

Установка Linux, демотиватор


Читать дальше →

Чиним flickrfs

Flickr с некоторых пор даёт под хранение фото 1Тб данных. Но загружать десятки тысяч домашней фотоколлекции через браузер из под Linux — это форменное издевательство. Однако, народ пытается как-то автоматизировать процесс. Одним из таких решений является flickrfs.

https://sites.google.com/site/manishrjain/flickrfs

Есть как сорцы, так и готовые пакеты под популярные дистрибутивы, включая текущие версии Ubuntu. Обещана интересная функциональность — монтирование своего аккаунта flickr через fuse в локальной системе, выгрузка и загрузка фото, работа с тегами, упорядочивание фотографий и т.п.

Но без доработки напильником, увы, никак не обойтись.

Первое, на что наткнулся — полное отсутствие любых действий и ошибок при штатном запуске. То есть настраиваем, привязываем к Flickr-аккаунту, автоматизируем, монтируем на выбранный каталог и… всё. Тишина. Любая попытка обратиться к каталогу вызывает зависание обратившегося процесса. Пока не убьёшь процесс flickrfs (он честно стартует) и не отмонтируешь каталог.

Через некоторое время изысканий удалось обнаружить первый шаг на пути исправлений. Нужно ввести небольшую задержку в цикле запуска тредов:
--- flickrfs.py.orig 2013-08-11 00:06:27.461206731 +0300
+++ flickrfs.py 2013-08-11 02:01:51.981314517 +0300
@@ -356,6 +356,7 @@
        curdir = "/sets/" + a['id']
        set_id = a['id']
        background(self.__sync_set_in_background, set_id, curdir)
+       time.sleep(0.7)
    log.info('sync_sets_thread finished')

    def sync_stream_thread(self):

После этого в логах пошли совершенно понятные
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 10: ordinal not in range(128)

Отлично! Дальше — дело техники. Вписываем в начало /usr/bin/flickrfs:
...
# -*- coding: utf-8 -*-
...
import sys
reload(sys)
sys.setdefaultencoding('utf-8')

И готово! Всё монтируется, всё загружается. Правда, как мне хочется, оно всё ещё у меня не работает, но это другая история…

Fredora Linux

А знаете ли Вы что…

Что нельзя запустить kdump на 32х битном ядре. Ядро включенное в FC17 скомпилировано без relocatable опции. И главное, пересобрать его с данной опцией невозможно, она автоматически отключается при компилировании.