Squashfs error arch

Ubuntu Documentation

SquashFS Errors

Problem Statement

Some users have reported being unable to boot from the Ubuntu LiveCD, due to SquashFS errors like this:

Example error when loading Xubuntu with Wubi on first boot:

Causes and Solutions

These errors can be due to a variety of reasons:

• bad memory modules (solution: use memtest86+ to check your memory)
• a bad dvd drive (solution: if possible, try using a different cd/dvd drive)
• bad data cable (solution: change it for a new one)
• bad media (solution: try burning the iso image to a new disc)
• a corrupted iso image (solution: run an md5 checksum, and if they don’t match, download the iso image again)

Temporary Workarounds

Some users have reported that adding the ide=nodma or acpi=off allowed them to work around this issue (which proved to be bad memory modules). You might want to give that a try

Successful boot was achieved by adding «all_generic_ide» to the grub boot line for the live CD.

You can add those lines to the grub entry, either in the grub.conf file or either entering letter ‘e’ on the grub menu and after editing Control+x to boot:

Add to the grub line:

Add to the kernel line:

More information about the problem in grub can be found here: https://bugs.launchpad.net/wubi/+bug/608941

If is not a HW problem and you can probe it

If you definitely found that is not a HW issue, add you comment with all the logs and evidence you can get to Launchpad bug #172937

SquashfsErrors (последним исправлял пользователь bump55 2010-07-23 10:40:22)

The material on this wiki is available under a free license, see Copyright / License for details
You can contribute to this wiki, see Wiki Guide for details

Источник

Arch Linux

You are not logged in.

#1 2020-06-16 19:32:35

SQUASHFS error :squashfs_read_data failed to read block 0x1311f16

I’m trying to install Arch in a VM right now. I’m pretty sure I did everything right. It’s not as hard as I thought after some aRch bTw users told me it’s the hardest thing to do. but I probably made a mistake anyway.

I’m using Grub and Hyper-V.

After rebooting I just see thousand of lines with the same error message (SQUASHFS error :squashfs_read_data failed to read block 0x1311f16) on my screen.

Also, somehow putting KEYMAP=de-latin1 in /etc/vconsole.conf doesn’t change anything. But that’s the smaller problem.

Thanks in advance for any help:)

#2 2020-06-16 22:36:04

Re: SQUASHFS error :squashfs_read_data failed to read block 0x1311f16

There are a few reasons this may happen but if your sure you did everything right I think its possible you might have faulty hardware. A bad stick of RAM can cause this error, does the host operating system work without issue and can you run memtest86+ to check your RAM? If you can run memtest86+ then at a minimum you can rule out bad hardware. Another possibility is an incorrectly setup boot loader.

Last edited by DeathStar (2020-06-16 22:39:28)

#3 2020-06-16 23:24:06

Re: SQUASHFS error :squashfs_read_data failed to read block 0x1311f16

I got kinda angry, wiped my windows installation and installed it on the bare metal. Now it’s working.

Last edited by hallowed (2020-06-16 23:24:45)

#4 2020-06-17 00:20:46

Re: SQUASHFS error :squashfs_read_data failed to read block 0x1311f16

Glad to hear it, Welcome to Arch Linux

Источник

Ошибка SQUASHFS: невозможно прочитать страницу, . размер

Я работаю со встроенной платформой ARM со встроенной флэш-памятью NAND. Мой раздел крыш сквош. И u-boot, и ядро ​​используют OMAP_ECC_BCH8_CODE_HW. Проблема в том, что некоторые платы (не только одна) перестали работать после отключения питания (они использовались около 2 месяцев).

Эти ошибки можно увидеть при загрузке:

Как мне отладить это? Я не стер вспышку, поэтому все еще можно провести некоторые тесты на ней.

Что я сделал до сих пор:

Я использовал nanddump (с -o, читать данные oob) на плохом разделе и заметил три предупреждения об исправлении ошибок ecc. Когда я записываю этот дамп на другую плату, он загружается без проблем.

