Re: Problema chroot sid
Hola, Una altre alternativa quan vols/necessites utilitzar versions més modernes d'algun programari es mirar si esta empaquetat amb snap, flatpak o AppImage. Pel teu cas, el Handbrake el tens disponible com a flatpak [1] I si no tens instal·lat el suport per flatpak es tan fácil com seguir la guia [2], tot el necessari esta disponible en els repos de Debian des de la versió 10 (Buster) [1] https://flathub.org/apps/fr.handbrake.ghb [2] https://flathub.org/setup/Debian Fins aviat, -- Para ser realmente grande, hay que estar con la gente, no por encima de ella. El jue, 7 mar 2024 a las 10:56, escribió: > > Moltes gràcies per l'interès, Alex! > > On Wed, 6 Mar 2024 22:53:11 +0100 > Alex Muntada wrote: > > > Hola, > > > > > 2024-03-04 08:20:28 > > > URL:http://deb.debian.org/debian/pool/main/z/zlib/zlib1g_1.3.dfsg-3.1_amd64.deb > > > [87580/87580] -> > > > "/srv/chroot/sid//var/cache/apt/archives/partial/zlib1g_1%3a1.3.dfsg-3.1_amd64.deb" > > > [1] > > > tar: ./usr/lib/x86_64-linux-gnu/libuuid.so.1.3.0: Cannot open: File exists > > > tar: ./usr/lib/x86_64-linux-gnu/libuuid.so.1: Cannot create symlink to > > > 'libuuid.so.1.3.0': File exists > > > tar: Exiting with failure status due to previous errors > > > > Ho he tornat a provar ara i l'error era diferent: es queixava > > d'una incompatibilitat entre libssl3t64 i libssl3. Això m'ha > > fet pensar que, essent sid la versió inestable, potser hi ha > > alguna transició en marxa i he trobat això: > > > > https://release.debian.org/transitions/html/auto-openssl.html > > No en se prou com per avaluar tot això i me perdo. > > > > > Els primers cops no me'n vaig adonar d'aquest error. Total que he enviat > > > un bug: > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065343 > > > > He vist que han resolt una part, però segueix fallant el > > debootstrap per altres transicions que hi ha en marxa. > > Segurament debootstrap no està pensat per utilitzar-se amb > > sid, encara que s'utilitzi el de backports, perquè instal·la els > > paquets amb dpkg directament enlloc de fer-ho amb apt. > > > > He provat el mmdebstrap que suggereixen al bug i a mi també > > m'ha funcionat bé (com deia abans, mmdebstrap utilitza apt per > > instal·lar els paquets i aleshores resol millor les dependències > > que debootstrap). > > Sí,amb: > > sudo mmdebstrap sid /srv/chroot/sid > > no hi ha cap problema. Aquesta comanda, que desconeixia, m'ha salvat. > > > > > Vols dir que no utilitzes el debootstrap de bookworm-backports? > > > No ho entenc, perquè si utilitzo el debootstrap de bookworm en > > > lloc del de bookworm-backports a mi me surt el mateix error de > > > "Cannot open: File exists". > > > > Perquè el problema està a la resolució de dependències que > > comento més amunt en una versió del sistema que és inestable per > > les transicions que hi ha constantment: > > > > https://release.debian.org/transitions/ > > Ja, però en un chroot va molt bé per executar aplicacions que tenen problemes > en la versió estable (en aquest cas, hadbrake, que en el versió estable, al > gravar els subtítols, els grava doble) o que necessites una versió més > actual. Sempre estic a estable i acabo instal·lant una sid en un chroot. Per > mi, molt millor que una màquina virtual. > > Gràcies per tota aquesta ajuda i salut! > > > > > > Salut, > > Alex > > > > -- > > ⢀⣴⠾⠻⢶⣦⠀ > > ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada > > ⢿⡄⠘⠷⠚⠋ Debian Developer log.alexm.org > > ⠈⠳⣄ > > >
Re: error: out of memory
Hola, Sospito que el que ha passat aquí és que el sistema d'arxius on tens /var/lib/dpkg/info/ ha tingut algún problema i tens 1 o més d'un fitxer malmès. Donat que tens aquest error en la instal·lació del paquet python3.11 almenys sabem que el fitxer que correspon a aquest paquet està malmès pero no descartaria que en el futur en trobis d'altres. Tanmateix, per solucionar-ho només has de seguir les indicacions que et poso més avall però pel paquet en qüestió que et falli en aquell moment. Així que la solució al teu problema seria q esborris el fitxer: rm /var/lib/dpkg/info/python3.11.list Si vols, pots mirar quin contingut té, segurament estigui buit, truncat, a amb strings que no corresponen. Per si ho vols comparar a la meva màquina el md5sum d'aquest fitxer: ef564eb433ea96cc9431b38ab3e7064d /var/lib/dpkg/info/python3.11.list Un cop esborrat el fitxer has d forçar la reinstal·lació del paquet, per això fariem: apt-get install --reinstall python3.11 I llestos, amb això hauries de poder solucionar el problema. Per altre banda, com partim de la hipòtesi que aquest problema ha estat una corrupció en el sistema de fitxers seria recomanable que comprovis la salut del teu disc dur per si convé canviar-lo. Salutacions, -- Para ser realmente grande, hay que estar con la gente, no por encima de ella. -- Para ser realmente grande, hay que estar con la gente, no por encima de ella. El dom, 2 abr 2023 a las 19:30, Xavier De Yzaguirre i Maura () escribió: > > Sembla ser que no funciona. > No se si atrevir-me a eliminar-ne les línies del status > A veure si a algú se li acudeix el que fer. > Gràcies > > Xavier De Yzaguirre > xdeyzaguirre(at)gmail(dot)com > +34 629 953 830 > > > > > > Missatge de Jordi Pujol del dia dg., 2 d’abr. 2023 a > les 13:52: >> >> Hola, >> No comento gaires vegades, peró uns errors com aquests em fan ser >> curiós, perquè son molt estranys, sembla com si la màquina fallés, >> >> Aquest error al instal.lar python far evident que els fitxers >> d'aquests paquets en el disc son corruptes, >> s'hauria de fer: >> rm -vf /var/cache/apt/archives/python* >> al resinstal.lar tornarà a descarregar els paquets >> >> Podría ser el disc dur, és lo més probable, hauries de fer algunes proves. >> L'última vegada vaig solucionar-ho canviant el disc mecànic per un SSD >> de 1TB. Va molt més depressa i no falla quasi mai. >> >> Salut, >> Jordi Pujol >> >> On Sun, Apr 2, 2023 at 12:54 PM Xavier De Yzaguirre i Maura >> wrote: >> > >> > Bon dia de nou, >> > Algú més s'ha trobat amb el problema del python3.11 al fer un apt upgrade: >> > 2023-04-02 11:52:18 xavier@PC006:~$ sudo apt upgrade >> > S'està llegint la llista de paquets… Fet >> > S'està construint l'arbre de dependències… Fet >> > S'està llegint la informació de l'estat… Fet >> > S'està calculant l'actualització… Fet >> > S'instal·laran els paquets NOUS següents: >> > linux-headers-6.1.0-7-amd64 linux-headers-6.1.0-7-common >> > linux-image-6.1.0-7-amd64 >> > S'actualitzaran els paquets següents: >> > console-setup console-setup-linux fuse3 installation-report >> > keyboard-configuration libdebconfclient0 libfuse3-3 libpackagekitqt5-1 >> > linux-compiler-gcc-12-x86 linux-doc >> > linux-doc-6.1 linux-headers-amd64 linux-image-amd64 linux-kbuild-6.1 >> > linux-libc-dev xserver-common xserver-xorg-core xserver-xorg-legacy >> > 18 actualitzats, 3 nous a instal·lar, 0 a suprimir i 0 no actualitzats. >> > S'ha d'obtenir 8.611 kB/137 MB d'arxius. >> > Després d'aquesta operació s'utilitzaran 570 MB d'espai en disc addicional. >> > Voleu continuar? [S/n] >> > Bai:1 http://httpredir.debian.org/debian bookworm/main amd64 fuse3 amd64 >> > 3.14.0-3 [35,8 kB] >> > Bai:2 http://httpredir.debian.org/debian bookworm/main amd64 libfuse3-3 >> > amd64 3.14.0-3 [88,0 kB] >> > Bai:3 http://httpredir.debian.org/debian bookworm/main amd64 >> > xserver-common all 2:21.1.7-2 [2.381 kB] >> > Bai:4 http://httpredir.debian.org/debian bookworm/main amd64 >> > xserver-xorg-legacy amd64 2:21.1.7-2 [2.387 kB] >> > Bai:5 http://httpredir.debian.org/debian bookworm/main amd64 >> > xserver-xorg-core amd64 2:21.1.7-2 [3.719 kB] >> > S'ha baixat 8.611 kB en 2s (4.713 kB/s) >> > [master cf8db93] saving uncommitted changes in /etc prior to apt run >> > Author: xavier >> > 7 files changed, 19 insertions(+), 87 deletions(-) >> > delete mode 100644 NetworkManager/system-connections/Proton VPN >> > ES#27.nmconnection >> > delete mode 100644 >> > NetworkManager/system-connections/pvpn-ipv6leak-protection.nmconnection >> > delete mode 100644 >> > NetworkManager/system-connections/pvpn-killswitch.nmconnection >> > create mode 12 >> > "systemd/system/multi-user.target.wants/snap-gnome\\x2d3\\x2d38\\x2d2004-137.mount" >> > create mode 100644 >> > "systemd/system/snap-gnome\\x2d3\\x2d38\\x2d2004-137.mount" >> > create mode 12 >> > "systemd/system/snapd.mounts.target.wants/snap-gnome\\x2d3\\x2d38\\x2d2004-137.mount" >> > S'estan llegint els canvis... Fet >> > S'estan
Re: error: out of memory
Hola, Em sembla q t'has topat amb aquest bug: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1970402 A l'enllaç [1] trobaràs una solució que et servirà fins que ho arreglin. [1] https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1970402/comments/25 Salutacions, -- Para ser realmente grande, hay que estar con la gente, no por encima de ella. El jue, 30 mar 2023 a las 12:36, Xavier De Yzaguirre i Maura (< xdeyzagui...@gmail.com>) escribió: > Bon dia jovent, > Fa un parell de setmanes que he d'arrencar el portàtil amb un live usb, si > faig l'arrencada normal, em diu error: out of memory i em fa un kernel > panic. > Crec que tot va començar arrel d'una arrencada després d'un upgrade, però > no ho tinc clar. > L'equip es un msi Prestige 15 A10SC-007ES amb 32 GB de RAM > Porta dos discs NVME de 512 GB configurats així: > user@debian:~$ lsblk > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > loop0 7:00 2,8G 1 loop > /usr/lib/live/mount/rootfs/filesystem.squashfs > sda 8:01 14,4G 0 disk > ├─sda1 8:11 3,4G 0 part > /usr/lib/live/mount/medium > └─sda2 8:21 4,9M 0 part > nvme1n1 259:00 476,9G 0 disk > └─nvme1n1p1 259:10 476,9G 0 part > └─PC006.VG01-PC006.LV01 254:00 725,5G 0 lvm > nvme0n1 259:20 476,9G 0 disk > ├─nvme0n1p1 259:30 1,9G 0 part > ├─nvme0n1p2 259:40 119,2G 0 part > ├─nvme0n1p3 259:50 59,6G 0 part > ├─nvme0n1p4 259:60 31,7G 0 part > ├─nvme0n1p5 259:7016G 0 part > └─nvme0n1p6 259:80 248,6G 0 part > └─PC006.VG01-PC006.LV01 254:00 725,5G 0 lvm > La nvme0n1p1 es boot > La nvme0n1p2 es root > La nvme0n1p3 es var > La nvme0n1p4 es tmp > La nvme0n1p5 es swap > La PC006.VG01-PC006.LV01 (LVM suma de les nvme0n1p5 i la nvme1n1p1), es on > hi tinc /home > > El disc sda es l'usb amb la live que estic utilitzant per arrencar que es > una 11.6 (jo utilitzo la 12, la del menjallibres). > > Seguint algunes indicacions que he trobat googlejant faig el següent: > > user@debian:~$ sudo mount /dev/nvme0n1p2 /mnt > user@debian:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi > user@debian:~$ sudo mount /dev/nvme0n1p3 /mnt/var > user@debian:~$ sudo mount /dev/nvme0n1p4 /mnt/tmp > user@debian:~$ cat /mnt/etc/resolv.conf > # Generated by NetworkManager > nameserver 80.58.61.254 > nameserver 80.58.61.250 > user@debian:~$ sudo mount --bind /dev /mnt/dev > user@debian:~$ sudo mount --bind /dev/pts /mnt/dev/pts > user@debian:~$ sudo mount --bind /proc /mnt/proc > user@debian:~$ sudo mount --bind /sys /mnt/sys > user@debian:~$ > > I tot seguit faig un chroot a /mnt. > I comprovo que tinc accés a la xarxa per si calgués: > root@debian:/# ping debian.org > PING debian.org (128.31.0.62) 56(84) bytes of data. > 64 bytes from mirror-csail.debian.org (128.31.0.62): icmp_seq=1 ttl=50 > time=112 ms > 64 bytes from mirror-csail.debian.org (128.31.0.62): icmp_seq=2 ttl=50 > time=113 ms > ^C > --- debian.org ping statistics --- > 2 packets transmitted, 2 received, 0% packet loss, time 1078ms > rtt min/avg/max/mdev = 112.442/112.879/113.316/0.437 ms > > Desprès miro quines imatges tinc instal·lades: > root@debian:/# ls -ahl /boot > total 162M > drwxr-xr-x 4 root root 4,0K 30 de març 11:39 . > drwxr-xr-x 24 root root 4,0K 12 de març 13:03 .. > -rw-r--r-- 1 root root 254K 29 de gen. 13:33 config-6.1.0-3-amd64 > -rw-r--r-- 1 root root 254K 15 de febr. 06:56 config-6.1.0-5-amd64 > -rw-r--r-- 1 root root 254K 5 de març 16:33 config-6.1.0-6-amd64 > drwxr-xr-x 3 root root 4,0K 1 de gen. 1970 efi > drwxr-xr-x 8 root root 4,0K 30 de març 10:35 grub > -rw-r--r-- 1 root root 46M 30 de març 10:35 initrd.img-6.1.0-3-amd64 > -rw-r--r-- 1 root root 46M 30 de març 10:35 initrd.img-6.1.0-5-amd64 > -rw-r--r-- 1 root root 47M 30 de març 11:39 initrd.img-6.1.0-6-amd64 > -rw-r--r-- 1 root root 83 29 de gen. 13:33 System.map-6.1.0-3-amd64 > -rw-r--r-- 1 root root 83 15 de febr. 06:56 System.map-6.1.0-5-amd64 > -rw-r--r-- 1 root root 83 5 de març 16:33 System.map-6.1.0-6-amd64 > -rw-r--r-- 1 root root 8,0M 29 de gen. 13:33 vmlinuz-6.1.0-3-amd64 > -rw-r--r-- 1 root root 7,8M 15 de febr. 06:56 vmlinuz-6.1.0-5-amd64 > -rw-r--r-- 1 root root 8,0M 5 de març 16:33 vmlinuz-6.1.0-6-amd64 > I actualitzo les initramfs: > root@debian:/# update-initramfs -u -k all > update-initramfs: Generating /boot/initrd.img-6.1.0-6-amd64 > update-initramfs: Generating /boot/initrd.img-6.1.0-5-amd64 > update-initramfs: Generating /boot/initrd.img-6.1.0-3-amd64 > Després actualitzo grub: > root@debian:/# update-grub > Generating grub configuration file ... > Found theme: /boot/grub/themes/Breeze/theme.txt > Found background image: /usr/share/images/desktop-base/desktop-grub.png > Found linux image:
Re: USB discs no detectats/muntats
Hola, Fa pinta que estas utilitzant usbguard i aquest està bloquejant el dispositiu USB. A l'enllaç [1] que et poso trobaràs com autoritzar el dispositiu USB que endolles i com fer aquest canvi permanent. [1] https://askubuntu.com/a/1331639 Salutacions, -- Para ser realmente grande, hay que estar con la gente, no por encima de ella. El mar, 28 mar 2023 a las 23:43, Xavier Narcís () escribió: > > Hola , > > Tinc un ordinador amb Debian. > > Quan inserto un llapis de memòria no me'l reconeix. > > > $ sudo dmesg | grep -i usb | tail > [ 5178.345857] usb 1-1: SerialNumber: 4C530009460109105141 > [ 5178.346732] usb 1-1: Device is not authorized for usage > [ 5194.783328] usb 1-1: USB disconnect, device number 27 > [ 5201.880764] usb 1-1: new high-speed USB device number 28 using xhci_hcd > [ 5202.029470] usb 1-1: New USB device found, idVendor=0781, idProduct=5572, > bcdDevice= 1.27 > [ 5202.029485] usb 1-1: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [ 5202.029492] usb 1-1: Product: Cruzer Switch > [ 5202.029497] usb 1-1: Manufacturer: SanDisk > [ 5202.029502] usb 1-1: SerialNumber: 4C530009460109105141 > [ 5202.029961] usb 1-1: Device is not authorized for usage > > > Només el trobo com a última instància usant: > > > $ usb-devices > > T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh=12 > D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=1d6b ProdID=0002 Rev=06.01 > S: Manufacturer=Linux 6.1.0-7-amd64 xhci-hcd > S: Product=xHCI Host Controller > S: SerialNumber=:00:14.0 > C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA > I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub > E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms > > T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=480 MxCh= 0 > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor=0781 ProdID=5572 Rev=01.27 > S: Manufacturer=SanDisk > S: Product=Cruzer Switch > S: SerialNumber=4C530009460109105141 > C: #Ifs= 0 Cfg#= 0 Atr= MxPwr= > cat: '/sys/bus/usb/devices/usb1/1-1/1-*:?.*/bInterfaceNumber': El fitxer o > directori no existeix > cat: '/sys/bus/usb/devices/usb1/1-1/1-*:?.*/bAlternateSetting': El fitxer o > directori no existeix > cat: '/sys/bus/usb/devices/usb1/1-1/1-*:?.*/bNumEndpoints': El fitxer o > directori no existeix > cat: '/sys/bus/usb/devices/usb1/1-1/1-*:?.*/bInterfaceClass': El fitxer o > directori no existeix > cat: '/sys/bus/usb/devices/usb1/1-1/1-*:?.*/bInterfaceSubClass': El fitxer o > directori no existeix > cat: '/sys/bus/usb/devices/usb1/1-1/1-*:?.*/bInterfaceProtocol': El fitxer o > directori no existeix > /usr/bin/usb-devices: 91: printf: 0x: not completely converted > /usr/bin/usb-devices: 91: printf: 0x: not completely converted > I: If#= 0 Alt= 0 #EPs= 0 Cls=(none)() Sub= Prot= Driver= > > T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=5000 MxCh= 6 > D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1 > P: Vendor=1d6b ProdID=0003 Rev=06.01 > S: Manufacturer=Linux 6.1.0-7-amd64 xhci-hcd > S: Product=xHCI Host Controller > S: SerialNumber=:00:14.0 > C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA > I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub > E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms > > > > Em podeu donar alguna pista a partir d'aquí sobre què hauria de mirar ? > > > Gràcies per avançat ! > > Salut. >
Re: Trobades mensuals?
Hola, Els "services" del IRC d oftc tenen una comanda per demanar ajuda. Algunes de les comandes no comparteixen el mateix ordre de paràmetres que altres xarxes de IRC pero mirant l'ajuda podràs veure fàcilment com funcionen. La comanda general per demanar ajuda seria: /msg NickServ help I et respondrà amb totes les comandes que disposa. Si després vols veure com utilitzar una comanda concreta faries algo com: /msg NickServ help register De manera que per registrar un usuari la comanda que cerques té aquest format: /msg NickServ register password e-mail Fins aviat, Jordi -- Para ser realmente grande, hay que estar con la gente, no por encima de ella. El mar, 28 dic 2021 a las 20:24, Xavier De Yzaguirre i Maura () escribió: > > Bon dia, > > Per accedir a #debian-catalan ho provo amb l'HexChat i quan intento > accedir-hi em respon: > > #debian-catalan :Cannot join channel (Need to be identified and > verified to join this channel, '/msg NickServ help' to learn how to > register and verify.) > > Sembla que cal un registre d'usuari i mot_de_pas, però no me'n surto, fa > massa anys que no toco l'IRC. > > He escrit "/msg NickServ register" i em diu "register" > > a continuació poso "/register "la_meva_password" "el_meu_correu"" i > teòricament m'ha de respondre enviant-me un correu. No se si sol trigar > gaire a fer-ho però de moment fa 30 minuts i no he rebut res. > > Em podeu orientar una mica? > > Gràcies. > > -- > Xavier De Yzaguirre i Maura > > xdeyzaguirre at protonmail(dot)ch > S > >
Re: iso-3166
Hola, Ens falta una mica de context... Estem parlant de certificats signats per una CA privada que controles o estas generant un CSR que vols enviar a alguna entitat que et generi el certificat ? Suposant que la CA la controles tu o que la CA a qui li envies no verifica el codi de país (no es tècnicament obligatori per un certificat de domini), no cal inventar cap codi, senzillament no el posis en el teu CSR. Usant openssl seria algo d'aquest tipus: openssl req -nodes -sha256 -subj '/L=NomLocalitzacio/CN=foobar.tld' -newkey rsa:4096 -keyout mykey.pem -out mycsr.pem La part important és el paràmetre "-subj" amb lo qual no veuràs el clàssic prompt fent preguntes com el codi de país. Utilitzar el codi NT no sembla gaire bona pràctica. Per una banda, aquest no pertany a l'estàndard ISO-3166, i per altre, va existir només de forma temporal per un territori que després es va dividir entre Iraq i Arabia Saudi [1]. Si no us agraden els codis existents crec q es preferible no indicar-ne cap. [1] https://www.iso.org/obp/ui/#iso:code:3166:NT Salutacions, -- El vie, 24 dic 2021 a las 11:38, Jordi (<215...@runbox.com>) escribió: > > > Doncs tampoc ho accepta . > > > Jordi > > El dv. 24 de 12 de 2021 a les 10:28 +0100, en/na Narcis Garcia va > escriure: > > Per a certificats x.509 efectivament, s'utilitza la ISO 3166 als > > codis > > de país. > > El país neutral té aquest codi: NT > > D'aquesta manera, ni US, ni Cat ni ES. > > > > > > Narcis Garcia > > > > __ > > I'm using this dedicated address because personal addresses aren't > > masked enough at this mail public archive. Public archive > > administrator > > should fix this against automated addresses collectors. > > El 24/12/21 a les 10:24, Jordi ha escrit: > > > M'estic agafant amb calma la configuració de exim4 i ara toca la > > > part > > > dels certificats. > > > > > > Als que no us agrada el codi de país ES, que feu? He provat amb un > > > XZ > > > al csr però a l'intentar fer la sol·licitud a no-ip em diu que no > > > és > > > vàlid. El servidor serà per us estrictament personal del punt a al > > > punt > > > b i prou. Suposo que alguns fareu servir AD però vull saber si hi > > > ha > > > altres opcions. > > > > > > Gracies. > > > > > > Jordi > > > > > > >
Re: Eina per gravar pantalla d'escriptori
Hola, Pots utilitzar OBS (paquet obs-studio), funciona amb Wayland de manera que no hauries de tenir cap problema per fer el q vols. Fins aviat, -- El mié, 22 dic 2021 a las 20:27, robert marsellés () escribió: > > Hola, > > Necessito gravar un vídeo del que faig i veig a la pantalla per enviar-ho a > un servei tècnic. > > He obtingut 4 paquets de la secció "Video" via: > $ aptitude search ?description(screen)?description(record)?description(video) > (a) kazam > (b) recordmydesktop > (c) simplescreenrecorder > (d) vokoscreen-ng > > Després de provar-los tots, m'he endut la desagradable sorpresa de que tots > funcionen amb X11 enlloc de Wayland segons els registres o errors que > apareixien. Jo uso un portàtil Lenovo amb Debian Bookworm (aka testing) amb > escriptori GNOME 41.1 que per defecte usa Wayland. > > El que m'ha sorprès és que, quan algun cop he necessitat fer captures de > pantalla, he utilitzat l'eina que ve per defecte a GNOME (que es diu > originalment "captura") i tot ha funcionat bé. Des del meu punt de vista > d'usuari, un vídeo és com una sèrie de captures de pantalla. Llavors, com és > que les eines de vídeo no funcionen i en canvi fer fotos sí? > > He intentat usar-los en una sessió amb X11 enlloc d'una amb Wayland > mitjançant el canvi de la configuració a /etc/gdm3/daemon.conf. Concretament > amb una opció que està deshabilitada per defecte en aquest fitxer: >WaylandEnable=false > > L'únic que he aconseguit és una pantalla negra tant si reiniciava la màquina > com si no. El procés d'arrencada funciona bé, però quan hauria de sortir el > "login" gràfic tot es queda negre. He intentat passar a altres consoles sense > èxit (bé, més aviat tot era negre també així que no era conscient d'haver > canviat de lloc). > > Així doncs, necessitaria ajuda: > 1) Algú sap d'algun altre programa que pugui provar? Preferiblement Debian i > descarregat dels seus repositoris (personalment, no m'agrada descarregar > paquets de qualsevol altre lloc). > > En cas que l'opció 1 no pugui ser: > 2) Algú te idea de com usar una sessió X11 ara? Recordo que, fa un temps, > quan això de Wayland va començar havia provat a passar de l'un a l'altre i > tot va anar bé. Pràcticament podia fer les mateixes coses. N'hi ha prou amb > l'opció que jo he fet servir? He de modificar quelcom més en altres fitxers > GNOME? > > Gràcies de bestreta. Salut, > > robert > > > Sent with ProtonMail Secure Email. >
Re: pregunta sobre el nucli Linux
Hola, Potser no ha quedat clar com ho he explicat, intento fer-ho millor. Al que m'estava referint és que el oom-killer està protegint el sistema contra la denegació de servei que provocaria que no hi hagi memòria disponible per un procés (d'usuari). En el cas d'esgotar tota la memòria i solicitar-ne més el oom-killer s'invocaria alliberant memòria a base de matar un algún procés (segons unes regles predefinides). És a dir, contesta la pregunta que ha formulat l'Alex: (3) Per què un sistema operatiu multiusuari no ve de sortida més protegit per que el procés d'un usuari no es mengi tota la ram causan una denegació de servei a la resta ? Sobre l'enunciat de la pregunta hauriem d'aclarir també que el fet que un procés consumeixi tota la memòria del sistema no es intrínsecament dolent, per tant prohibir-ho per tots els casos no té sentit. Un usuari podria tenir una màquina que executa un sol procés que utilitza exactament tota la memoria però sense passar-se. Creieu que s'ha de denegar aquest comportament unilateralment?? Interpreto que quan et refereixes al "problema del company" vols dir que el Firefox (o qualsevol altre procés d'usuari de la máquina) tingui la possibilitat d'utilitzar tota la RAM del sistema. Això seria una cosa diferent a la denegació de servei per quedar-te sense RAM (i swap en cas d'haver-hi) i per gestionar-ho hi ha altres eines com ulimit, cgroups, ... En la majoria de distribucions (incloses Debian i Ubuntu) els límits per defecte són molt laxos però, no és responsabilitat de l'usuari (administrador) de la máquina configurar aquesta com desitgi?? Si estàs pensant que el oom-killer hauria d'haver matat el Firefox, segons el que ens expliquen probablement hauria d'haver passat, però també és possible que no s'hagués exhaurit tota la memòria sinó que s'ha quedat a prop del límit però sense arribar-hi i per tant no s'ha arribat a cridar el oom-killer. En aquest escenari el Firefox intentava funcionar amb la RAM+swap, lo qual és molt lent però es algo que ha decidit l'usuari de la màquina. T'encaixa ara?? Contestant a les teves preguntes sobre el codi del OOM: El significat que has suposat de les abreviacions és correcte. En quan al trosset de codi [2], l'objectiu de la funció on està escrit això és donar una puntuació pel procés sobre el que li han preguntat. Aquesta puntuació és una funció (en el sentit matemàtic) que utiliza diferents paràmetres sobre l'espai de memòria del procés (rss, swap, taula de pàgines,...). Per poder consultar aquestes dades necessita el punter a l'esctructura mm_struct i per trobar aquest punter crida a la funció "find_lock_task_mm()". Salutacions, Jordi -- -- Para ser realmente grande, hay que estar con la gente, no por encima de ella. El sáb, 2 oct 2021 a las 20:14, pedeb () escribió: > > Hola Jordi, > > sembla que això de oom_killer és una cosa que té múltiples > configuracions i que s'ha d'ajustar, però que té uns ajustos genèrics i > no veig gaire raonable per evitar el problema que comenta el company > [0], o estic equivocat. > > també he trobat [1] (això ho trobo molt interessant Alex) > > i independentment d'això, ja que has apuntat el codi font, si em pots > ajudar a entendre: > > què vol dir literalment la variable adj: adjustment? > > què vol dir literalment la mm: memory management?, ien aquest context [2] ? > > Gràcies! > Pedro > > [0] > https://www.percona.com/blog/2019/08/02/out-of-memory-killer-or-savior/ > https://www.oracle.com/technical-resources/articles/it-infrastructure/dev-oom-killer.html >que ve de > https://juantrucupei.wordpress.com/2017/04/03/desactivar-oom-killer-out-of-memory-killer/ > > [1] > https://dev.to/msugakov/taking-firefox-memory-usage-under-control-on-linux-4b02 > > [2] > p = find_lock_task_mm(p); > if (!p) > return LONG_MIN; > > On 10/2/21 3:02 PM, Jordi Miguel wrote: > > Hola, > > > > Sobre el tema del límit d'usuaris per les aplicacions de Google Drive > > (Docs, Sheets, Slides), Google diu el següent: > > > > Share & collaborate on a file with more than 100 people > > Up to 100 people with view, edit, or comment permissions can work on a > > Google Docs, Sheets, or Slides file at the same time. When more than > > 100 people are accessing a file, only the owner and some users with > > editing permissions can edit the file. > > > > Podeu veure la informació completa aquí[1] amb les solucions que > > proposen per compartir amb més de 100 persones. Potser seria > > interessant que ens comentessis com vas compartir aquesta presentació: > > quins permisos tenies tu sobre la presentació? els alumnes tenien el > > mateix enllaç i, per tant, permisos que tu? o l'enllaç dels alumnes > > només tenia permisos com a lector ?? Pots reproduir el problema si > >
Re: pregunta sobre el nucli Linux
Hola, Sobre el tema del límit d'usuaris per les aplicacions de Google Drive (Docs, Sheets, Slides), Google diu el següent: Share & collaborate on a file with more than 100 people Up to 100 people with view, edit, or comment permissions can work on a Google Docs, Sheets, or Slides file at the same time. When more than 100 people are accessing a file, only the owner and some users with editing permissions can edit the file. Podeu veure la informació completa aquí[1] amb les solucions que proposen per compartir amb més de 100 persones. Potser seria interessant que ens comentessis com vas compartir aquesta presentació: quins permisos tenies tu sobre la presentació? els alumnes tenien el mateix enllaç i, per tant, permisos que tu? o l'enllaç dels alumnes només tenia permisos com a lector ?? Pots reproduir el problema si comparteixes la presentació de la manera que es proposa a la documentació de Google ?? Sobre el motiu pel qual Firefox consumeix tota la memòria RAM, imagino que tindràs extensions i/o temes carregats. El primer pas seria intentar reproduir el mateix problema utilitzant el safe mode (e.g. # firefox --safe-mode ) ?? Si en safe mode el Firefox es comporta correctament hauries d'anar activant/desactivant extensions fins que trobis quina provoca que el consum es dispari. En quant el tema de control de memòria per part del kernel ja has vist en la teva cerca per Internet que tens diverses opcions disponibles (ulimit, cgroups, ...). La funció de protecció que busques opino que la compleix el OOM-killer (out-of-memory killer). Podeu veure com funciona mirant el codi font [2]. Quan aquest procés s'activa registra el que ha fet al dmesg. Si realment es va consumir tota la memòria pots revisar quin o quins processos va matar el OOM-killer mirant els logs. [1] https://support.google.com/drive/answer/2494822?hl=en [2] https://github.com/torvalds/linux/blob/master/mm/oom_kill.c#L195 Salutacions, Jordi -- El sáb, 2 oct 2021 a las 13:28, Àlex () escribió: > > > > Em crida molt l'atenció que Google Slides faci petar el navegador quan > > es comparteix una presentació amb 100 persones. > > > No és tant quan 100 persones obren el document, com quan un d'ells fa > clic al botó d'iniciar reproducció. > > Quan moltes persones tenen el document obert el sistema no tenía més que > 1 Gb de RAM ocupada entre escriptori i navegador. És quan faig clic al > botó d'iniciar presentació qué de sobte demana tota la RAM i peta. Per > què? No ho sé. > > Només ho he reproduit un parell de cops amb Ubuntu 18.04 + Firefox 92.0 > > No ho he provat amb Chromium . Tampoc ho he provat a Windows ni MacOS. > > Fa uns dies que veig que els llocs de Google funcionen millor amb > Chromium que amb Firefox. Potser només passa amb Firefox. > > Però de les tres preguntes que sorgeixen ... > > (1) Per què passa això a Google Slides ? > > (2) Per què els navegadors no controlen quan una pestanya es menja tota > la RAM del sistema per avisar l'usuari si la vol bloquejar ? > > (3) Per què un sistema operatiu multiusuari no ve de sortida més > protegit per que el procés d'un usuari no es mengi tota la ram causan > una denegació de servei a la resta ? > > ... a llarg termini m'interessen més la pregunta (3) ó la (2) que la (1) >
Re: debian 11 webdav lent
Hola, Podries debugar la connexió dels clients Debian 11 utilitzant curl en aquelles maquines. Així podries descartar que sigui el davfs o el gvfs de Debian 11 els que tenen algun cosa que fa q vagin lents. Un exemple de crida curl contra NextCloud seria: curl -i -X PROPFIND --user 'usuari:pass' -v 'http://foo.tld/remote.php/dav/files/usuari/' --upload-file - -H "Depth: 1" < end Això et retornaria el listat d fitxers de la carpeta d l'usuari que demanis. Si funciona sense lentitud almenys sabràs que el problema no es la comunicació entre el teu server i els clients, sino alguna cosa del client d WebDav que fas servir a Debian11. Salutacions, Jordi -- Para ser realmente grande, hay que estar con la gente, no por encima de ella. El jue, 26 ago 2021 a las 17:54, Blackhold () escribió: > > Hola, > responc entre línies > > Missatge de R. Sicart del dia dj., 26 d’ag. > 2021 a les 15:14: > > > > Bones, > > > > I les rutes de xarxa són les mateixes? Tant debian 10 com debian 11 fan > > servir IPv4 o IPv6 per connectar-se al nextcloud webdav? > > Estan els equips a la mateixa xarxa, tinc 3 debian 10 i 5 debian 11, > el comportament és el mateix per a tots (debian 10 ok, debian 11 > lent). > > > > > D'altra banda, pel que veig, sembla un problema que li passa a més gent. No > > sé si amb el mateix setup que tu fas servir però en tot cas no sembla un > > problema nou: https://duckduckgo.com/?q=nextcloud+webdav+slow=fpas=web > > > > Mai he fet servir nextcloud, llegint en diagonal veig que podria ser una > > sobreutilització de la base de dades per php, problemes de IOwait, etc. El > > que em sorprèn O_O és que des dels clients debian 10 no tinguis el > > problema. Podria ser una questió de cache local existent als debian 10, > > però inexistent als debian 11? > > > > Els paquets relacionats amb webdav/nextcloud instalats als clients debian > > 10 i debian 11 són els mateixos? > > Estic per provar un altre entorn d'escriptori, cinnamon utilitza nemo > com a navegador de finestres i al no haver-hi cap client específic > instal·lat al sistema (només llibreries), entenc que el client de > webdav va incorporat al navegador de finestres, per a això he provat > davfs2 a la debian 11 però he descartat seguir anant per aquest camí > perquè encara era més lent que amb el navegador de finestres de > l'entorn d'escriptori. En unes hores provaré per exemple gnome a > debian 11 per veure quin n'és el comportament. > > Altres proves que he fet ha sigut canviar el servidor de nginx a > apache al servidor de nextcloud, el comportament és el mateix. Vull > provar també de pujar el servidor a debian 11, tot i que espero que el > resultat em torni a dur a que el problema està a les debian 11. > > > > > Salut i sort amb la recerca. > > Gràcies, viam si ho trobo... > > > -- > > > > R. Sicart > > > > 26 août 2021 13:31:53 Blackhold : > > > > > Amb tcpdump no veig excessives diferències, els ports més o menys són > > > els mateixos. Es genera molta informació per a cada connexió i tampoc > > > sóc capaç d'identificar massa les diferències entre els paquets > > > generats per una versió i altra de client de webdav. > > > > > > He provat de muntar el webdav fent servir el paquet davfs2 i també, la > > > lentitud és extrema... > > > > > > Què hi ha a debian 11 que no estigui a debian 10 que pugui estar > > > enlentint la comunicació? > > > > > > Gràcies > > > > > > - Blackhold > > > http://blackhold.nusepas.com > > > @blackhold_ > > > ~> cal lluitar contra el fort per deixar de ser febles, i contra > > > nosaltres mateixos quan siguem forts (Xirinacs) > > > <°((( >< > > > > > > Missatge de R. Sicart del dia dc., 25 d’ag. > > > 2021 a les 21:02: > > >> > > >> Bones, > > >> > > >> Jo potser provaria de comparar una captura tcpdump de cada client, per > > >> veure si fan servir els mateixos protocols i ports. > > >> > > >> Sort ! >
Re: Debian 11 estable en poques hores
Hola, Pots utilitzar els binaris dels repos de Virtualbox per Debian Stable amb la Debian Testing. Es a dir, que el repo "deb http://download.virtualbox.org/virtualbox/debian buster contrib non-free" et funcionarà amb bullseye i el pots utilitzar fins que treguin el de la nova stable. Fins aviat, Jordi -- Para ser realmente grande, hay que estar con la gente, no por encima de ella. El mié, 18 ago 2021 a las 13:03, jordi P. () escribió: > > On 18/8/21 9:29, Eloi wrote: > > Pel que fa a VirtualBox, n'explico la història: deixant de banda el fet > > que estigués a contrib per necessitar d'un compilador privatiu per a la > > BIOS simulada, el problema ha vingut perquè, ja fa un temps, Oracle va > > ../-- > > > > Pels meus usos, especialment màquines virtuals en servidors remots, QEMU > > ha estat un gran salt endavant. Per a usos domèstics reconec, però, que > > pot ser un petit pas enrere. > > Cert i molt ben enraonat, però és clar que cada cas és un mon. > > Fa bastants anys, a la feina vaig muntar algun sistema amb WWMware i > també amb quemu, tot era molt nou i a les beceroles, i d'allò ja no en > queda res. > > Ara a nivell domèstic i per comóditat el Virtualbox només el necessito > per fer córrer un sol programa amb W7, la seguretat d'aquesta maquina em > preocupa molt poc, i prou pena tinc d'haver d'utilitzar res de ms. > > Esperaré a veure si els de Virtualbox fan uns binaris per Bullseye. > > > -- > Jordi Perera >
Re: Engegada aleatòria
Hola, Quina llàstima que haguem de cercar solucions amb tan poca informació per part del kernel... Que el hardware no funcioni correctament no seria la meva primera opció ja que dius que tens un kernel antic que arrenca sempre sense problemes. En tot cas estaríem parlant d'un tema d'incompatibilitat o bug, o potser tens la mala sort de que llegeixes un tros de disc que no sempre funciona bé. A partir d'aquí aniria provant diverses coses a veure si alguna cosa ajuda a desencallar. A cada canvi prova d'apagar i arrencar per veure si hi ha alguna diferència: - Tornar a crear el ramdisk amb la màquina encesa amb el kernel que no et funciona b: # update-initramfs -c -k `uname -r` Si retorna output d'alguna cosa que no li agrada ja ens ho diràs. Pots crear-lo amb verbose (-v) si vols més informació del què posa a dins. # update-grub2 - Desactivar Kernel Mode Setting (KMS): Edita el fitxer /etc/default/grub i modifica la variable GRUB_CMDLINE_LINUX_DEFAULT amb "nomodeset i915.modeset=0 amdgpu.dc=0" # update-grub2 - Tens algun mòdul afegit al ramdisk?? Aquests s'especifiquen a /etc/initramfs-tools/modules - Verifica la informació d'estat del disc dur via SMART # smartctl -a /dev/sda Pots executar un test llarg amb: # smartctl --test=long /dev/sda I quan acabi sortirà la informació a la sortida de l'anterior comanda. Espero que finalment obtinguem algun canvi de comportament. Salutacions, -- Para ser realmente grande, hay que estar con la gente, no por encima de ella. -- Para ser realmente grande, hay que estar con la gente, no por encima de ella. El mar, 16 mar 2021 a las 8:01, Joan Albert () escribió: > > Bon dia Jordi, > > > Si amb aquesta configuració encara no ens > > ensenya res augmenta a "loglevel=7" i afegeix "debug". > > He provat fins i tot aquesta opció, però el que fa és reportar molta més > informació només si passa la part crítica. > > > Buscant per Internet he vist que hi ha força gent que ha tingut > > problemes similars al teu amb els kernels 5.10, la majoria però deien > > que se'ls hi arreglava amb la versió 5.10.0-4 però és precisament la > > que tu fas servir i ha quedat clar que no et funciona bé. > > Efectivament, i de fet crec que arrossego un parell de versions que em > donaven problemes (m'hauria d'haver fixat en quina va ser la primera, > però no ho recordo). > > > Si ens pots donar més informació aquestes preguntes podrien ajudar: > > - Tens el portàtil connectat a alguna dock station?? Si fos així, et > > passa el mateix quan no està endollat a ella?? > > No el tinc a cap dock station. > > > - Utilitzes un monitor extern?? Et passa el mateix quan no està > > connectat el monitor extern? (o a la inversa) > > Sí l'utilitzo normalment, però no canvia el resultat segons si està o no > connectat a ell. > > > - Has provat mai d'esperar a veure si acaba arrencant? de l'ordre de > > deixar-lo 15-25 minuts (com més millor per descartar). En cas negatiu, > > normalment quan de temps has esperat abans de forçar un reinici? > > Ahir mateix vaig esperar més d'una hora :) > > Em pregunto si no pot ser un problema de hardware simplement... > > Gràcies igualment i salut! > > -- > TS
Re: Engegada aleatòria
Hola, Bé, almenys sabem que quan no funciona no s'arriba ni a executar systemd, de manera que falla molt aviat en el procés. El següent pas que t'aconsello es augmentar el nivell de log. Per això hauries de tornar a editar el fitxer /etc/default/grub i posar un "loglevel=6" a la variable GRUB_CMDLINE_LINUX_DEFAULT (recorda fer el update-grub2 després). Si amb aquesta configuració encara no ens ensenya res augmenta a "loglevel=7" i afegeix "debug". Buscant per Internet he vist que hi ha força gent que ha tingut problemes similars al teu amb els kernels 5.10, la majoria però deien que se'ls hi arreglava amb la versió 5.10.0-4 però és precisament la que tu fas servir i ha quedat clar que no et funciona bé. Si ens pots donar més informació aquestes preguntes podrien ajudar: - Tens el portàtil connectat a alguna dock station?? Si fos així, et passa el mateix quan no està endollat a ella?? - Utilitzes un monitor extern?? Et passa el mateix quan no està connectat el monitor extern? (o a la inversa) - Has provat mai d'esperar a veure si acaba arrencant? de l'ordre de deixar-lo 15-25 minuts (com més millor per descartar). En cas negatiu, normalment quan de temps has esperat abans de forçar un reinici? Salutacions, Jordi -- Para ser realmente grande, hay que estar con la gente, no por encima de ella. -- Para ser realmente grande, hay que estar con la gente, no por encima de ella. El lun, 15 mar 2021 a las 12:04, Joan Albert () escribió: > > Hola Jordi, > > De nou, moltes gràcies pel teu temps. > > > Entenc que això és la sortida de dmesg d'una arrencada que ha funcionat > > correctament. > > Efectivament, és la sortida d'una arrencada que ha funcionat > correctament. > > > Amb el canvi aquest del grub el proper cop que l'ordinador no s'engegui > > correctament la pantalla no amagarà cap missatge que s'hagi escrit, de > > manera > > que espero que surti alguna cosa interessant que ens doni una pista, més > > enllà > > d'aquell "Loading initial ramdisk" que ens vas posar a l'inici. > > - Per veure el llistat d'arrencades de l'ordinador: # journalctl > > --list-boots > > El tema és que no trobo més informació d'arrencades no > satisfactòries. He revisat el llistat d'arrencades utilitzant la comanda > # journalctl --list-boots i només apareixen les arrencades que han > funcionat (només apareix una del dia d'ahir, i en total devien ser 15 > intents). Tampoc apareixien més missatges a part de "Loading initial > ramdisk", tot i canviar els paràmetres del grub i fer l'actualització. > > Salut, > > -- > Joan Albert
Re: Engegada aleatòria
Hola, Quan l'ordinador s'engega amb normalitat utilitzant el kernel 5.10.0 que es el q diu/fa després del "Loading initial ramdisk" ?? Pot ser que tinguis el GRUB configurat amb "quiet" i/o "splash" ?? Si és així ho podries modificar per poder veure el que s'imprimeix a la pantalla quan l'ordinador es congela. Bàsicament hauries de editar el fitxer /etc/default/grub i modificar una línea que dirá algo similar a aixo: GRUB_CMDLINE_LINUX_DEFAULT="quiet" Pots deixar la variable buida. Guardes el fitxer i després apliques la configuració executant la comanda (com a root): update-grub2 A veure si d'aquesta manera pots obtenir més informació que ajudi a veure el que li passa quan no funciona. Fins aviat, Jordi -- Para ser realmente grande, hay que estar con la gente, no por encima de ella. El mié, 10 mar 2021 a las 12:03, Joan Albert () escribió: > > > Potser el sistema d'arrencada estigui corrupte o mal generat: > > $ sudo update-initramfs -u -k all > > He provat exactament aquesta comanda sense cap tipus d'error, > i segueixo tenint el mateix problema :) > > Alguna idea més? Gràcies igualment! > > -- > TS >
Re: (deb-cat) Desfragmentacio de l'arrencada
Hola, Aquestes eines que comentes va ser el primer q vaig pensar en llegir el correu del Narcís, pero després em vaig adonar que ell no estava pensant en el cas generic de que tots els trossets d'un fitxer estiguin guardats d manera consecutiva en el disc, sinó, que a banda de que els fitxers no estiguin fragmentats, un conjunt de fitxers (els q es llegiran al arrencar) estiguin emmagatzemats de forma consecutiva. Fins on tinc entès, les eines de defragmentació de disc generals no intenten optimitzar aquest cas i això es el que fa el e4rat-lite. Segurament seria convenient facilitar la feina del e4rat-lite començant amb un disc que no tingui fragmentació, amb lo qual el combo e4defrag + e4rat-lite seria interessant de provar. Fins aviat, Jordi El mié., 24 feb. 2021 18:54, Alex Muntada escribió: > Hola Jordi > > > Almenys existeix una eina que fa el que està buscant el Narcís, > > es diu e4rat i pots trobar informació al wiki de ArchLinux. > > Tanmateix l'eina original va quedar una mica "abandonada" i > > el projecte més actiu és un fork que es diu e4rat-lite > > Sembla que les versions recents dels nuclis linux duen activada > l'opció extend de l'ext4, que permet defragmentar a nivell de > fitxers amb e4defrag (ja ve amb el paquet e2fsprogs). > > Habitualment es deia que els sistemes de fitxers ext3 i ext4 > no es fragmentaven, però sembla que algú va fer una recerca més > detallada del tema i d'aquí en va sorgir l'eina e4defrag: > > > https://www.hecticgeek.com/defragment-ext4-file-systems-using-e4defrag-ubuntu/ > > Salut, > Alex > > -- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada > ⢿⡄⠘⠷⠚⠋ Debian Developer log.alexm.org > ⠈⠳⣄ > >
Re: (deb-cat) Desfragmentacio de l'arrencada
El mié, 24 feb 2021 a las 10:58, Josep Lladonosa () escribió: > > > > On Wed, 24 Feb 2021 at 08:47, Narcis Garcia wrote: >> >> Quan un ordinador arrenca, executa programes i aquests carreguen >> llibreries i fitxers d'arreu del volum de disc. >> Això produeix lectures aleatòries de centenars de fitxers amb els blocs >> dispersos per tota la unitat ja que, quan es desfragmenta un disc dur, >> la única cosa que s'ordena és que cada fitxer tingui els seus blocs de >> dades contínus en el disc. >> >> És a dir, podem tenir fitxers emmagatzemats com a lletres: >> A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z >> >> Però l'arrencada carrega per exemple el gestor d'arrencada (A) el qual >> carrega el sistema del nucli (B), i el qual aleshores demana fitxers >> d'arreu com R, J, Y, D, K per la qual cosa el capçal d'un disc dur no fa >> més que canviar de posició tota l'estona i fent que la càrrega sigui >> molt més lenta del què el disc seria capaç de transmetre seqüencialment. >> Això es nota molt amb el soroll d'un disc dur quan arrenca el sistema. >> >> L'ideal en aquest exemple seria poder reorganitzar els blocs del disc així: >> A,B,R,J,Y,D,K, C,E,F,G,H,I,L,M,N,O,P,Q,S,T,U,V,W,X,Z >> De manera que de la A a la K es llegís tot sense interrupció. >> >> Hi ha alguna eina que faciliti això per accelerar l'arrencada? > > > La meva proposta passa per afegir maquinari (un ssd on el temps de > "posicionament" és molt petit i més o menys constant). > Podríeu teniri un ssd "petitó" utilitzat en forma de memòria cau (estil > bcache) > o, directament, tenir un ssd "petitó" per al sistema... > > SALUT! > Josep > >> >> >> Gràcies. >> >> -- >> >> Narcis Garcia >> >> __ >> I'm using this dedicated address because personal addresses aren't >> masked enough at this mail public archive. Public archive administrator >> should fix this against automated addresses collectors. >> > > > -- > -- > Salutacions...Josep > -- Hola, Almenys existeix una eina que fa el que està buscant el Narcís, es diu e4rat i pots trobar informació al wiki de ArchLinux[1]. Tanmateix l'eina original va quedar una mica "abandonada" i el projecte més actiu és un fork que es diu e4rat-lite [2] Si ho proves ja ens comentes l'experiència, i si la feina de muntar aquestes coses val la pena per estalviar-se comprar un SSD per un sistema antic. Amb el preu d'un SSD avui dia sembla difícil de justificar el temps per configurar i mantenir aquestes artesanies, però sempre és divertit pels amants de la tecnologia. [1] https://wiki.archlinux.org/index.php/e4rat [2] https://github.com/LendyZhang/e4rat-lite Fins aviat, Jordi -- Para ser realmente grande, hay que estar con la gente, no por encima de ella.
Re: Curiositat sobre les IP assignades pels proveïdors
Hola Orestes, El que comentes que fa el teu proveïdor s'anomena "Carrier-grade NAT" i és una pràctica que s'ha estès bastant degut a l'esgotament de les adreces IPv4. Es d'esperar que quan lo habitual sigui IPv6 aquests proveïdors tornaran a donar IPs públiques als seus usuaris. En quant a obrir ports per poder accedir a serveis que tinguis a les teves màquines internes des de Internet ho tens bastant negre. Bàsicament les solucions passen per obtenir una adreça IP pública que si que puguis controlar i utilitzar-la per publicar els serveis als que vols accedir des d'Internet. Possibles solucions: - Obtenir una adreça d'un proveïdor de VPN que suporti publicar serveis. - Si el teu proveïdor tmb t'esta donant una IPv6, i si aquesta és pública (això segon seria bastant probable) utilitzar-la per publicar els teus serveis. L'únic "desavantatge" és que els usuaris que només tinguin un accés IPv4 no podran accedir directament als teus serveis, hauran d'utilitzar miredo o altres solucions. - Si disposes d'un servidor amb IP pública fer un tunel entre la teva màquina i la màquina externa i publicar els serveis utilitzant la IP del servidor públic. (algo similar a lo que s'explica aquí [1]) Espero que aquesta informació et serveixi d'alguna cosa. Per cert, estic molt d'acord amb el Pedro que els proveïdors haurien de deixar ben clar si la connexió que contractes està darrera un NAT o no. Desconec si el teu proveïdor ha deixat clara aquesta informació abans d'adquirir el producte, tanmateix donat que hi ha ISPs que no ho diuen fóra bó disposar d'una llista pública on els usuaris puguin consultar aquesta informació abans de contractar res. [1] https://amoss.me/2017/05/port-forwarding-behind-a-carrier-grade-nat/ Fins aviat, Jordi -- Para ser realmente grande, hay que estar con la gente, no por encima de ella. El lun., 27 ago. 2018 a las 13:42, Orestes Mas () escribió: > > Hola a tothom, > > Observo un fenomen curiós, i m'agradaria saber si algú de vosaltres s'hi > ha trobat. > > Fa pocs dies m'he posat fibra a casa. Volia obrir el port 22 del router > per poder accedir des de fora via ssh a un ordinador. Això ja ho feia > amb el proveïdor antic i no tenia cap problema, però ara amb el router > nou no em funcionava. La IP pública, segons m'indiquen webs del tipus > "whatismyip" era 93.176.xxx.yyy (canvia si reboto el router). > > Però com que no em funcionava m'hi he barallat una estona i al final > acabo deduint que el proveïdor d'internet utilitza una xarxa privada > interna (una classe B, suposo, amb adreces de l'interval > 100.76.xxx.yyy). I surt a internet amb unes quantes adreces públiques > compartides entre diversos usuaris. > > Les preguntes: Us heu trobat que el proveïdor d'internet faci NAT també? > Sabeu si com a usuaris ens podem queixar (ja imagino que no...)? Vaig > errat si dedueixo que això impedirà que funcioni qualsevol accés a casa > iniciat des de l'exterior (tipus emule, bittorrent,ssh , httpd...)? > Suposo que funcionarà entre usuaris de la xarxa privada, però com que > només són 65536 això no és massa esperançador... > > Orestes > >
Re: Curiositat sobre les IP assignades pels proveïdors
Hola, Aquesta resposta sobre les IP's privades no es del tot precisa. Existeixen més rangs que no s'enruten a Internet. Entre ells el rang que comenta l'Orestes i que pertany al següent RFC: https://tools.ietf.org/html/rfc6598 Si mireu el RFC veureu que es un rang que es va crear precisament per fer el que l'Orestes ha detectat en la seva connexió. D'altre banda, et confirmo que efectivament no és el primer proveïdor d'Internet que utilitza NAT amb els seus usuaris. Salutacions, Jordi -- Para ser realmente grande, hay que estar con la gente, no por encima de ella. El lun., 27 ago. 2018 a las 14:04, Pedro () escribió: > > > Però com que no em funcionava m'hi he barallat una estona i al final > > acabo deduint que el proveïdor d'internet utilitza una xarxa privada > > interna (una classe B, suposo, amb adreces de l'interval > > 100.76.xxx.yyy). I surt a internet amb unes quantes adreces públiques > > compartides entre diversos usuaris. > > Els prefixos de xarxa privada són: > > 10.0.0.0- 10.255.255.255 (10/8 prefix) > 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) > 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) > > https://tools.ietf.org/html/rfc1918 > > > podria ser que el proveïdor bloqueja port 22, per què no proves un altre? > > fora bo que ens diguis de quin proveïdor es tracta i així ens animarem > a posar-lo en les nostres whitelists o blacklists personals >
Re: (deb-cat) GRUB2, BIOS, LBA, mdadm
Amb la informació que disposem no se m'acut cap idea per ajudar-te a fer que el GRUB vegi el volum RAID, així que em sembla q et queden dues opcions: 1. Esperar que algu d'aquesta llista tingui una bona idea per solucionar-ho i/o anar a demanar suport als desenvolupadors de GRUB per tal de trobar la causa del teu problema. 2. Canviar d'estratègia i aconseguir el teu volum amb els 3 discs utilitzant LVM enlloc de RAID. Potser d'aquesta manera esquives els problemes/anomalies. Salutacions, Jordi -- Para ser realmente grande, hay que estar con la gente, no por encima de ella. 2017-11-23 17:30 GMT+01:00 Narcis Garcia <debianli...@actiu.net>: > > $ insmod mdraid1x > $ ls > (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) (hd2) (hd2,msdos1) (fd0) > > > > __ > I'm using this express-made address because personal addresses aren't > masked enough at this mail public archive. Public archive administrator > should fix this against automated addresses collectors. > El 23/11/17 a les 16:19, Jordi Miguel ha escrit: > > Sembla ser que el GRUB no està veient els dispositius RAID. Podries > > executar a la shell de GRUB el següent i enviar-nos la sortida?? > > > > grub> insmod mdraid # (podria ser que es digues "raid" a seques, no > > estic segur del nom ara) > > grub> ls > > > > > > Salutacions, > > Jordi > > -- > > Para ser realmente grande, hay que estar con la gente, no por encima de > > ella. > > > > > > 2017-11-23 15:38 GMT+01:00 Narcis Garcia <debianli...@actiu.net>: > >> Deshabilitant la disquetera de 1.44K, la única diferència és que > >> desapareix el missatge sobre «fd0». Tinc entès que seria possible > >> configurar el mapa d'unitats de GRUB per tal que ometi unitats com fd0. > >> > >> grub rescue> ls > >> (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) (hd2) (hd2,msdos1) > >> > >> grub rescue> ls (hd0,msdos1)/ > >> error: unknown filesystem. > >> > >> > >> __ > >> I'm using this express-made address because personal addresses aren't > >> masked enough at this mail public archive. Public archive administrator > >> should fix this against automated addresses collectors. > >> > >> El 23/11/17 a les 15:25, Jordi Miguel ha escrit: > >>> Donades les linies d'error que ens has posat sembla que la unitat de > >>> disquet (fd0) de l'ordinador esta en conflicte amb el GRUB, ja sigui > >>> per un bug o un altre motiu que desconec. Podries provar a desactivar > >>> de la BIOS la unitat de disquet (i ja posats desendollar-la del > >>> ordinador per estar segurs) i provar-ho de nou? > >>> Si a la consola del Grub executes un "ls", quines particions veu? Ens > >>> pots enviar l'output? > >>> > >>> A veure si hi ha sort. > >>> > >>> > >>> Salutacions, > >>> Jordi > >>> > >>> -- > >>> Para ser realmente grande, hay que estar con la gente, no por encima de > >>> ella. > >>> > >>> > >>> 2017-11-23 14:02 GMT+01:00 Narcis Garcia <debianli...@actiu.net>: > >>>> No sabia que GRUB2 ja s'espabilava directament amb RAID. Ho fa GRUB1 ? > >>>> > >>>> He tingut oportunitat de provar amb un disc dur de 20GB (dins els límits > >>>> de la BIOS): > >>>> /dev/sda1 Ext4 1GB per /boot > >>>> /dev/sda2 Ext4 10GB per l'arrel > >>>> Resultat: Després d'instal·lar bé, no arrenca amb el mateix missatge. > >>>> Aleshores, de qualsevol manera GRUB2 en un i586 autèntic no reconeix els > >>>> sistemes de fitxers quan hi ha 2 particions al mateix disc. > >>>> > >>>> Vist això, avui també he provat la suggerència de Jordi Miguel: > >>>> /dev/sda1 (els 32GiB) volum per a RAID > >>>> /dev/sdb1 (els 32GiB) volum per a RAID > >>>> /dev/sdc1 (els 32GiB) volum per a RAID > >>>> -> /dev/md0 (els 100GB) Ext4 per l'arrel. > >>>> Resultat: Després d'instal·lar bé, no arrenca. Els missatges: > >>>> > >>>> error: failure reading sector 0xb30 from `fd0´. > >>>> error: disk `mduuid/a867853f5e9773488fa4911285e2db93´ not found. > >>>> Entering rescue mode... > >>>> grub rescue> _ > >>>> > >>>> Hauria de sacrificar tot el primer disc només per /boot fora del RAID? > >>>> > >>>> > >>>> __ >
Re: (deb-cat) GRUB2, BIOS, LBA, mdadm
Sembla ser que el GRUB no està veient els dispositius RAID. Podries executar a la shell de GRUB el següent i enviar-nos la sortida?? grub> insmod mdraid # (podria ser que es digues "raid" a seques, no estic segur del nom ara) grub> ls Salutacions, Jordi -- Para ser realmente grande, hay que estar con la gente, no por encima de ella. 2017-11-23 15:38 GMT+01:00 Narcis Garcia <debianli...@actiu.net>: > Deshabilitant la disquetera de 1.44K, la única diferència és que > desapareix el missatge sobre «fd0». Tinc entès que seria possible > configurar el mapa d'unitats de GRUB per tal que ometi unitats com fd0. > > grub rescue> ls > (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) (hd2) (hd2,msdos1) > > grub rescue> ls (hd0,msdos1)/ > error: unknown filesystem. > > > __ > I'm using this express-made address because personal addresses aren't > masked enough at this mail public archive. Public archive administrator > should fix this against automated addresses collectors. > > El 23/11/17 a les 15:25, Jordi Miguel ha escrit: >> Donades les linies d'error que ens has posat sembla que la unitat de >> disquet (fd0) de l'ordinador esta en conflicte amb el GRUB, ja sigui >> per un bug o un altre motiu que desconec. Podries provar a desactivar >> de la BIOS la unitat de disquet (i ja posats desendollar-la del >> ordinador per estar segurs) i provar-ho de nou? >> Si a la consola del Grub executes un "ls", quines particions veu? Ens >> pots enviar l'output? >> >> A veure si hi ha sort. >> >> >> Salutacions, >> Jordi >> >> -- >> Para ser realmente grande, hay que estar con la gente, no por encima de ella. >> >> >> 2017-11-23 14:02 GMT+01:00 Narcis Garcia <debianli...@actiu.net>: >>> No sabia que GRUB2 ja s'espabilava directament amb RAID. Ho fa GRUB1 ? >>> >>> He tingut oportunitat de provar amb un disc dur de 20GB (dins els límits >>> de la BIOS): >>> /dev/sda1 Ext4 1GB per /boot >>> /dev/sda2 Ext4 10GB per l'arrel >>> Resultat: Després d'instal·lar bé, no arrenca amb el mateix missatge. >>> Aleshores, de qualsevol manera GRUB2 en un i586 autèntic no reconeix els >>> sistemes de fitxers quan hi ha 2 particions al mateix disc. >>> >>> Vist això, avui també he provat la suggerència de Jordi Miguel: >>> /dev/sda1 (els 32GiB) volum per a RAID >>> /dev/sdb1 (els 32GiB) volum per a RAID >>> /dev/sdc1 (els 32GiB) volum per a RAID >>> -> /dev/md0 (els 100GB) Ext4 per l'arrel. >>> Resultat: Després d'instal·lar bé, no arrenca. Els missatges: >>> >>> error: failure reading sector 0xb30 from `fd0´. >>> error: disk `mduuid/a867853f5e9773488fa4911285e2db93´ not found. >>> Entering rescue mode... >>> grub rescue> _ >>> >>> Hauria de sacrificar tot el primer disc només per /boot fora del RAID? >>> >>> >>> __ >>> I'm using this express-made address because personal addresses aren't >>> masked enough at this mail public archive. Public archive administrator >>> should fix this against automated addresses collectors. >>> >>> El 22/11/17 a les 19:57, Jordi Miguel ha escrit: >>>> Hola, >>>> >>>> Pq mantens la partició boot fora del RAID?? Et proposo q provis la >>>> següent config: >>>> >>>> - /dev/sda1: Partició primària de la resta, volum per a RAID >>>> - /dev/sda2: Partició primària de 1GB, volum per a RAID >>>> - /dev/sdb1: Partició primària de la resta, volum per a RAID >>>> - /dev/sdb2: Partició primària de 1GB, volum per a RAID >>>> - /dev/sdc1: Partició primària de la resta, volum per a RAID >>>> - /dev/sdc2: Partició primària de 1GB, volum per a RAID >>>> >>>> /dev/md0: RAID0 amb les 3 particions grans, formatat a ext4, per a l'arrel. >>>> /dev/md1: RAID0 amb les 3 particions petites, per a swap. >>>> >>>> Despres quan et pregunti on vols instal·lar el grub li especifiques >>>> que el vols a /dev/sda. >>>> >>>> >>>> Salutacions, >>>> Jordi >>>> -- >>>> Para ser realmente grande, hay que estar con la gente, no por encima de >>>> ella. >>>> >>>> >>>> 2017-11-22 19:49 GMT+01:00 Narcis Garcia <debianli...@actiu.net>: >>>>> Després de fer diversitat de proves amb els discs com a 32GiB de mida: >>>>> >>>>> - La mateixa distribució amb el sistema de fitxers Ext3 falla igual. &
