SliTaz Forum
You are not logged in.
Bonjour Shann,
testé mhwav... avec le contournement introduit dans /etc/init.d/bootopts.sh
Malheureusement, ça ne fonctionne pas chez moi, même après avoir relancé la session tux.
Ma machine (?) attend un chemin absolu comme valeur de tempDir1 (par exemple, masque du type /tmp/.mhwaveedit).
Dès que le tempDir1 est défini de cette manière (càd sans variable dans le path), je n'ai plus de message d'erreur et le décodage ainsi que l'affichage de l'empreinte audio s'exécutent avec succès.
Il est possible que je fasse incorrectement qq chose, mais pour l'instant je ne vois pas :-/
Car, si chez toi, ça fonctionne normalement, c'est ici qu'il y a un "problème".
Place aux fêtes de fin d'année, à l'accueil du Père Noël et à la nouvelle année.
Youpiiiiiiiiiiiiiiii :-)
Amitiés.
Offline
Salut Rantanplan,
En effet le fix que j'ai fait est pour la partie liveCD.
J'ai mis à jour mhwaveedit pour gérer en post_install le fix.
Si boot live, on fix le path dans /etc/init.d/bootopts.sh
Pendant l'install sur disque, on fix le path lors de la création du compte
Si install déjà faite, on fix le path en post_install (grace a la mise à jour)
Pour le moment je n'ai pas mis à jour le fix sur le rolling, je veux m'assurer que le comportement fonctionne comme attendu.
Rebuild des isos core, core-pae et core64 en cours.
Offline
Shann,
merci.
Je mets à jour, relance session tux et teste à nouveau.
EDIT : Testé et pour moi c'est OK, merci encore.
J'ai essayé la commande [c]rmdir --ignore-fail-on-non-empty /home/tux/[mon_rep][/c]
mais le répertoire n'a pas été détruit, pourquoi ?
Merci.
Amitiés.
Offline
Shann,
chargé dernière ISO pour 32 bits : boot liveUSB OK
mhWaveEdit : OK, fichiers .mp3 et .ogg décodés et affichés dans l'interface.
Cependant, je vois qu'il est toujours dans les mises à jour après rechargement de la liste.
Faut-il néanmoins appliquer cette mise à jour ?
J'ai voulu tester "Outils système / Configuration de SliTaz / set-date".
Sur ma machine, ça semble inopérant "Old date"="New date" (connexion wifi établie).
La date de départ était en 2005, c'est peut-être la raison de l'échec ?
Pour le reste, tout se lance. Mais, je ne peux pas toujours tester le bon fonctionnement.
Bonne soirée.
Amitiés.
Offline
Merci pour le retour.
Hmm étrange pour mhwaveedit, quand j'ai fait mon test, aucunes nouvelle maj proposé.
j'ai refais un test pour être sûr, qemu avec current-core.iso, pas de maj proposé après le rechargement et test avec current-core-pae.iso sur mon eeepc, idem tazpkg up -r pas de maj.
Normalement set-date permet d'ajuster l'heure via ntp (donc avoir internet)
Offline
Bonjour Shann,
set-time
extrait de slitaz-config :
[c]rdate -s tick.greyware.com 2>/dev/null[/c]
Retour de la commande en console
tux@slitaz:~$ sudo rdate -p tick.greyware.com
Password:
rdate: timeout connecting to time server
J'ai essayé avec pool.ntp.org, même résultat.
J'ai créé un fichier dans /var/lib/ntp nommé ntp.drift avec le contenu suivant :
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
Mais, ça ne change rien ce qui doit être normal puisqu'il faudrait le programme ntpd de ntp.org.
J'ai trouvé un serveur de temps aux usa (j'imagine bien qu'il y en a ailleurs)
time-d-g.nist.gov 129.6.15.27 NIST, Gaithersburg, Maryland All services available
et a priori ça fonctionnerait :
tux@slitaz:/var/lib/ntp$ sudo rdate -p 129.6.15.27 (ou 129.6.15.30 ou time-c-g.nist.gov)
Password:
Sun Dec 24 11:59:49 2023
tux@slitaz:~$ sudo date 081205432021
Password:
jeu. août 12 05:43:00 CEST 2021
tux@slitaz:~$ sudo rdate -s time-c-g.nist.gov
Password:
tux@slitaz:~$ date
dim. déc. 24 12:23:53 CET 2023
tux@slitaz:~$
tick.greyware.com renvoit invariablement "timeout connecting to time server".
J'avais encore 3 mises à jour après le rechargement de la liste.
Si la prochaine fois c'est encore d'actualité, je ferai une copie d'écran.
Je démarre à chaque fois à partir de l'image ISO via grub4dos en session live 32 bits avec les paramètres par défaut pour le français de France.
Liaision internet via wifi.
Je te souhaite un bon réveillon, si possible.
À bientôt.
Offline
Salut Rantanplan,
Intéressant, de ce que j'ai lu rdate utilise "Time Protocol" qui est obsolète remplacé par NTP.
Busybox dispose déjà du programme ntpd 
Voici la commande que j'ai exécuté :
tux@slitaz:~$ date
dim. déc. 24 13:05:40 CET 2023
tux@slitaz:~$ su -
Password:
root@slitaz:~# date 081205432021
jeu. août 12 05:43:00 CEST 2021
root@slitaz:~# ntpd -q -n -p 0.pool.ntp.org
ntpd: setting time to 2023-12-24 13:06:01.256361 (offset +74679777,899916s)
root@slitaz:~# date
dim. déc. 24 13:06:04 CET 2023
Si tu utilise bien l'iso faite hier (20231223), normalement il n'y pas de maj proposé.
Merci, je décolle milieu d'après midi pour rejoindre ma famille 
.
Bonne fêtes de fin d'années également / Happy Christmas for all.
Offline
Shann,
merci d'avoir pris le temps de répondre.
Bon voyage et savoure le temps avec les tiens.
Passez de bonnes fêtes ensemble.
Bonnes fêtes de Noël et du Jour de l'an nouveau.
Amitiés.
Offline
Suite "mise-à-jour".
1°) Version SliTaz depuis le terminal : cf. slitaz-version.png
2°) Rechargement liste dans TazPanel : cf rechargt-liste.png
3°) Mettre à jour depuis TazPanel : cf. mise-a-jour.png
4°) Mettre à jour depuis le terminal : cf tazpkg up -r
La commande [c]cat /etc/slitaz-release[/c] retourne bien [c]current[/c]
Démarrage à froid à partir d'un grub4dos et amorçage de l'image ISO 32 bits core avec les paramètres = français ; Live.
Rien de bloquant.
Mises à jour non appliquées.
Juste un signalement.
Amitiés.
[attachment=51928,3458] [attachment=51928,3459] [attachment=51928,3460] [attachment=51928,3461]
Offline
@shann,
Updating mwaveedit:
Execute post-install commands...
tempDir1 = $HOME/.mhwaveedit
Fix configuration files for tux ...sed: unmatched '|'
[ Failed ]
Offline
Hi Ceel,
good catch 
I test it for upgrade, but think forget retest from fresh config with '$HOME/.mhwaveedit' when refactor sed command.
Package rebuild with fix sed command.
I test with fresh config and also when config already set.
Offline
Bonjour Shann et toute l'équipe,
J'ai repris l'iso slitaz-current-core.iso, rien de mon côté
Merci pour le retour.
La version de référence est chez toi et j'ai plus confiance en tes résultats.
J'ai chargé la dernière version current qq heures avant ton annonce sur le forum (impatient que j'étais :-)).
À bientôt.
Amitiés.
Offline
Bonjour shann,
Je rencontre un problème avec la dernière mise à jour du kernel (27/12) ; un de mes PC se fige pendant le boot après [c]Loading network settings from /etc/network.conf[/c] pour Core ou [c]Configuring loopback...[/c] pour justX. Ça ne se produit que sur le Lenovo (récent, à peine plus de 2 ans), pas sur le (très) viel acer.
En repartant de l'ISO du 23/12 et en faisant la mise à jour de tous les paquets sauf linux-pae-drm, le boot se déroule normalement.
Bonne fête de fin d'année.
A happy new year at all the SliTazers!`
Offline
Bonsoir Ceel,
Arf
Ok je vais rollback l'ajout drm amdgpu.
J'ai un mini-pc sur lequel j'ai voulu mettre SliTaz, minus l'affichage avec VESA/FBDEV, tout fonctionne.
AMD Ryzen 3 3200U with Vega gfx
j'ai activé amdgpu drm dans le kernel, mais à mon avis le support n'est pas optimal sur la branche 4.x.
En testant, je reste sur vesa/fbdev.
Je suppose que ton lenovo à un ryzen with vega ?
Offline
Gagné, AMD Ryzen 5 3500 with Radeon Vega Mobile Gfx.
Offline
J'ai oublié d'te dire... Peut-être un indice ?
When using AMDGPU, it is recommended to unset the ATI Radeon option so that the radeon module is not built. Or alternatively, the module can be built and blacklisted (after rebooting check with lsmod | grep radeon to see if the blacklisting worked). The amdgpu and radeon modules are not meant to be loaded simultaneously, unless, for example multiseat, system requires it.
(la note sous l'encadré de la configuration du kernel, dans le paragraphe https://wiki.gentoo.org/wiki/AMDGPU#Kernel)
J'avais aussi commencé à bosser sur le module AMDGPU mais j'ai arrêté quand X a finalement démarré sur le Lenovo.
Offline
les 3 kernels ont bien été rebuild et les paquets synchronisé.
Je vais continuer à diag pour AMDGPU, la je coince sur le formatage du ssd 
.
CYX-SSD-S1000 (256Go), mkfs.ext3 failed.
je vois des ata2 softreset failed (device not ready), link slow, je comprend pas trop si c'est le ssd qui à un souci (pourtant neuf) ou si plutôt côté cable.
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata2.00: failed command: DATA SET MANAGEMENT
ata2.00: cmd 06/01:01:00:00:00/00:00:00:00:00/a0 tag 5 dma 512 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2.00: status: { DRDY }
ata2: hard resetting link
ata2: link is slow to respond, please be patient (ready=0)
ata2: softreset failed (device not ready)
ata2: hard resetting link
ata2: link is slow to respond, please be patient (ready=0)
ata2: softreset failed (device not ready)
ata2: hard resetting link
ata2: link is slow to respond, please be patient (ready=0)
ata2: link is slow to respond, please be patient (ready=0)
ata2: softreset failed (device not ready)
ata2: limiting SATA link speed to 3.0 Gbps
ata2: hard resetting link
ata2: softreset failed (device not ready)
ata2: reset failed, giving up
ata2.00: disabled
ata2: EH complete
sd 1:0:0:0: [sda] tag#7 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 1:0:0:0: [sda] tag#7 CDB: Write same(16) 93 08 00 00 00 00 05 20 7f e8 00 00 00 40 00 00
print_req_error: I/O error, dev sda, sector 86015976
sd 1:0:0:0: [sda] tag#8 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 1:0:0:0: [sda] tag#8 CDB: Write same(16) 93 08 00 00 00 00 04 e0 80 28 00 3f ff c0 00 00
print_req_error: I/O error, dev sda, sector 81821736
sd 1:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 1:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 a0 00 28 00 00 08 00
print_req_error: I/O error, dev sda, sector 10485800
sd 1:0:0:0: [sda] tag#9 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 1:0:0:0: [sda] tag#9 CDB: Read(10) 28 00 00 a0 00 28 00 00 08 00
print_req_error: I/O error, dev sda, sector 10485800
sd 1:0:0:0: [sda] tag#1 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 1:0:0:0: [sda] tag#1 CDB: Read(10) 28 00 00 a0 00 28 00 00 08 00
print_req_error: I/O error, dev sda, sector 10485800
Buffer I/O error on dev sda2, logical block 0, async page read
sd 1:0:0:0: [sda] tag#2 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 1:0:0:0: [sda] tag#2 CDB: Read(10) 28 00 00 a0 00 28 00 00 08 00
print_req_error: I/O error, dev sda, sector 10485800
Buffer I/O error on dev sda2, logical block 0, async page read
sd 1:0:0:0: [sda] tag#3 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 1:0:0:0: [sda] tag#3 CDB: Read(10) 28 00 00 a0 00 28 00 00 08 00
print_req_error: I/O error, dev sda, sector 10485800
sd 1:0:0:0: [sda] tag#10 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 1:0:0:0: [sda] tag#10 CDB: Read(10) 28 00 00 a0 00 28 00 00 08 00
print_req_error: I/O error, dev sda, sector 10485800
sd 1:0:0:0: [sda] tag#4 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 1:0:0:0: [sda] tag#4 CDB: Write(10) 2a 00 1d cf 32 28 00 00 88 00
print_req_error: I/O error, dev sda, sector 500118056
sd 1:0:0:0: [sda] tag#11 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 1:0:0:0: [sda] tag#11 CDB: Write(10) 2a 00 00 a0 20 40 00 05 40 00
print_req_error: I/O error, dev sda, sector 10494016
Buffer I/O error on dev sda2, logical block 1027, lost async page write
Buffer I/O error on dev sda2, logical block 1028, lost async page write
Buffer I/O error on dev sda2, logical block 1029, lost async page write
Buffer I/O error on dev sda2, logical block 1030, lost async page write
Buffer I/O error on dev sda2, logical block 1031, lost async page write
Buffer I/O error on dev sda2, logical block 1032, lost async page write
Buffer I/O error on dev sda2, logical block 1033, lost async page write
Buffer I/O error on dev sda2, logical block 1034, lost async page write
Autant mkfs.ext3 /dev/sda1 pour / est ok, par contre le mkfs pour /home
Offline
Hmm
C'est assez special, il semble que je doive utiliser -K (ou -E nodiscard) pour que le formatage se fasse sans problème.
Il semble que le ssd supporte fstrim mais pas totalement.
un fstrim -v / (/dev/sda1) ok, mais un fstrim -v /home (/dev/sda2) va échoué.
[c]FITRIM ioctl failed: Input/output error[/c]
L'impression que soit le kernel est pas assez récent, soit le chipset ne fait pas les choses correctement (normalement, c'est SATA AHCI, et derrière ssd m.2)
Offline
Bonjour tout le monde,
Meilleurs voeux de bonne et heureuse année 2024.
En vous souhaitant une bonne santé et de voir aboutir heureusement vos projets, même les plus fous.
suite à la mise à jour du paquet reconstruit linux zram, j'obtiens un échec (voir image jointe).
Merci.
À bientôt.
Amitiés.
[attachment=51943,3464]
Offline
Bonjour Rantanplan,
A la première installation de [c]linux-zram[/c], [c]tazpkg[/c] exécute la fonction [c]post_install()[/c] qui ajoute [c]compcache[/c] à la variable [c]RUN_DAEMONS[/c] dans le fichier [c]/etc/rcS.conf[/c] puis lance le daemon.
Lors d'une mise à jour du paquet, [c]tazpkg[/c] exécute également la fonction [c]post_install()[/c] mais [c]compcache[/c] est déjà démarré, d'où le message [c]compcache is already running, Echec[/c]. Ce n'est pas un échec d'installation et ça doit d'ailleurs se produire avec d'autres paquets.
Donc ce n'est pas une année qui commence mal ;-)
Meilleurs voeux à tous.
Offline
Bonjour Ceel,
merci d'avoir pris la peine de répondre.
Je n'étais pas inquiet et cette "péripétie" n'a pas entamé mon optimisme. :-)
D'ailleurs, malgré l'échec de l'exécution des cdes post-install, je n'avais pas constaté de dysfonctionnement lors de l'utilisation de la version current, chez moi.
S'il y a des tests d'utilisateur final (ou lambda) que je puisse réaliser et si ça peut aider, dis-le moi.
Je suis en version 32bits LiveUSB FR Europe/Paris sans persistance (derrière grub4dos).
Bonne soirée.
Amitiés.
Offline
Bonsoir,
Meilleurs voeux pour cette nouvelle année.
Celle-ci n'a pas vraiment commencée avec la santé pour mon frère et moi, nous avons eu le droit a le covid .
Encore un peu fatigué mais ça va mieux que début de semaine.
L'essentiel est que tous le monde va bien.
Pour la partie post-install de linux-zram, sans doute faire un check avant de lancer comcache.
Comme le souligne Ceel, c'est plus un warning, mais qu'on pourrait éviter .
La fin du support de la 4.19 arrive fin d'année il faut que je continue mes tests pour le 5.4.
Offline
For my minipc, i change this day ssd to nvme and increase memory.
(2x8Go DDR4 2666MHz SODIMM), see 14Go because vega has 2Go NVRAM allocated (no option on bios to change it)
Think ssd provide by default (256Go CYX-SSD-S1000) seem cheap.
Need deal with grub2, grub4dos doesn't support nvme.
patch lilo for nvme support but seem strange major is 259, but catch MAJOR_SATA2 (260).
tux@eretria:~$ lsblk -l
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 1 14.5G 0 disk
sda1 8:1 1 14.5G 0 part
nvme0n1 259:0 0 931.5G 0 disk
nvme0n1p1 259:1 0 5G 0 part /
nvme0n1p2 259:2 0 926.5G 0 part /home
tux@eretria:~$ uname -a
Linux eretria 4.19.298-slitaz-pae #6 SMP Wed Dec 27 21:30:03 Europe 2023 i686 GNU/Linux
tux@eretria:~$ df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 4.8G 84.7M 4.7G 2% /
tmpfs 6.9G 244.0K 6.9G 0% /run
tmpfs 6.9G 244.0K 6.9G 0% /var/run
devtmpfs 6.9G 0 6.9G 0% /dev
tmpfs 6.9G 0 6.9G 0% /dev/shm
tmpfs 6.9G 0 6.9G 0% /var/lock
/dev/nvme0n1p2 910.9G 460.0K 906.3G 0% /home
tux@eretria:~$ free -m
total used free shared buff/cache available
Mem: 14075 46 14018 0 10 13552
Swap: 0 0 0
tux@eretria:~$ grub-install -V
grub-install (GRUB) 2.04
Offline
[ Generated in 0.019 seconds, 7 queries executed - Memory usage: 1.62 MiB (Peak: 1.77 MiB) ]