Reprise du message précédent :
Déjà fait, j'avais une prio 600 sur les sources Netgear.
 
Là on dirait plus une dépendance à la con non satisfaite.

libc6 c'est pas exactement une dépendance à la con, c'est un peu LE paquet indispensable à tout.  
 
Franchement, tu risque de galérer. Y'a pas moyen de mettre un truc totalement Open sur ce NAS, genre OpenWRT pour les routeurs?

Essaye de comprendre pourquoi il veut pas upgrade libc-bin dans la même version que libc6.

 
Pour moi il cherche une libc6 issue de Stretch.
 
Si je tente le downgrade, ça casse ailleurs :
 

Bah libc y'a tout qui dépend de ça. Perso je dirais tu n'as presque aucune chance, sauf peut-être à investir potentiellement beaucoup de temps. Comme je disais, y'a pas un firmware alternatif libre?

systemd a encore frappé, can't mount boot-efi.mount  

bon bah reboot sur un ancien rollback, via snapper modifiy --defaut --read-write <chiffre>, suppression des snapshots qui ne bootent plus (snapper rm <chiffre> ), update-grub fait qui m'indique seulement les snapshots restants (et qui bootent), mais au redémarrage du pc, j'ai toujours l'ancien grub qui m'affiche des snapshots que je viens de supprimer mais qui sont là et qui tentent de booter (mais ca fini en can't mont boot-efi.mount).
Mystère...

Un p'tit grub-install peut être ?

Déjà tenté, je ne comprends où se planque ces snapshots fantômes.
Je vais tenter d'installer un autre kernel et voir si grub se met à jour correctement, du moins lors du boot.

J'ai recréé le lien @ dans /.snapshots/ pointant vers /.snapshots/151/snapshot/ et miracle (ou alors j'ai raté une étape), au reboot il me propose enfin le bon snapshot à booter par défaut.

Par contre, je n'ai pas compris pourquoi le lien /.snapshots/@ a été supprimé

[edit]j'ai parlé trop vite

[edit 2] ah bah un apt purge linux-image-6.8.12-amd64 et pas d'erreur.

[edit 3] grub/grub-btrfs est tout paumé, j'ai un snapshot 156 maintenant, mais /.snapshots/@ pointe toujours sur 151, et pareil pour /boot/grub/grub.cfg qui pointe sur 151 par défaut j'ai pas envie de me refaire toutes les modifs à chaque nouveau snapshot...

truc curieux après un apt upgrade ce matin, les kernel ont doublé de taille
Comme je suis en LVMCrypt avec un /boot séparé je me suis retrouvé avec la partition pleine et le apt qui crash en milieu... c'est quoi ce merdier ?
 

 
250Mb pièce alors que j'avais des fichiers de 90Mb jusqu'à hier

Bon pi c'était folklorique mais j'ai pu agrandir ma partition /boot/ \o/
 
1) pris un nouveau disque de même taille
2) refait la partition EFI et un /boot de 1Gb cette fois
3) refait la partition crypt
4) refait les LVM swap et root
5) recopier les UUID de tout le monde, y compris le lvm
6) rsync de tout  
7) yalla
 
Il faut impérativement que les nouvelles partoches prennent les UUID des anciennes, surtout le LVMCrypt, sinon ça plante au boot

Tu dois être en testing vu ce noyau?

Oui, mais quand même

Tu as regardé dans le bugtracker si y'a quelque chose?

Tout ça mériterait une compilation avec KRN et le .config du noyau stable de ta distrib' ... j'dis ça, j'dis rien

sur la stable actuelle, l'initramfs et le kernel font ~15 Mo chacun
étonnant que ça pèse autant, comme si tous les drivers du monde étaient embarqués

J'ai le package Nvidia-drivers installé, est-ce qu'il rajoute du merdier dans le kernel? Me semble que c'est du module à côté non ?

Bon, kifkif au niveau taille sur mon ordinateur portable fraîchement installé en testing

EDIT: Visiblement c'est répertorié https://migrateq.io/lists/debian-user/msg02353.html

