- Печать
Страницы: [1] Вниз
Тема: ZSID-compressed data is corrupt — System halted_ (Прочитано 965 раз)
0 Пользователей и 1 Гость просматривают эту тему.
rfk62jpizm
Здравствуйте. При попытке установить Ubuntu 22.04 LTS с флешки получаю ошибку ZSID-compressed data is corrupt
— System halted_ . В чем причина возникновения данной ошибки и как ее решить?
БТР
Проверьте контрольные суммы загруженного образа и записанных на флешку файлов. Проверьте оперативную память ( memtest ).
rfk62jpizm
Проверьте контрольные суммы загруженного образа и записанных на флешку файлов. Проверьте оперативную память ( memtest ).
Образ качал с официального сайта, записывал программой Rufus (тоже качал с оф сайта). Память рабочая 100%. Может есть мануал какой или документация где описана прична возникновения данной ошибки?
Skif_off
Беглый поиск намекает на память. У кого-то автоопределение параметров срабатывало неправильно, решением оказалось просто зайти в BIOS, ничего не трогая нажать кнопку сохранения параметров, выйти и — порядок.
Она не в разгоне? (Для тех же AMD Ryzen, например, видел рекомендацию поднять частоту.) Не крутили тайминги? Как вариант — проверить, как определяются параметры оперативки, и если не стоит что-то типа «by SPD», то попробовать переключить. Или сбросить настройки. Или на некоторых платах у Asus есть кнопка MemOK.
P.S. Исправьте ZSID на ZSTD, и тему будет проще найти.
« Последнее редактирование: 17 Августа 2022, 20:56:17 от Skif_off »
jimbo1991
Сумма sha256 у меня не сходится. С флешки записал образ и залил на файлообменник https://dropmefiles.com/0YcXS Может кто поковырять образ и выяснить что с ним случилось?
andytux
Ты меня конечно не слушай, в жизни никогда не проверял ни одной суммы-хеша.
Впрочем вру. Проверял, когда загружал программы с компакт-кассеты.
Если исо-образ качал торрентом, то он проверяет правильность образа. Если сомнения, то в торрент-клиенте запусти верификацию.
Запустить из исо-образа можно и без записи на флешку. А если образ записал на флешку командой dd, то это уже не имеет никакого отношения к образу.
Так что, разберись сначала сам, что, куда, как, зачем и почему…
F12
Ты меня конечно не слушай…
— ну одно дело проверять хеш ISO-образ после скачивания, и совсем другое содержимое загруженного образа и записанных на флешку файлов, что собственно и предложил БТР, в Ответ #1
… тоже не часто случается делать такие проверки, пришлось рыться в своих заметках, и таки нашел, заметка датирована 2006 годом и ссылается на 1-й коммент к статье Verify a burned CD/DVD image on Linux, как на первоисточник.
Суть проверки в следующем, команда diff сравнивает содержимое примонтированного ISO-образа хранящегося на диске, с содержимым записанным на внешний носитель, будь то CD, DVD или флешка, или другое устройство
diff -urN /ondisk /dvdВ процессе выполнения команда будет выдавать в выхлоп файлы отличающиеся по содержимому, если ничего не выдаст, значит не совпадающих файлов не обнаружено, следовательно все было записано правильно и без ошибок.
ЗЫЖ хоть и давно пользовался, но помню вроде работало нормально… а вот сейчас смотрю свою же заметку и вижу примечание, что проверка не всегда проходит до конца, иногда неожиданно завершается с сообщением: «каталоги зациклены»…
ЗЗЫЖ в общем кому интересно, пробуйте 
- Печать
Страницы: [1] Вверх
-
Neranus
- Posts: 1
- Joined: 2019-02-03 12:43
Debian boot error — XZ compressed data is corrupt
#1
Post
by Neranus » 2019-02-03 13:20
Hello,
I do use Debian 9 for about one month, but know I can’t boot over Linux, if I try to I got an error-alert «Xz-compressed data is corrupt —System halted». I do even have an Windows 10 at the same hard drive and I can boot over windows without any problems.
My processor is an Intel(R) Core(TM)2 CPU 6320 @ 1.86GHz
x64-based processor
Does anyone know, why this happens and -eventually- how to fix it?
Thanks
Neranus
P.s. I’m sorry for any grammar mistakes, because english is not my first language
-
Head_on_a_Stick
- Posts: 13994
- Joined: 2014-06-01 17:46
- Location: /dev/chair
- Has thanked: 53 times
- Been thanked: 80 times
Re: Debian boot error — XZ compressed data is corrupt
#2
Post
by Head_on_a_Stick » 2019-02-03 14:25
Bad RAM, perhaps?
I can’t remember if memtest is included in the Debian ISO image boot options, try starting it in non-UEFI mode (it won’t work otherwise).
I searched the error message on your behalf (you’re welcome) and one thread stated that re-seating the CPU removed the error.
Many other suggestions available from your favorite search engine 
Il semble que la perfection soit atteinte non quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retrancher.
-
ggbce
- Posts: 1
- Joined: 2019-12-24 15:17
Re: Debian boot error — XZ compressed data is corrupt
#3
Post
by ggbce » 2019-12-24 15:28
Hi,
Many people return a problem about RAM when «XZ-Compressed data is corrupt» and like Neranus I can confirm in our case it’s nor linked to RAM issue. In his case, he have a dual boot machine with Windows where no problem with RAM… In my case, my Debian 10 (32-bit) machine is a VM in Oracle Virtualbox.
I tried to export my machine to another host and the issue is the same.
Then,
How to fix a corrupted machine that want to boot, then return this error:
Code: Select all
XZ-Compressed data is corrupt
-- System haltedwithout reinstalling from scratch. I have a big webserver on my VM that could need a lot of work to reinstall… This server is running since many years starting on Debian 5 upgraded to Debian 6, 7, 8, 9 and 10 since 6 mothns without problem… !!!
It probably exist a method to run a LiveCD to fix startup ?
[SOLVED] -Update to 8.1.0 on Generic Failed — «XZ-compressed data is corrupt — system halted»
I have an Acer Revo3700 (ION2) HTPC. I have tried to upgrade from 8.0.2 (which runs perfectly) to 8.1.0 and have been unsuccessful. The update starts and completes as normal and the system reboots. On reboot I get an onscreen message stating: «XZ-compressed data is corrupt — system halted» and the system has frozen. As a result I created a USB stick with 8.1.0 to try a fresh install however I got the same error message after booting from USB. I was unable to even start the install process.
As I have been unable to install 8.1.0 I did a fresh install of 8.0.2 using a USB stick and that installed as expected. I also then as a final check tried to update to 8.1.0 from within this fresh install and that also appeared to complete successfully but I was left with the error message screen as described above after reboot.
Any help would be greatly appreciated.
- Official Post
One of the project staff has a Revo3700 and has tested it with the official 8.1.0 image without issues. We can’t think why you’re seeing messages about decompressing an XZ kernel because the official Generic image uses gzip compression. Our current guess is you’re not using an official image?
Thanks for your reply.
The images I have used have all come from the libreelec.tv website. Could it be a problem with mirror I have used? I am in the UK.
Last night I also tried updating to 8.1.0 from within Libreelec and again that seemed to install fine, rebooted and then resulted in the same error. (again I was able to reinstall 8.0.2 from USB afterwards with no issues)
It does seem very strange. Tonight I will have a look in the Bios settings and check everything is ok.
Any futher thoughts would be greatly appreciated.
Thought I would update on a few things I tried tonight.
Upgrade from 8.0.2 to a Milhouse Leia build 0815 and same problem.
I also created a new USB stick with 8.1.0 and the installer won’t start. The same message appears.
I suspect it could be some kind of kernel issue? Could there be some reason why the kernel is not compatible with my Revo3700?
Does the USB installer app format the hard drive (suspect not)? Would it be worth a complete reformat?
- Official Post
Formatting won’t achieve anything. I’m told we compress the kernel with xz (and overall squashfs with gzip) but we can’t think up a scenario where this problem could occur. Milhouse (btw) is the staff member with a Revo3700. He reports no problems with his Leia images.
I’ve installed 8.0.2 on my Revo3700 and upgraded to 8.1.0 without any problem (using both img.gz and .tar for the upgrade).
I also regularly deploy my test builds (.tar) to my Revo 3700, again without any issue.
Have you installed 8.0.2 to the internal hard disk of the Revo 3700? It all sounds like you’re somehow booting from the wrong media, possibly a BIOS issue?
Yes. 8.02 installs to the internal hard disk perfectly. The bios is set to boot from the internal hard drive first so I have to access the boot menu to boot from USB. It seems as if the new kernel on 8.1 will not unzip whether it is on a USB stick or installed on the internal hard drive(after I have updated from 8.0.2) When the installer starts from USB where does it try to extract the kernel to? USB or internal hard drive?
I have used my Revo running Openelec/Libreelec for years with regular updates to beta and RC releases and never had an issue.
Have you upgraded any part of your Revo? Are you still using the original HDD? Could this be a hardware issue with the HDD?
I had a look at the bios and I couldn’t see anything that looks out of the ordinary. Would you have any suggestions?
I’m trying to boot from a minimal Live CD (install-amd64-minimal-20140327.iso), and I’m getting XZ Compressed data is corrupt errors. The checksum for the ISO seems to be correct, and the CD will boot on a different machine, but on the machine I need to install, I get these errors at the «Loading gentoo.igz» stage (either that, or it hangs here with no errors).
- ASRock M3A785GMH/128M (Socket AM3)
- AMD Phenom II X4 910e Quad-Core / 4x 2.50GHz / 8MB cache / Socket AM3 / 65W
- NVIDIA GT 240 / 512MB GDDR3 / PCI-E x16 / DVI
Any ideas what options to try, or what could be wrong?
Previous to that, I tried CD written from a different machine got about half way through the process, and then failed with r/w error, so there does seem to be a CD drive issue.
Thanks for the suggestions.
## Booting kernel from Legacy Image at 02000000 .
Image Name: gm828x
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1995272 Bytes = 1.9 MiB
Load Address: 02000000
Entry Point: 02000040
Verifying Checksum . OK
XIP Kernel Image . OK
OK
: mem=256M gmmem=190M console=ttyS0,115200 user_debug=31 init=/linuxrc root=/dev/mtdblock3 rootfstype=squashfs
XZ-compressed data is corrupt
Copyright 2001-2022 Gentoo Foundation, Inc. Designed by Kyle Manna © 2003; Style derived from original subSilver theme. | Hosting by Gossamer Threads Inc. © | Powered by phpBB 2.0.23-gentoo-p11 © 2001, 2002 phpBB Group
Privacy Policy
Linux Mint Forums
Update: unfortunately, something must be wrong with the pen drive I used. I dd’ed the iso to an old 2GB drive I have and it booted correctly.
Bummer, because I bought this 16GB USB drive little time ago for the exact purpose of creating a persistent live x64 Cinnamon Betsy system. I’m sure the drive works correctly, does anyone have any advice on how to proceed? (tests to perform to know the causes, etc.)
Re: xz-compressed data is corrupt
Post by kevinthefixer » Sat Sep 12, 2015 11:21 am
Re: xz-compressed data is corrupt
Post by HisDudeness » Sat Sep 12, 2015 11:30 am
I write a new table every time I am to flash a distro on it, as dd screws the table up.
Right now I’m badblocking, but it looks like it’s gonna take a while. Then, I’ll f3, which I did right after buying it to check if it really was 16GB.
Re: xz-compressed data is corrupt
Post by HisDudeness » Sun Sep 13, 2015 6:45 am
Bad blocks gave me practically 100% of blocks corrupted using the first pattern, and zero using the others. how’s that even possible?
I mean, it als gives the progress 0/0/0. As it tested with 0xaa pattern the last digit continued increasing almost together with the number of tested blocks, while the others stayed 0 even with the other patterns. Testing 0x55, 0xff and 0x00 gave no result in terms of bad blocks.
The output is 123 MB big and gives sector 15667263 as last one, in line 15667200. 63 non bad blocks in 16 GB?
| View previous topic :: View next topic | |||||
| Author | Message | ||||
|---|---|---|---|---|---|
| samuel.penn Tux’s lil’ helper  
Joined: 14 Dec 2003 |
|
||||
| Back to top |
|
||||
 |
