GRUB не запускает образ iso

[andytux]

Зачем загрузка с раздела ntfs?

На этом ноуте загрузка настроена туда. Переносить не стал. По логике, это более проблемный вариант, чем с ext4-раздела. Все таки "вражеская ФС". Попадались высказывания на форуме, что с НТФС-раздела вообще ничего не запускается.

Места на системном разделе нет?

В данный момент действительно нет.

Какой:
код в /etc/grub.d/40_custom?
md5 хэш у твоего образа lubuntu-14.04-desktop-i386.iso ?
ФС на системном разделе?

Код, как по ссылке, которую я давал. Хеш не проверял. Посмотрел хеш для образа там где скачивал, во всяком случае мы ведем речь об одном и том-же файле. На системном разделе ФС - ext4.

Для чистоты эксперемента можешь сделать точно как у меня?

Могу, но не буду.

Кажется нашел причину ошибки.
Из 14.04 системный раздел ext4 с 18.04 просто не монтируется.

Эту версию может попробую проверить, позже.

Пользователь добавил сообщение 12 Марта 2019, 10:31:15:"Ну а после - чудеса мне по такому случаю"
Отрабатываю версию: "Из 14.04 системный раздел ext4 с 18.04 просто не монтируется."
Скопировал образ на раздел ext4. Пробую загрузится.
1. Загрузка "loopback bootable". Неудача. Ошибка точно как на твоем скриншоте.
2. Обычная загрузка из исо-образа (моим кодом). Неудача. Ошибка точно как на твоем скриншоте.
3. Загрузка "кодом от ReNzRv". Неудача. Ошибка точно как на твоем скриншоте.
4. Загрузка с помощью memdisk. Для образа выделил 700мб памяти. Неудачно. Загрузка началась, появился экран с точками. После него вывалился в консоль с ошибкой, что не может найти устройство с живой системой.
5. Загрузка "из набора файлов". Неудача. Ошибка точно как на твоем скриншоте.
Версия подтверждается. Вот тебе и "самая родная ФС".  И еще в подтверждение этой версии.
 Начинаю припоминать, что я уже сталкивался с таким поведением нового ext4.
Поэтому, на другом ноуте (32битный) во избежание проблем со старыми версиями системы разделы форматировал в "старую версию ext4". Точно не помню, но наверно запускал старую версию Ubuntu и старой версией гпартед создавал разделы.
Один раздел, который файлопомойка, создан-отформатирован давно, его не трогал. А раздел для системы создал "со старой версией ext4".
Установил без форматирования 18.04 с mini.iso + LXDE. Сейчас скопировал на него образ lubuntu-14.04-desktop-i386.iso.
Загружается без проблем с обоих разделов.
Вывод tune2fs для старой и новой версии ext4:

(Нажмите, чтобы показать/скрыть)

tune2fs 1.44.1 (24-Mar-2018)
Filesystem volume name:   fuj120_1
Last mounted on:          /
Filesystem UUID:          edecc6fa-f40a-45f5-85f0-b0e0ec0962ae
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              512064
Block count:              2048031
Reserved block count:     102401
Free blocks:              438889
Free inodes:              380099
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      499
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8128
Inode blocks per group:   508
Flex block group size:    16
Filesystem created:       Wed May  2 18:04:23 2018
Last mount time:          Tue Mar 12 13:30:59 2019
Last write time:          Tue Mar 12 13:29:22 2019
Mount count:              1011
Maximum mount count:      -1
Last checked:             Fri May 11 07:44:22 2018
Check interval:           0 (<none>)
Lifetime writes:          174 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:             256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      de141a94-9c71-4720-8be7-9f4945a949c9
Journal backup:           inode blocks

tune2fs 1.44.1 (24-Mar-2018)
Filesystem volume name:   hit320_3
Last mounted on:          /
Filesystem UUID:          504fd29d-5da9-4ff6-8713-aa20f98bc687
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              602656
Block count:              2408935
Reserved block count:     20000
Free blocks:              192851
Free inodes:              373178
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8144
Inode blocks per group:   509
Flex block group size:    16
Filesystem created:       Thu Jul 12 16:57:09 2018
Last mount time:          Tue Mar 12 12:50:04 2019
Last write time:          Thu Dec 13 08:23:43 2018
Mount count:              835
Maximum mount count:      -1
Last checked:             Thu Jul 12 17:32:19 2018
Check interval:           0 (<none>)
Lifetime writes:          305 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:             256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
First orphan inode:       131975
Default directory hash:   half_md4
Directory Hash Seed:      e84056e2-ee3b-48d8-9014-58f9ccc108f9
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0x36c9b996

Замеченные различия:
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Group descriptor size:    64
Это в новой версии, В старой нет "Group descriptor size", "extent 64bit". Может еще что, досканально не сравнивал.

[ReNzRv]

andytux,
Вот теперь пазл сложился) Благодарю.
Странно, но тем с подобной проблемой не находил, возможно не то искал. Надеюсь эта тема кому-то поможет.
Проблема определена, решение понятно, ставлю - "Решено".

[andytux]

С проблемой-то есть, а вот решений... Как минимум мне она помогла. Повозился - лучше запомню.
Сейчас, когда стала понятно суть проблемы, видно, что название темы не соответствует. Груб выполнял свою задачу полностью, запускал ядро и передавал ему параметры.
Это уже сама система не могла работать на файловой системе, которая ей незнакома.

[ReNzRv]

Да, согласен, не соответствует - но это если знаешь проблему!
А если не знаешь, то виновником кажется именно GRUB, и искать люди будут скорее всего примерно по такой фразе, поэтому пускай остается как есть)

[fdxcd]

Груб выполнял свою задачу полностью, запускал ядро и передавал ему параметры.
Это уже сама система не могла работать на файловой системе, которая ей незнакома.

Включим логическое мышление. Подумаем, если запускать не с помощью GRUB, будет работать с iso-образа, записанного на ntfs?

[ReNzRv]

fdxcd,
А Вам логическое мышление не дает очевидный  ответ?
Конечно это зависит от загрузчика.
Но здесь мы другие загрузчики не собираемся обсуждать.

[fdxcd]

А Вам логическое мышление не дает очевидный  ответ?

Мне моё даёт. Но ведь кто-то здесь не исключительно обо мне заботится? Вот:

Странно, но тем с подобной проблемой не находил, возможно не то искал. Надеюсь эта тема кому-то поможет

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

виновником кажется именно GRUB

Так только кажется? Или так и есть?

Конечно это зависит от загрузчика

Пользователь добавил сообщение 13 Марта 2019, 13:56:24:

мы другие загрузчики не собираемся обсуждать.

И не надо. Определиться хотя бы именно GRUB оказался виновником, или это только кажется, что GRUB виноват. Для этого и предлагалось ответить на вопрос, а не обсуждать другие загрузчики.

[ReNzRv]

fdxcd,
Загрузка образа с NTFS, и моя проблема - это две разные темы которые Вы зря пытаетесь объеденить.
В моем случае - загрузчик не причем.

(Нажмите, чтобы показать/скрыть)

Предлагаю закончить этот флуд и удалить наши сообщения до ответа №48.
В противном случае придется обратится к помощи модераторов.