Когда я использовал nanddump с дополнительной опцией -n (—noecc, Читать без исправления ошибок) и записал его на другую плату (используя nandwrite -n), вторая плата не смогла загрузиться.

Мне кажется, что эти ошибки можно исправить, и поэтому nanddump исправил их в первом случае. Я сравнил эти 2 дампа, и они представляют собой только три различия (3 поправки ecc, сообщенные nanddump?)

Вопрос в том, почему эти ошибки не были исправлены системой автоматически? Это потому, что squashfs не является файловой системой, ориентированной на mtd, и не должна использоваться на устройствах mtd? Если так, я должен использовать squashfs по UBI? Тогда как насчет ядра (насколько я знаю, это должен быть необработанный образ, чтобы загрузить его из u-boot)?

Источник

Linux Mint Forums

Welcome to the Linux Mint forums!

Workaround: SQUASHFS errors while installing LMDE from USB

Workaround: SQUASHFS errors while installing LMDE from USB

Post by j-a » Fri Jun 08, 2012 12:31 pm

Last night, after a 12 hour tinkering marathon, I finally managed to install LMDE 201204 on my ThinkPad X220 (i5-2520M). Lacking a DVD-Drive (and with my 1GB USB stick being too small for the LMDE ISO) I decided to use one of my microSD cards in combination with a USB-Adapter. I used Ubuntu’s ImageWriter to copy the ISO to the card and it took a few copies until the md5 consistency checks finally validated.

Booting the live system worked perfectly. The installation went smooth — until the last few percent (some kernel module files were copied) where it suddenly halted. dmesg revealed the infamous SQASHFS errors:

Memtest86+ showed no RAM-issues. I even tried several different microSD Cards — all with no success. So I took a closer look at the installer ( /usr/lib/live-installer/installer.py). What it basically does is create two mountpoints

• /source/, where /live/image/casper/filesystem.squashfs ist mounted, and
• /target/, where the freshly formatted root partition of the new system is mounted

and then copy all files (=the whole LMDE system) from /source/ to /target/.

To determine which files had not been copied yet, I diff’ed the two directories, which again led to many SQUASHFS errors. I unmounted /source/ and did a md5sum on filesystem.squashfs which promptly failed, although it had validated correctly right before the installation.

Although /live/image/casper/filesystem.squashfs is mounted with the readonly option, the mounting and/or reading of the volume somehow modifies the file, which leads to a corrupted filesystem. Maybe this is a strange recursion- and/or permission-related bug in squashfs which occurs when a mounted filesystem.squashfs tries to mount itself again and thus somehow gains write access. Or my microSD-USB adapter is crap. Oh well.

After verifying that

I’m glad I pulled through all the hassle. Everything feels so solid and responsive now. As a former Debian user it’s quite like coming home.

Источник

squashfs из iso loop

Собственно хочу понять как подхватывать вторичную фс при загрузке из iso, в качестве примера взят mageia2:

Где ISOIMAGE это метка тома ISO по умолчанию от grub2-mkrescue -o ../grub.iso .

Собственно, загрузчик этой конфигурацией подхватывается, но вылетает при попытке загрузиться с loopbacks/distrib-lzma.sqfs:

Что тут можно сделать ? Очень желательны и другие примеры 🙂

Многие пробовал, но Магейа не приходилось. Почему в качестве примера взял столь древнюю версию.

Очень желательны и другие примеры

Тут есть пара примеров. Только не вникал, рабочие или нет.

Попробую прокомментировать твой пример.

Первые две строки вообще не понятно зачем.

Откуда взялась переменная isofile. Обычно использую iso_path. Уже точно не помню, но кажется это внутренняя переменная груб. Если изменить имя, то возникают ошибки.

Следующая строка должна быть:

loopback loop0 $isofile

После этой строки:

Чтобы доалее уже не писать loop. Все имена начинаются с «/», например, «linux /boot/vmlinuz». Далее, две строки с «probe» тоже непонятно что делают.

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

Почему в качестве примера взял столь древнюю версию.

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

Первые две строки вообще не понятно зачем.

