Эксперименты с hibernate/tuxonice

[Pro]

Ну и начинает подъем туксонайза без всякого init.

при включенной опции обработки init (в настройках tuxonice) параметр resume может и обрабатывается но запускается init и вот из него не пробуждалось ничего.

Ну вот появилась ясность вобщем будет работать.

[Pro]

опробовал загрузку с tux_file - работает!!!!
в подсказке для добавления  параметра в menu.lst ошибка, ведь вместо resume используем tux_path - вот оно меня и сбивало все время, ну и путь к разделу почему то по uuid указывается т.е. вместо file:/dev/sda8:12eed имеем file:UUID=6c081252824a4d559ff597df86f85411:0xd797d8 что конечно немного напрягает....

[dim-kut]

в подсказке для добавления  параметра в menu.lst ошибка, ведь вместо resume используем tux_path - вот оно меня и сбивало все время

Да, там наверно есть ошибки, но мы вроде решили при работе с встроенным жестким диском (пользователь выбирает HDD или USB) работать с параметром resume, без init, так быстрее будет.

UUIDов я ни разу не встречал, возможно потому, что всегда была сохраненка.

[Pro]

Да, там наверно есть ошибки, но мы вроде решили при работе с встроенным жестким диском (пользователь выбирает HDD или USB) работать с параметром resume, без init, так быстрее будет.

эм... не помню чтобы мы решили что-то подобное. Давай тогда распиши что делается, когда пользователь выбирает пункт что работает с USB. И при компиляции ядра обработка init для tuxonice должна быть включена или выключена?

[dim-kut]

эм... не помню чтобы мы решили что-то подобное.

Ну где-то в начале этой темы ты говорил, что лучше бы обойтись без init, для скорости. Поэтому при выборе пользователем встроенного HD я подставляю параметр resume. Можно конечно использовать tux_path и tux_delay=0, но потеряем чуть времени на распаковку initrd. На первой версии ядра с туксонайз у меня работали оба варианта - с init и без.

И при компиляции ядра обработка init для tuxonice должна быть включена или выключена?

Вот это не знаю.

[Pro]

Поэтому при выборе пользователем встроенного HD я подставляю параметр resume.

А при выборе USB? что подставляем?

[dim-kut]

А при выборе USB? что подставляем?

Для USB я и придумал вставку в init, чтобы выждать несколько секунд, пока USB очухается. С параметром resume с USB не поднимешься - ядро сразу запускает подъем, а шина еще не готова.

Т.е. подставляем tux_path ( = то же, что и resume ) и tux_delay= 5-10 секунд.

[Pro]

ну нет, это нам не подходит, делаем так:

1. в ядре включаем обработку init скрипта (собственно это уже сделано)
2. в init скрипте заклыдваем твой код (тоже сделано, код я разместил после секции wait_usb т.е. если загрузка с диска usb то будет ожидание готовности устройства, если с HDD то не будет ожидания)
3. для правильного пробуждения задаем tux_path и если нужно tux_delay (тоже уже сделано) никаких параметров resume=
4. Нужна корректировка вставки в init чтобы при отсутствии образа resume, но при заданных tux_path не происходил выход из init скрипта а то виснет система.
5. ну и как-то надо протестировать чтобы от uuid избавится или проверить чтоб по всякому работало.

[dim-kut]

4. Нужна корректировка вставки в init чтобы при отсутствии образа resume, но при заданных tux_path не происходил выход из init скрипта а то виснет система.

Можно ввести еще один параметр tux_path_check какой-нибудь, и передавать путь к файлу в init в нормальном виде, и там проверять его наличие. В случае раздела сложнее, надо подумать, может cat /proc/partitions поможет, не знаю покажет ли она swap.

[Pro]

не не, не то.
Tuxonice в dmesg и свои логи пишет что image not found, вот это просто надо обработать и не делать exit из скрипта init.
вычислять конечно по логам самой программы лучше, где то в /var/log чтоли читал файл логов от tuxonice.

Само наличие файла проверять смысла нет, в нем может просто не сохранили ничего, а файл сделали. (так же и в swap разделе)

[dim-kut]

4. Нужна корректировка вставки в init чтобы при отсутствии образа resume, но при заданных tux_path не происходил выход из init скрипта а то виснет система.

/sys/power/tuxonice/last_result -> Bit flag - if last hibernate failed, why?
Я проверил, есть такой файлик с 0, значит подниматься надо только когда там 1, иначе - обычная загрузка.

2. в init скрипте заклыдваем твой код (тоже сделано, код я разместил после секции wait_usb т.е. если загрузка с диска usb то будет ожидание готовности устройства, если с HDD то не будет ожидания)

echo 1 > /sys/power/tuxonice/do_resume
Это необходимо вставить после монтирования /sys, Но перед монтированием файловых систем.

Отсюда - http://ru.gentoo-wiki.com/wiki/TuxOnIce

[Pro]

ну при загрузке системы /sys создается заново, так что в этом файле будет 0 а 1 появится только при подключении save файла, ведь в нем все изменения. Так что не вариант.

[dim-kut]

Саш, ну ты бы выложил сборку к выходным, я бы поэкспериментировал. А то у меня вахта уже заканчивается, последняя неделя пошла.

[Pro]

сегодня.

[dim-kut]

Нет, не получается поднятся с USB.
Сначала сделал swap_file, он туда даже ложится не захотел. Но долго не разбирался, перешел на suspend_file. Ложится, при подъеме постоянно утыкаюсь в ту же картинку, которую последний раз выкладывал. В качестве параметра для подстановки в загрузчик в случае suspend_file всегда предлагается UUID.

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