Re: Debian en un mòbil? Estàs de conya?

2021-10-07 Conversa Joan Albert
Hola,

> Ho vaig fer servir durant un parell d'anys un mòbil amb ubuntu touch
> (actualment em sembla que es diuen ubports: (https://ubports.com) . I bueno,
> no vaig quedar gaire content. 

En el meu cas, vaig utilitzar-lo durant més d'un any, i en vaig quedar
prou content, però és cert que encara li falta molta maduresa (tot i
així, ha millorat força).

Igual que tu, vaig tornar a Android, almenys usant LineageOS, cosa que
és millor del que m'esperava.

Salut,

-- 
Joan Albert



Re: Engegada aleatòria

2021-03-16 Conversa Joan Albert
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


signature.asc
Description: PGP signature


Re: Engegada aleatòria

2021-03-15 Conversa Joan Albert
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

2021-03-15 Conversa Joan Albert
Hola Jordi,

> 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

Gràcies per la resposta. He fet el canvi que has comentat i això és el
que he pogut treure de la comanda "sudo dmesg". No sé què podria ser
rellevant i què no, per això enganxo tot fins a l'inicialització de
systemd; espero que no sigui un problema.

Gràcies amb antelació!

[0.00] microcode: microcode updated early to revision 0xe2, date
= 2020-07-14
[0.00] Linux version 5.10.0-4-amd64
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-4-amd64
root=UUID=0ddc0be7-b651-4644-8876-3871a66513bc ro
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating
point registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
[0.00] x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
[0.00] x86/fpu: Enabled xstate features 0x1f, context size is
960 bytes, using 'compacted' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x00057fff]
usable
[0.00] BIOS-e820: [mem 0x00058000-0x00058fff]
reserved
[0.00] BIOS-e820: [mem 0x00059000-0x0009dfff]
usable
[0.00] BIOS-e820: [mem 0x0009e000-0x0009efff]
reserved
[0.00] BIOS-e820: [mem 0x0009f000-0x0009]
usable
[0.00] BIOS-e820: [mem 0x000a-0x000f]
reserved
[0.00] BIOS-e820: [mem 0x0010-0xd90fafff]
usable
[0.00] BIOS-e820: [mem 0xd90fb000-0xd95fafff]
type 20
[0.00] BIOS-e820: [mem 0xd95fb000-0xd9c7efff]
reserved
[0.00] BIOS-e820: [mem 0xd9c7f000-0xd9e7efff]
ACPI NVS
[0.00] BIOS-e820: [mem 0xd9e7f000-0xd9efefff]
ACPI data
[0.00] BIOS-e820: [mem 0xd9eff000-0xd9ef]
usable
[0.00] BIOS-e820: [mem 0xd9f0-0xde7f]
reserved
[0.00] BIOS-e820: [mem 0xf80fa000-0xf80fafff]
reserved
[0.00] BIOS-e820: [mem 0xf80fd000-0xf80fdfff]
reserved
[0.00] BIOS-e820: [mem 0xfe00-0xfe010fff]
reserved
[0.00] BIOS-e820: [mem 0x0001-0x00031f7f]
usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.40 by HP
[0.00] efi: ACPI=0xd9efe000 ACPI 2.0=0xd9efe014
SMBIOS=0xd98db000 ESRT=0xd9077660
[0.00] secureboot: Secure boot could not be determined (mode 0)
[0.00] SMBIOS 2.7 present.
[0.00] DMI: HP HP ProBook 650 G2/80FD, BIOS N76 Ver. 01.02
03/01/2016
[0.00] tsc: Detected 2400.000 MHz processor
[0.000619] e820: update [mem 0x-0x0fff] usable ==>
reserved
[0.000621] e820: remove [mem 0x000a-0x000f] usable
[0.000627] last_pfn = 0x31f800 max_arch_pfn = 0x4
[0.000631] MTRR default type: write-back
[0.000632] MTRR fixed ranges enabled:
[0.000633]   0-9 write-back
[0.000634]   A-B uncachable
[0.000635]   C-F write-protect
[0.000636] MTRR variable ranges enabled:
[0.000637]   0 base 00E000 mask 7FE000 uncachable
[0.000638]   1 base 00DC00 mask 7FFC00 uncachable
[0.000638]   2 disabled
[0.000639]   3 disabled
[0.000640]   4 disabled
[0.000640]   5 disabled
[0.000641]   6 disabled
[0.000641]   7 disabled
[0.000642]   8 disabled
[0.000642]   9 disabled
[0.000981] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC-
WT
[0.001552] last_pfn = 0xd9f00 max_arch_pfn = 0x4
[0.009443] esrt: ESRT header is not in the memory map.
[0.009450] Using GB pages for direct mapping
[0.009897] RAMDISK: [mem 0x321b7000-0x350d2fff]
[0.009903] ACPI: Early table checksum verification disabled
[0.009906] ACPI: RSDP 0xD9EFE014 24 (v02 HPQOEM)
[0.009910] ACPI: XSDT 0xD9EBC188 E4 (v01 HPQOEM SLIC-BPC
  0113)
[0.009915] ACPI: FACP 0xD9EEE000 F4 (v05 HPQOEM SLIC-BPC
 HP   0001)
[0.009920] ACPI: DSDT 0xD9EC5000 0250E4 (v02 HPQOEM 80FD

Re: Engegada aleatòria

2021-03-10 Conversa Joan Albert
> 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: Engegada aleatòria

2021-03-09 Conversa Joan Albert
Bona tarda,

Moltes gràcies per les respostes (Josep, Narcís i Xavier). Faig un nou
correu comentant els diversos punts:

> Jo començaria per provar a triar diferent nucli d'inici, al gestor
> d'arrencada (menú del GRUB). Si això fa variar el resultat, tindràs més
> pistes sobre l'origen del problema.

Efectivament! Provant el nucli/kernel 4.19 funciona, mentre que amb el
5.10.0-4 actual segueixo tenint aquest problema intermitent. Sent així,
quins podrien ser els següents passos?

> Un cop em va passar (bug de nucli, manca d'actualització de bios HP) que
> el nucli no progressava per culpa d'un dispositiu usb (càmera web Polycom).
> Per engegar l'havia de tenir desconnectat.
> Vaig actualitzar la bios i es va resoldre.

Perdó pel total desconeixement, però com s'actualitza la BIOS? :) He
buscat una mica d'informació, però no ho he vist massa clar, i
preferiria no provar coses sense estar-ne prou segur. Té alguna relació
amb el nucli?

> mira si tens al directori /boot/grub un fitxer amb el nom unicode.pf2, la
> corrupció d'aquest fitxer pot provocat l'aturada de l'arrencada.

He provat de fer el que comentaves, i ha estat en va. 
Probablement aquest fitxer no estigui corrupte.

Sembla que ens anem apropant poc a poc!

-- 
TS


signature.asc
Description: PGP signature


Engegada aleatòria

2021-03-08 Conversa Joan Albert
Bon dia debianites,

Tinc un petit problema que arrossego des de fa ja unes setmanes i crec
que ha arribat el moment de demanar ajuda.

El tema és que el meu PC de la feina, el qual corre únicament Debian
testing, fa el "burru" quan s'engega. Quasi mai s'engega a la primera,
es queda aturat a la pantalla inicial, concretament a la frase "Loading
initial ramdisk". El que acaba passant és que, després d'apagar-lo
forçosament (no em mateu, si us plau) i engegar-lo de nou moltes vegades
(provant d'endollar-lo i desendollar-lo, treure-li el connector USB del
teclat extern i posar-lo de nou, etc.), màgicament s'acaba iniciant
correctament.

La solució transitòria que he decidit de moment és simplement deixar-lo
obert 24/7, però òbviament no és la solució correcta. He buscat
informació i he estat provant varies opcions (no recordo ja quines...),
tant a respostes de Debian com de Linux en general, i no me'n surto.
Algú té almenys una idea de quin pot ser el motiu? I sobretot, com pot
ser que acabi funcionant sense fer res més que reiniciar?

Moltes gràcies amb antelació,

-- 
TS


signature.asc
Description: PGP signature


Google Summer of Code - Política

2021-02-15 Conversa Joan Albert
Bones companys i companyes,

La setmana passada vaig rebre un correu de Debian (no recordo ja quina
llista era) explicant el Google Summer of Code d'aquest any[1].

Personalment, no coneixia aquesta iniciativa, i no sé si seré l'únic a
qui li incomoda. Uns dels principals motius pels que vaig triar Debian
com a distribució és el fet de ser independent d'organitzacions i
centrat en la comunitat (en contrast amb Ubuntu, per exemple) i del seu
ús estricte de software lliure per defecte. Sent totalment parcial
respecte les empreseses GAFAM (ja no utilitzo pràcticament cap servei d'elles),
desconfio de la bona voluntat que hi pugui haver en aquest SOC.
Òbviament, Google podria organitzar-lo lliurement, però per què s'ha
d'enfatitzar oficialment des de la web de Debian i els seus canals?
Hi ha hagut mai una discussió al respecte?

Segurament ja hi ha hagut aquest debat en algun moment, simplement
m'agradaria que algú pogués donar una mica de context sobre ell.

Moltes gràcies,

[1] https://wiki.debian.org/SummerOfCode2021/ 
-- 
TS



[OT] Sector laboral - Ús de Debian/Software Lliure

2021-01-27 Conversa Joan Albert
Bona tarda,

En primer lloc, perdoneu-me si aquest fil no és adient, i espero que
algú pugui comentar-ho si és el cas.

Fa temps que tinc curiositat sobre el sector on
treballem/investiguem/estudiem els integrants d'aquesta llista,
i saber si allà utilitzem o no la nostra estimada distribució,
software lliure en general o no és el cas.

Òbviament, donaré exemple i començaré jo mateix:
Sóc un (mal anomenat) científic de dades i treballo per a una
consultoria de Barcelona. Només dues persones utilitzem sistemes
operatius GNU/Linux perquè som molt tossuts, però la resta no. Sí és
cert que disposem de màquines virtuals CentOS per a temes productius.

El meu ordinador, no cal dir-ho, utilitza Debian (testing) :D
A veure si s'anima algú més a explicar el seu cas.

Salut! 

--
Joan Albert


signature.asc
Description: PGP signature


Re: M'aconselleu? client git gràfic i senzill

2020-11-16 Conversa Joan Albert
Bones!

> Jo considero GitLab més lliure que GitHub per les següents raons:
> 
> 1. Es pot autogestionar, és a dir, obtenir el mateix programari per a
> fer-te la teva instal·lació independent.
> 2. El programari autogestionable és programari lliure (MIT/X11).
> 3. GitHub és propietat de Microsoft, corporació que camina en contra de
> les llibertats tecnològiques.

I ja posats amb aquest tema, vaig buscar plataformes de software 100%
lliure i vaig trobar dues bones opcions: Sourcehut[1] i Codeberg[2] (per
si algú tenia inquietuds amb aquest tema també).

[1] sourcehut.org
[2] codeberg.org

Salut!



Re: gafamades pel dia de la llibertat del programari???

2020-09-16 Conversa Joan Albert Erraez
Bones!

> Ni idea, heu mirat https://vikings.net ? Jo no l'he fet servir. Diuen
> que fan servir programari lliure 100% i energia renovable, però no he
> vist exactament quines ofertes de hosting fan. Potser ja no ho fan o
> potser cal posar-s'hi en contacte per saber-ho.

Té molt bona pinta Xavi, aprofito per a fer menció de Pangea 
(https://pangea.org/), que té l'afegit de ser local, i crec que es mereixen una 
menció aquí.

Disculpeu si el fil s'ha anat molt del tema :)

Salut!
Joan Albert