Да, без search можно было в данном контексте обойтись, но и навредить, насколько я понимаю, не может

Теперь я уже не понял назначение этой команды.

Проверить, исо-образ случайно не битый.

Нет, файл исправный: md5 в порядке, в qemu работает нормально. Да если бы дело было только в этой древности. Я решительно не понимаю механику того как подхватывать образ внутри loop. И, в частности, непонятно где брать опции загрузки ядра различающиеся от дистрибутива к дистрибутиву, и я не имею всякие там lang, vga, splash и.т.п, я имею ввиду именно опции на продолжение загрузки дистрибутива из файловых систем типа squashfs, спрятанных внутри iso-образа.

P.S: Спасибо за отзыв, хорошего вам вечера

не понимаю механику того как подхватывать образ внутри loop

Сам дистрибутив должен уметь загружаться из исо-образа. Собственно груб загружает только ядро и инитрд. Дальше уже скрипты из инитрд должны искать исо-образ. В разных дистрибутивах они действуют по разному. Для облегчения этого процесса придумали технологию loopback-bootable. Суть ее в том, что в файле loopback.cfg находится конфиг, для загрузки именно из исо-образа. Собственно груб запускается с конфигом loopback.cfg Иногда это просто символическая ссылка на grub.cfg. Посмотрел образ версии 7 — до loopback-bootable Mageia еще не доросла. А умеет-ли она вообще грузиться из исо-образа. Пока нигде не попадался ответ на этот вопрос.

где брать опции загрузки ядра различающиеся от дистрибутива к дистрибутиву

Поискать в интернете. Недавно разбирался с antiX. Быстро все нашлось и заработало. На магею пока не находится. Второй вариант. Распотрошить инитрд и поискать в нем.

Это принципиально, загрузка из исо-образа. А например, загрузка «из набора файлов» получилась?

В общем, ничего эта Mageia не могет.

Вот что нашлось. Пока получилось только загрузить версию 7 из «набора файлов», находящихся на разделе с файловой системой ext4. Реально файлы находятся в каталоге /opt/mageia. Для имитиации, что они находятся в корне, в корне были созданы симлинки boot, isolinux, loopbacks, указывающие на соответствующие каталоги. Первое впечатление от системы — отвратительно. Грузилась минут десять. Обычно загрузка сервисов проскакивает, что не успеваешь прочитать. Здесь неспеша выползают строчки, успеваю прочитать раза три. Версия 6 не запстилась, с той же ошибкой, что у тебя.

Что нашлось в инитрд 5 версии:

непонятно где брать опции загрузки ядра различающиеся от дистрибутива к дистрибутиву

Базово — нигде. Это не опции ядра, это опции для программ (в основном загрузочных скриптов), передающиеся через командную строку ядра и доступные через /proc/cmdline. Ядро игнорирует неизвестные опции, поэтому там может быть что угодно. Разработчики системы инициализации (initrd/initramfs скриптов) далеко не всегда документируют все возможности. Как уже написали, если очень хочется, изучайте что внутри initrd. Причём, может оказаться что в initrd использует какой-нибудь бинарник, для которого нет или не полная man-страница и нужно смотреть исходник.

Распаковал и просмотрел инитрд всех версий mageia.

О первой версии можно сказать только что она есть. Во второй появляется код «поиска живой сисстемы», но только на файловой системе iso9660. С третьей версии Магея может найти свою «живую систему» на файловой системе ФАТ. Но все имена файлов и каталогов жестко зашиты в скрипте. В практически неизменном состоянии доходит до шестой версии. Только в седьмой появляется возможность менять каталог. Но вроде бы нет никаких намеков на возможность загрузки из исо-файла.

Пример конфига груб2 для загрузки Mageia live.

Источник

Hi i find this if somebody has it again!

SquashFS Errors
Problem Statement
Some users have reported being unable to boot from the Ubuntu LiveCD, due to SquashFS errors like this:

