SliTaz Forum
You are not logged in.
Pages: 1
Hi,
After update this morning, [c]tazusb writefs[/c] creates rootfs in 1 sec, 72K.
Downgrading busybox to 1.31.1 solved the issue.
Offline
Sorry, not better with the new build 
Offline
Tryed the last build (2025-10-07) tonight but unfortunately still the issue.
Offline
Ciao Ceel, tazusb non lo uso, comunque è uno script non dovrebbe essere difficile fare un debug.
Vedo che il log punta a LOG="/tmp/$(basename $0).log"
magari puoi trovare l'indizio dove va crash.
Diversamente puoi provare a ricompilare busybox partendo da quello funzionante, scopriresti se il difetto è generato dal cook o dalla versione di busybox.
---------------------------------------------------------------------------
Hi Ceel, I don't use tazusb, but it's a script, so it shouldn't be difficult to debug.
I see that the log points to LOG="/tmp/$(basename $0).log."
Maybe you can find a clue as to where it crashes.
Otherwise, you can try recompiling busybox starting from the working one. You'll find out if the defect is generated by the cook or by the busybox version.
Offline
Ciao gibor,
hai pobabilmente ragione ma il problema deve essere risolto anche sul mirror.
@dev
launching an update today creates a beautiful mess:
when installing packages (Database timestamp 10/08/25 10:20):
[c]Extracting package... unlzma: bad lzma header[/c]
after the update:[c]
tazpkg info <package_name>
/usr/lib/tazpkg/info: .: line16: can't open '/var/lib/tazpkg/installed/<package_name>/receipt': No such file or directory[/c]
and
[c]ls /var/lib/tazpkg/installed: No such file or directory[/c]
and so on. I didn't even try to create a rootfs.
I saw [c]busybox[/c] has been rebuilt this afternoon, and a mass rebuilding is in progress. Wouldn't it be possible to post a warning message on the forum in such situation?
EDIT
in [c]tazpkg.log[/c] the names of the updated packages are not mentioned; only
[c]YYYY-MM-DD HH:MN:SS - Installed - (944)[/c]
Offline
@Ceel
I never said it shouldn't be fixed on the mirror, just that if you don't instruct the cook properly, you'll never compile the right package...
However,
unlzma: bad lzma header
hints at a problem already known with the new lzma. If busybox has followed it in its evolution, I think it will be difficult to fix it.
I'll leave it at that, I don't want to disturb the experts!
--------------------------------------------------------------------------
@Ceel
mai detto che non debba essere risolto sul mirror, solo che se non istruisci il cook a dovere, non compilerai mai il pacchetto giusto...
Comunque
unlzma: bad lzma header
lascia intravedere un problema già conosciuto con i nuovi lzma. Se busybox l'ha seguito nell'evoluzione la vedo dura correggerlo.
Lascio il passo, non voglio disturbare gli addetti ai lavori!
Offline
Hi Ceel, gibor,
I doing test yesterday with cooking september iso, around 9pm after go back from work and see your message.
Packages not all upgraded due of [c]unlzma: bad lzma header[/c] (if remind tazpkg, busybox and other), only few packages installed as expected (expat, openssl, libcrypto, ...).
If try [c]tazpkg up -r[/c], purpose again to upgrade all packages, after investigation seem busybox, tazpkg have wrong size on mirror compared to cook.slitaz.org, seem that fixed after 11pm yesterday by bellard.
I'm sorry for this, not sure that what happen, maybe wrong build or issue during rsync process.
Seem not break system (i hope), we really need to improve process to avoid this.
@Ceel, i test [c]tazusb writefs[/c] with new busybox, seem ok now.
Offline
Ciao gibor,
mai detto che non debba essere risolto sul mirror
Scusa. Non è quello che volevo dire. Volevo dire che era importante di risolvere questo problema sul mirror prima che troppo utenti abbiano rotto il loro sistema.
Ma come dici, lasciamo fare gli esperti.
=====================================
I never said it shouldn't be fixed on the mirror
Sorry gibor. That's not what I meant. I meant that it was important the problem was fixed on the mirror before too many users have broken their system.
and like you say, let's the experts do.
Hi shann,
Don't be sorry. Only those that don't work never do "errors".
And maybe I should use [c]mirror[/c] rather than [c]mirror1[/c]?
Offline
Seems all is in order now.
Thanks!
Offline
hmm, no. Still not perfect.
Yesterday night, I updated a rootfs (last update was 02/10) and all went right.
This morning, I tryed to update another rootfs very similar (last update: 28/09) and as soon as [c]busybox[/c] is updated no other package can be updated:
[c]md5sum: can't open 'pkgname-ver.tazpkg': No such file or directory
checksum error for "pkgname-ver.tazpkg"
rm: can't remove 'pkgname-ver.tazpkg': No such file or directory[/c]
Re-installing busybox v1.31.1 and blocking the package, [c]tazpkg up[/c] works normally.
Weird, don't really understand what happens.
Offline
Hi Ceel,
Sad to read, if understand you still have issue when you updated your rootfs 
.
I have iso of Sep 7th, i check it, installed on disk and do [c]tazpkg up -r[/c] seem ok.
Strange that i don't have same issue, but you report seem indicate busybox 1.37.0 need improve to avoid tazpkg issue.
Offline
Hi Ceel,
Concerning issue about md5sum ..., i have same at moment.
Think related to tank have sometime 504 due of overload on lighttpd requests .
In case not related to busybox 1.37
Cook: xorgproto 2021.5
===============================================================================================================
QA: checking package receipt...
Checking build dependencies...
md5sum: can't open 'git-2.39.4-x86_64.tazpkg': No such file or directory
Checksum error for "git-2.39.4-x86_64.tazpkg"
rm: can't remove 'git-2.39.4-x86_64.tazpkg': No such file or directory
I temporary block access to cook.slitaz.org (hg.slitaz.org always ok) due of bad crawl.
Really need to found way for block bot on cook.slitaz.org
Offline
I got it! The culprit was [c]cacerts[/c]
Forgot to mention in my previous post that immediately after busybox v1.37.0 was installed, [c]tazpkg[/c] didn't success to connect to the mirror:
Recharging repository "Main"
=========================================================
Checking... [ Failed ]
Creating backup of the last packages list... [ Done ]
Getting "bundle.tar.lzma"... [ Failed ]
Restoring database files... [ Done ]
=========================================================
Recharging failed
The strange thing was that the rootfs that works fine was built from the one that didn't accept busybox v1.37.0. The story:
The initial rootfs was: xorg-server + slim + cwm + xterm + nnn; I wanted to give a try at the cwm window manager.
When I became a few familiar with it, I installed some apps and saved this in a new rootfs.
Having a look at [c]tazpkg.log[/c] files of each rootfs, the notable difference was [c]cacerts[/c] inslalled for the web browser.
Finally, the culprit is... me 
Maybe [c]cacerts[/c] should be added at [c]DEPENDS[/c] in the [c]busybox[/c] and/or [c]tazpkg[/c] receipts?
Concerning error 504, yes, I noticed it for a few weeks, even sometimes to access to the forum
Offline
No problem, infact you are right, good idea to add cacerts as depends for busybox or tazpkg.
I forgot to ask you if you have cacerts installed, infact same issue for me when i create new chroot env, sometime forgot to add cacerts on chroot, and tazpkg recharge told me that failed to connect on mirror https ^^.
At 2026 january contract engagment ended for servers, i plan to move before christmas to others server and reduce cost infrastructure by twice. At least november or december to avoid pay huge costs.
I think also maybe split forum, mercurial to avoid impact when massive requests, but maybe in other time after migration.
Offline
Pages: 1
[ Generated in 0.019 seconds, 7 queries executed - Memory usage: 1.57 MiB (Peak: 1.77 MiB) ]