|||||
| Ant P. Watchman 
Joined: 18 Apr 2009 |
|
||||
| Back to top |
|
||||
|
|||||
| vaxbrat l33t  
Joined: 05 Oct 2005 |
|
||||
| Back to top |
|
||||
|
|||||
| toralf Developer  
Joined: 01 Feb 2004 |
|
||||
| Back to top |
|
||||
|
|||||
| samuel.penn Tux’s lil’ helper
Joined: 14 Dec 2003 |
|
||||
| Back to top |
|
||||
|
|||||
| mcizhy n00b 
Joined: 28 Sep 2014 |
|
||||
| Back to top |
|
||||
|
|||||
|
|
You cannot post new topics in this forum |
Добрый день! Уважаемые читатели и гости крупнейшего IT блога России pyatilistnik.org. В сегодняшней заметке, хочу описать ситуацию со стареньким оборудованием Dell PowerEdge 1950. Есть сервер на котором установлена FreeBSD. Была необходимость выполнить сервисное обслуживание операционной системы. Был выключен Dell PowerEdge 1950. Далее после включения, сервер не обнаружил один из виртуальных массивов, после чего выдавал сообщение system halted и не давал далее загружаться. Вот такая вот ситуация, давайте я расскажу, как удалось его воскресить.
Проблема с RAID контроллером PERC 6/i
В моей организации идет процесс вывода из строя старого оборудования, которое много тратит электроэнергии, а толку дает мало. Одним из таких серверов был Dell PowerEdge 1950. Моему коллеги нужно было выполнить на нем работы и перезагрузить его. После перезагрузки выскочили вот такие предупреждения:
Обратите внимание, что сервер Dell не видит один из виртуальный дисков VDs, за номером 2, я выделил это стрелкой.
Далее видно, что найдены 3 Virtual Drive и происходит попытка загрузки сетевой настройки IDRAC, а после него формулировка:
После чего сервер так висит долгое время, загрузка с дисков или загрузка BIOS не осуществляется.
Как решается проблема
ИЗ информации описанной выше мы видим две проблемы:
В системе он вообще не виделся, и RAID контроллер на него не ругался, просто как будто нет. SMART показатели других дисков были в порядке. Я присмотрелся к индикации HDD на сервере и обнаружил, что один из них моргал, это был как раз 02-ой.
У меня был выведенный брат близнец этого сервера, и я решил поменять диски с проблемного диска, вставив их в другой выключенный сервер, с таким же RAID контроллером
После включения нового сервера с дисками от старого у меня обнаружилась старая конфигурация всех 4-х массивов.
Тут важный момент, новый RAID контроллер нашел конфигурацию, о старых виртуальных массивах (Virtual Drives), которую предлагает себе импортировать, соглашаемся и нажимаем кнопку «F»
После чего система стала загружаться и я больше не увидел сообщения «system halted». В очередной раз убедился, что всегда нужно иметь все про запас, это хорошо, что сервис сам продублирован и еще не успели убрать на склад старый сервер, который пригодился так кстати.
Источник
-
#1
I am in the progress of migrating my LXCs and VMs from Proxmox VE 5.3-6 to 6.4-4. All the backups of LXCs transferred and restored works correctly as expected; however, my only VM transferred and restored didn’t work as expected. The backup restore succeeds successfully, but upon booting it, I keep getting the same following error:
Code:
Loading ../vmlinuz-4.14-138-rancher...ok
Loading ../initrd-v1.5.6...ok
XZ-compressed data is corrupt
-- System haltedI backup the VM twice while it is turned off via GUI and restore it multiple time from the two backups, but the result is the same. I am wondering if it has to do with how RancherOS is setup, but considering the backup works in Proxmox, it should be a straight forward process. It doesn’t make sense why I am getting this strange error.
-
#2
Can you post your VM config after restore? (‘qm config <vmid>’)
-
#3
Here is VM config after the backup restore, readjusting more memory, and adding a CD-ROM:
Code:
root@pandora:~# qm config 202
boot: order=scsi0;scsi1;net0;net1;net2;net3
cores: 2
memory: 3072
name: Rancher
net0: virtio=1E:92:E5:91:08:60,bridge=vmbr2
net1: virtio=E2:0B:2D:01:16:21,bridge=vmbr3
net2: virtio=CE:4A:FE:98:86:18,bridge=vmbr4
net3: virtio=42:AF:D5:EA:AE:51,bridge=vmbr5
numa: 0
onboot: 1
ostype: l26
scsi0: local-lvm:vm-202-disk-0,size=10G
scsi1: local:iso/rancheros-autoformat_1_.iso,media=cdrom,size=153M
scsihw: virtio-scsi-pci
smbios1: uuid=e28216c7-8a89-45d9-b338-6e3c8878cade
sockets: 1
startup: up=60
vmgenid: 70470d52-22d4-4fd2-a1a3-1783386cb722Here is VM config before the migration:
Code:
root@Pandora:~# qm config 202
bootdisk: scsi0
cores: 2
memory: 2048
name: Rancher
net0: virtio=1E:92:E5:91:08:60,bridge=vmbr2
net1: virtio=E2:0B:2D:01:16:21,bridge=vmbr3
net2: virtio=CE:4A:FE:98:86:18,bridge=vmbr4
net3: virtio=42:AF:D5:EA:AE:51,bridge=vmbr5
numa: 0
onboot: 1
ostype: l26
scsi0: local-lvm:vm-202-disk-0,size=10G
scsihw: virtio-scsi-pci
smbios1: uuid=e28216c7-8a89-45d9-b338-6e3c8878cade
sockets: 1
startup: up=60
vmgenid: 38ef1fb9-922e-46ca-9127-fa471da1ce5aYou can see that it is almost the same as before the migration except the part where I added the CDROM and have the system booted from it. Given that it is a system docker, I found that I am able to get everything to work correctly as expected if I booted from the CDROM as its system docker substitute instead of booting it directly from the disk drive. Thus, I suspected that maybe there is something different between the two Proxmox versions causing this strange behavior.
Last edited: Aug 4, 2021
-
#4
Hm, you could try booting from a live restore image and checking the original drive from that, just to see if all the data is in fact correctly restored.
Also, compare the checksums (sha1sum /dev/mapper/pve-vm--202--disk--0) of the two disks before and after restore, if they differ, use something like ‘vbindiff’ to see where. The ‘XZ-compressed data is corrupt’ message would indicate that the BIOS and QEMU startup paths executed successfully, and the error only occured during loading of the actual image from disk.
-
#5
Yeah, I checked the checksum of the disk on the old Proxmox server before the restore and of the disk on the new Proxmox server after restore, and it doesn’t match up.
Code:
root@Pandora:/dev/pve# echo --n vm-202-disk-0 | md5sum
06d05d82b8d1a09433d6721cc1ac79f6 -
root@pandora:/dev/pve# echo --n vm-202-disk-0 | md5sum
c93da46e6642afc91c68fbc59776221c -Since I don’t remember how I setup that VM in the past and booting it up from a boot disk works fine, I am going to move on and keep it as is. It is taking too long to troubleshoot this issue. Thanks.
-
HisDudeness
xz-compressed data is corrupt
Hi everyone! I downloaded the latest iso via torrent, and I write it on my usb drive with this command
Code: Select all
sudo dd if=lmde-2-201503-cinnamon-64bit.iso of=/dev/sdc bs=4M && syncBut, booting from it, I get this error:
XZ-compressed data is corrupt
– System halted
Can anyone help me on this? Which informations do you need?
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
-
HisDudeness
Re: xz-compressed data is corrupt
Post
by HisDudeness » Sat Sep 12, 2015 7:12 am
Update: unfortunately, something must be wrong with the pen drive I used. I dd’ed the iso to an old 2GB drive I have and it booted correctly.
Bummer, because I bought this 16GB USB drive little time ago for the exact purpose of creating a persistent live x64 Cinnamon Betsy system. I’m sure the drive works correctly, does anyone have any advice on how to proceed? (tests to perform to know the causes, etc.)
-
HisDudeness
Re: xz-compressed data is corrupt
Post
by HisDudeness » Sat Sep 12, 2015 11:30 am
I write a new table every time I am to flash a distro on it, as dd screws the table up.
Right now I’m badblocking, but it looks like it’s gonna take a while. Then, I’ll f3, which I did right after buying it to check if it really was 16GB.
-
HisDudeness
Re: xz-compressed data is corrupt
Post
by HisDudeness » Sun Sep 13, 2015 6:45 am
Code: Select all
sudo badblocks -w -s -o usbstick.log -v /dev/sdcBad blocks gave me practically 100% of blocks corrupted using the first pattern, and zero using the others… how’s that even possible?
I mean, it als gives the progress 0/0/0. As it tested with 0xaa pattern the last digit continued increasing almost together with the number of tested blocks, while the others stayed 0 even with the other patterns. Testing 0x55, 0xff and 0x00 gave no result in terms of bad blocks.
Pass completed, 15667200 bad blocks found. (0/0/15667200 errors)
The output is 123 MB big and gives sector 15667263 as last one, in line 15667200. 63 non bad blocks in 16 GB?
Stupid question: badblocks is to run in a drive with a filesystem?
-
kevinthefixer
- Level 4
- Posts: 280
- Joined: Thu Jul 23, 2015 10:36 pm
Re: xz-compressed data is corrupt
Post
by kevinthefixer » Sun Sep 13, 2015 5:01 pm
Sorry I don’t know a thing about badblocks. This from man badblocks:
Code: Select all
Important note: If the output of badblocks is going to be fed to the
e2fsck or mke2fs programs, it is important that the block size is prop‐
erly specified, since the block numbers which are generated are very
dependent on the block size in use by the filesystem. For this reason,
it is strongly recommended that users not run badblocks directly, but
rather use the -c option of the e2fsck and mke2fs programs.Given the tools at hand, I would format the stick ext2 with mke2fs using the -c option.
-
ceekdp -
Aug 16th 2017 -
Thread is Unresolved
-
- #1
Hi all,
I have an Acer Revo3700 (ION2) HTPC. I have tried to upgrade from 8.0.2 (which runs perfectly) to 8.1.0 and have been unsuccessful. The update starts and completes as normal and the system reboots. On reboot I get an onscreen message stating: «XZ-compressed data is corrupt — system halted» and the system has frozen. As a result I created a USB stick with 8.1.0 to try a fresh install however I got the same error message after booting from USB. I was unable to even start the install process.
As I have been unable to install 8.1.0 I did a fresh install of 8.0.2 using a USB stick and that installed as expected. I also then as a final check tried to update to 8.1.0 from within this fresh install and that also appeared to complete successfully but I was left with the error message screen as described above after reboot.
Any help would be greatly appreciated.
Kind Regards.
ceekdp.
-
- Official Post
- #2
One of the project staff has a Revo3700 and has tested it with the official 8.1.0 image without issues. We can’t think why you’re seeing messages about decompressing an XZ kernel because the official Generic image uses gzip compression. Our current guess is you’re not using an official image?
-
- #3
Hi chewitt,
Thanks for your reply.
The images I have used have all come from the libreelec.tv website. Could it be a problem with mirror I have used? I am in the UK.
Last night I also tried updating to 8.1.0 from within Libreelec and again that seemed to install fine, rebooted and then resulted in the same error. (again I was able to reinstall 8.0.2 from USB afterwards with no issues)
It does seem very strange. Tonight I will have a look in the Bios settings and check everything is ok.
Any futher thoughts would be greatly appreciated.
Kind Regards,
ceekdp
-
- #4
Thought I would update on a few things I tried tonight.
Upgrade from 8.0.2 to a Milhouse Leia build 0815 and same problem.
I also created a new USB stick with 8.1.0 and the installer won’t start. The same message appears.
I suspect it could be some kind of kernel issue? Could there be some reason why the kernel is not compatible with my Revo3700?
Does the USB installer app format the hard drive (suspect not)? Would it be worth a complete reformat?
Kind Regards,
ceekdp
-
- Official Post
- #5
Formatting won’t achieve anything. I’m told we compress the kernel with xz (and overall squashfs with gzip) but we can’t think up a scenario where this problem could occur. Milhouse (btw) is the staff member with a Revo3700. He reports no problems with his Leia images.
-
- #6
I’ve installed 8.0.2 on my Revo3700 and upgraded to 8.1.0 without any problem (using both img.gz and .tar for the upgrade).
I also regularly deploy my test builds (.tar) to my Revo 3700, again without any issue.
Have you installed 8.0.2 to the internal hard disk of the Revo 3700? It all sounds like you’re somehow booting from the wrong media, possibly a BIOS issue?
-
- #7
Yes. 8.02 installs to the internal hard disk perfectly. The bios is set to boot from the internal hard drive first so I have to access the boot menu to boot from USB. It seems as if the new kernel on 8.1 will not unzip whether it is on a USB stick or installed on the internal hard drive(after I have updated from 8.0.2) When the installer starts from USB where does it try to extract the kernel to? USB or internal hard drive?
I have used my Revo running Openelec/Libreelec for years with regular updates to beta and RC releases and never had an issue.
Have you upgraded any part of your Revo? Are you still using the original HDD? Could this be a hardware issue with the HDD?
I had a look at the bios and I couldn’t see anything that looks out of the ordinary. Would you have any suggestions?
Thanks again for looking into this for me. It is much appreciated.
Kind Regards,
ceekdp
-
- #8
When the installer starts from USB where does it try to extract the kernel to? USB or internal hard drive?
Neither, the compressed kernel is booting in RAM (read from the USB). You should be able to boot the USB without a hard drive being attached.
Have you upgraded any part of your Revo? Are you still using the original HDD? Could this be a hardware issue with the HDD?
No upgrades, it’s still got a 250GB HDD. Haven’t made any changes to it in the 7 or 8 years I’ve had it.
I had a look at the bios and I couldn’t see anything that looks out of the ordinary. Would you have any suggestions?
Thanks again for looking into this for me. It is much appreciated.
Kind Regards,
ceekdp
Display More
I’d need to look at my BIOS, but if 8.0.2 installs normally then in theory 8.1.0 should too. Can you try a different USB memory stick, it’s _very_ unusual for the USB to not boot — either the KERNEL file is corrupt or the USB memory stick is corrupt.
When you are upgrading, you are dropping the new tar file into the Update Samba share and rebooting? You’re not extracting the contents of the tar manually (which you no longer need to do).
I’ll also write the 8.1.0 img to a USB and try booting the installer in my Revo3700.
-
- #9
The 8.1.0 installer booted without a problem from a cheap old USB memory stick. At the moment, other than corruption/hardware failure, I’m not sure what else to suggest. Maybe run memtest86+ to test your RAM?
Edit: Just to add I used the «LibreELEC USB-SD Creator» (Windows, 64-bit) application to create USB memory stick. Don’t write the 8.1.0 img.gz file directly to the USB memory stick (as that won’t result in a bootable memory stick) — it needs to be uncompressed to .img, and then the .img written to the memory stick (the «USB-SD Creator» application handles all of this automatically). You probably know all of this already as you have a working 8.0.2 system but just in case… we’ve all done it.
-
- #10
Problem solved! — It turned out to be a faulty RAM module. I have now updated 8.02 to 8.1 with no issue.
As suggested I ran memtest86+ and it noted that there were errors. I then changed the RAM with some spare I had from an old laptop and ran the update from within 8.0.2 and hey presto! It looks like the Revo3700 has some life left in it after all
Thanks so much for your help guys! You create amazing software and I’m grateful you take the time to help users out to solve our problems.
Kind Regards,
ceekdp
-
- #11
Thanks for confirming the fault — that’s a bit of a relief!