Вы не слишком далеко продвинулись в своих попытках. Попробуйте эту небольшую адаптацию вашего собственного кода:
$ for file in *.cc.json*ml; do mkdir -p ${file%%.*}; mv -v ${file%%.*}.* ${file%%.*}; done
renamed '102.cc.json2.pre2.ml' -> '102/102.cc.json2.pre2.ml'
renamed '102.json2.pre1' -> '102/102.json2.pre1'
renamed '1.cc.json2.ml' -> '1/1.cc.json2.ml'
renamed '1.json2' -> '1/1.json2'
renamed '1.json2.pre1' -> '1/1.json2.pre1'
Мне так и не удалось решить эту проблему с неработающим обновлением. Тем не менее, отличная функция моментального снимка Btrfs (, которая теперь используется по умолчанию для корневого раздела в openSUSE Tumbleweed ), по крайней мере, позволила мне вернуться к моментальному снимку непосредственно перед zypper dup
, который сломал все. Таким образом, я мог вернуться к графическому рабочему столу. См. на этой странице для получения информации о моментальных снимках системы openSUSE.
Проблема заключалась в том, что независимо от того, сколько дней/недель прошло, как только zypper dup
запускался снова, повторялась та же проблема, и графический рабочий стол зависал при загрузке.
В конце концов мне пришлось переустановить openSUSE поверх самого себя (, сохранив отдельный домашний раздел, чтобы не восстанавливать его тоже ). Теперь openSUSE Tumbleweed работает на последней версии и может обновляться без нарушения работы графического рабочего стола.
Мораль здесь такова: :используйте Btrfs с включенными моментальными снимками для вашего корневого каталога и поместите свой домашний каталог в отдельный раздел.