EDIT2: sur mon portable il y avait le package firmware-nvidia-graphics alors qu'il n'y en avait pas besoin. Je l'ai viré, update-initramfs et le fichiers est revenu à ses 80Mb. Il y a donc de la lolerie de firmware en trop sur ma machine vu que par défaut j'installe les firmware non-free, a rajoute peut être un peu de merde.

Ah bah pareil. Testing aussi.

D'autant qu'en virant le 6.9.9 pour remettre 6.9.8 celn dernier s'est aussi mis à faire 275Mo, et le apt remove du 6.9.9 continuait de vouloir recréer un initrd.img pour celui-ci alors qu'il devait se faire désinstaller.

Résultat je suis parti dans un putain de périple pour réduire le volume chiffré pour ensuite réduire toutes les couches LVM (LV/PV) puis LUKS, déplacer les partitions et redimensionner le /boot à une taille de 2.5Go au lieu des 500Mo d'origine.

Non sans douleur (merci cryptsetup qui veut pas fermer un device ouvert même si les partitions n'ont pas été montées), la réinstallation de GRUB etc.

Je sais pas ce qu'ils ont foutu

Périple idem mais du coup je sais que c'est possible à faire

Voir mes post suivants

Bon par contre il y a un truc con sous Mate, par défaut Super+T ouvre le Mate Terminal mais moi j'veux pas lui Je n'ai pas trouvé où était configuré ce raccourci

En effet j'ai lu après.

Mais bon c'est bien ça m'a fait pratiquer LVM et LUKS

J'avais déjà du redimensionner du LVM (shrink en plus, pas extend) mais jamais avec LUKS.

Bonjour les calculs de nombre de secteurs etc pour pas faire des arrondis .

Le seul truc relou c'est que pour étendre le /boot qui est au début du disque avec de l'espace qui est à la fin j'ai du finir avec gparted pour décaler le volume / et swap et avoir l'espace libre au bon endroit

En vrai j'ai du réinstaller GRUB 2 fois car la première fois j'avais étendu la mauvaise partition (vu qu'elle était marquée boot/efi), ce qui m'a fait déplacer le /boot une premiere fois et donc ça ne bootait plus (meme avec grub réinstallé, il a fallu recréer l'entrée  UEFI de boot dans le BIOS). Et refaire la meme manip pour shrink la partition EFI et déplacer/etendre la bonne /boot et  (et idem recreer l'entrée UEFI puisqu'elle avait rebougé).

Ca faisait longtemps que j'avais pas du bidouiller

La dernière fois c'était pour upgrader la partie LUKS à cause d'une faille.

Pour vos soucis de initrd trop gros, dans /etc/initramfs-tools/initramfs.conf, vous avez :
MODULES=most
ou :
MODULES=dep
?

c'est surement lié à LVM
meme si non monté, le lvm devient actif des que cryptsetup ouvre le volume.
du coup, faut faire un  

pour pouvoir fermer le volume avec cryptsetup.
me suis fait aussi avoir plusieurs fois

Je suis full xfs, ça ne supporte pas le shrink

Et la beauté du truc c'est qu'évidemment cette commande ne marchait pas ! Meme en l'appliquant je voyais toujours le volume LUKS actif en regardant dans dmsetup.

Je suis en "most" faudrait passer en "dep" du coup !

EDIT: bigre, je suis passé à 20Mb sur mon portable merci !

Firefox 128 https://michael.kjorling.se/blog/20 [...] refox-128/
Chez moi la coche est grisée depuis la mise à jour vers 128, est-ce un comportement du paquet debian d'unstable ?
J'ai rajouté dom.private-attribution.submission.enabled à false par précaution, la coche reste toujours grisée et non cochée.

Si elle est grisée, ça peut venir soit d’une extension (tu as essayé de voir sur un profil vierge de test ?), soit en effet d’une modification de Debian opérée avant l’empaquetage (c’est pas le cas avec Arch qui reste aussi vanilla que possible, et où j’ai dû la désactiver moi-même).

Mais pour le savoir, il faut voir avec un profil vierge : si c’est toujours grisé, c’est que ça vient de Debian. Si c’est accessible, c’est une extension qui la bloque sur ton profil normal (restera alors à savoir laquelle en testant après avoir désactivé chacune d’entre elles).

Même comportement avec un nouveau profile. Coche grisée.

ptet un grep sur les valeurs données dans ton articles dans etc/firefox ou genre, voir si c'est une conf

Les booléens ont jamais été sous forme de "coche" chez moi mais true/false (bon je suis pas sur debian là)
Et j'ai jamais vu d'entrées "grisées" non plus. Tout est gris dans about:config

Bref => screenshot

Ca réagit pas quand je clique dessus donc grisé.

Dans les options de FF, pas dans « about:config », pour la coche.

OK mon mauvais.
Perso (128.0.3) j'avais déjà la clé dans about:config à true.
Que je la passe a false ou true j'ai le même comportement que thana.
 
Parce qu'en fait cette sous-option dépend de "Autoriser Firefox à envoyer des données techniques et des données d’interaction à Mozilla" un peu au dessus. Si celle-ci est pas cochée, alors le truc de privacy-preserving est toujours grisé.
Et grisé est toujours décoché dans ce cas.

Salut les barbus.
 
Je refais une fresh install de debian sur un nouveau SSD, et j’aimerais bien réussir à chiffrer mon installation ce coup-ci
 
en gros j’ai un SSD de 2To, j’ai intallé windows sur une partition de 500Go ( oui je sais...).
et j’aimerais allouer le 1,5To restant à debian : une partition de ~200Go + de la data pour le reste, sous LVM chiffré.
 
Malheureusement en mode auto pour noob, ce n’est pas possible, l’install me demande de prendre tout le nvme  
 
vous auriez un petit tuto pour le faire en manuel svp?
 
Merci

Salut, c'est le setup que j'ai sur ma machine
J'ai fait ça comme ça, me semble que c'est juste.

Dans ton utilitaire de partitions
1) sélectionner la partition EFI déjà présente avec windows comme partition EFI pour ton debian (ne pas l'effacer bien entendu)
2) crée une partition avec /boot comme point de montage, je dirais 500Mb (j'ai mis 1Gb), ça va dépendre si t'es en testing ou pas (voir les blagues de kernel ci-dessus) tu peux la formater en XFS ou EXT4 (perso je suis full XFS même si on ne peut pas réduire la taille d'une partition de ce type alors que EXT4, tu peux)
3) crée un volume chiffré (l'option en tête de page) et choisis l'espace vide restant, il va te demander d'entrer ton mot de passe, pour gagner du temps tu peux "décocher" l'option où il propose d'effacer la totalité du volume.
4) entre dans le menu des volumes logiques (en tête de page)
5) créée un volume group (je ne sais pas comme c'est en français) tu peux donner le nom que tu veux genre "mongroup"
6) crée un volume logique pour ton swap si t'en a besoin, genre 4Gb et choisis "swap" comme type de partition
7) crée un autre volume avec l'espace restant, choisis ton système de fichier (XFS, EXT4, etc) et assigne ça à "/"
8) si tu veux séparer ton /home alors crée/ajuste tes volumes en fonction, perso je ne sépare plus rien.

Valide le tout et yalla

Re même question qu'à l'époque, mais --remove --force-all n'existe plus (rien pour dpkg, rien pour apt).
Comment supprimer un paquet le temps de réinstaller une bonne version, sans tenir des dépendances ?
Apt s'obstine à installer des équivalents, malgré l'utilisation de --allow-remove-essentials, et il veut que je vire plasma et d'autres choses...
J'ai essayé avec ceci, idem:

pour le contexte: un dist-upgrade hier sans vérifier ce qui a été fait (mise à jour de systemd 256 vers 252-mx...et fichier commun entre les 2, donc pas moyen de downgrade...) polkitd qui se plaint de ne pas avoir libsystemd 253 mini, plus de bluetooth, ca prend des plombes à booter, et ca spamme les logs...

Bon, fin du sujet, j'ai réinstallé une antix par dessus.
Par contre, je ne comprends pas comment on peut maintenant supprimer un paquet sans tenir compte des dépendances.

Parfait!!!!
J’ai suivi à la lettre ça a fonctionner nickel!
je te remercie

 
petit rappel, ne pas oublier ton mot de passe de chiffrement... sinon c'est mort pour récupérer tes données