SQUASHFS error: sb_bread failed reading block 0x9d7f3
SQUASHFS error: Unable to read fragment cache block [275faa28]
SQUASHFS error: Unable to read page, block 275faa28, size 23a7
Example 2:

[ 1228.553598] EXT3 FS on sda5, internal journal
[ 1228.553605] EXT3-fs: mounted filesystem with ordered data mode.
[ 1349.994012] SQUASHFS error: zlib_inflate returned unexpected result 0xfffffffd, srclength 131072, avail_in 352, avail_out 92175
[ 1349.994024] SQUASHFS error: sb_bread failed reading block 0x77162
[ 1349.994029] SQUASHFS error: Unable to read fragment cache block [1dc4df1a]
[ 1349.994035] SQUASHFS error: Unable to read page, block 1dc4df1a, size a972
Example error when loading Xubuntu with Wubi on first boot:

[ 81.364872] Btrfs loaded
[ 90.596351] Adding 261112k swap on /host/ubuntu/disks/swap.disk. Priority:-1 extents:1 across:261112k
[ 104.800436] EXT4-fs (loop2): mounted filesystem with ordered data mode
[ 288.909464] SQUASHFS error: zlib_inflate error, data probably corrupt
[ 288.909481] SQUASHFS error: squashfs_read_data failed to read block 0x11b3773e
[ 288.909490] SQUASHFS error: Unable to read data cache entry [11b3773e]
[ 288.909494] SQUASHFS error: Unable to read page, block 11b3773e, size 17512
[ 288.909531] SQUASHFS error: Unable to read data cache entry [11b3773e]
[ 288.909534] SQUASHFS error: Unable to read page, block 11b3773e, size 17512
[ 288.909557] SQUASHFS error: Unable to read data cache entry [11b3773e]
[ 288.909561] SQUASHFS error: Unable to read page, block 11b3773e, size 17512
[ 288.909574] SQUASHFS error: Unable to read data cache entry [11b3773e]
[ 288.909578] SQUASHFS error: Unable to read page, block 11b3773e, size 17512
[ 288.909591] SQUASHFS error: Unable to read data cache entry [11b3773e]
[ 288.909594] SQUASHFS error: Unable to read page, block 11b3773e, size 17512
[ 288.909609] SQUASHFS error: Unable to read data cache entry [11b3773e]
[ 288.909612] SQUASHFS error: Unable to read page, block 11b3773e, size 17512
[ 288.909626] SQUASHFS error: Unable to read data cache entry [11b3773e]
[ 288.909630] SQUASHFS error: Unable to read page, block 11b3773e, size 17512
[ 288.909644] SQUASHFS error: Unable to read data cache entry [11b3773e]
[ 288.909647] SQUASHFS error: Unable to read page, block 11b3773e, size 17512
[ 288.909664] SQUASHFS error: Unable to read data cache entry [11b3773e]
[ 288.909667] SQUASHFS error: Unable to read page, block 11b3773e, size 17512
Causes and Solutions
These errors can be due to a variety of reasons:

bad memory modules (solution: use memtest86+ to check your memory)
a bad dvd drive (solution: if possible, try using a different cd/dvd drive)
bad data cable (solution: change it for a new one)
bad media (solution: try burning the iso image to a new disc)
a corrupted iso image (solution: run an md5 checksum, and if they don't match, download the iso image again)
Temporary Workarounds
Some users have reported that adding the ide=nodma or acpi=off allowed them to work around this issue (which proved to be bad memory modules). You might want to give that a try

Successful boot was achieved by adding "all_generic_ide" to the grub boot line for the live CD. 

You can add those lines to the grub entry, either in the grub.conf file or either entering letter 'e' on the grub menu and after editing Control+x to boot:

Add to the grub line: 

all_generic_ide pci=nommconf
Add to the kernel line: 

ide=nodma acpi=off
More information about the problem in grub can be found here: https://bugs.launchpad.net/wubi/+bug/608941

If is not a HW problem and you can probe it
If you definitely found that is not a HW issue, add you comment with all the logs and evidence you can get to Launchpad bug #172937

Страницы: [1]   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1]   Вверх