Utilisation TMPFS, avec erreur "Opération non Permise"

Support Debian
,
Tags: #<Tag:0x00007f9c664703b0> #<Tag:0x00007f9c664702e8>
#1

Bonjour,
j’rai un script runonce qui utilise le bout de code suivant pour créer un disque tmpfs qui me sert de zone de calcul temporaire (que je ferme ensuite):

export TMPCISDISK="/media/cisramdisk"
        [ ! -d /media/cisramdisk ] && mkdir -p $TMPCISDISK
        [ -z "`mount | grep -Ei "$TMPCISDISK"`" ] && mount -t tmpfs -o size=2048K,nodev,nosuid,noexec tmpfs $TMPCISDISK

Malheureusement, j’ai stystématiquement une erreur Operation non permise au montage. Alors que je suis en root et qu’il y a assez de mémoire disponible.
Je n’ai trouvé aucun message d’erreur dans les logs.

#2

Bonsoir @Zargos
Ca mériterait quelques explications ou simplifications, ne serait-ce que pour la lisibilité ou la compréhension:

et

PS: le copier coller du dernier bloc n’apparaît pas avec la même typographie ici

Les éléments entre [ ] sont-ils vraiment indispensables, ne serait-ce que pendant le temps de débogage ?

Essayez de remplacer la variable par sa valeur brute dans la dernière ligne pour faire la part des choses et tenter d’identifier ce qui ne va pas avant la résolution proprement dite du problème.

#3

Est-ce qu’il ne te faudrait pas spécifier les options uid voire gid ?

Sinon, pourquoi tu écris ainsi :

et non pas :

[ ! -d "${TMPCISDISK}" ] && mkdir -p ${TMPCISDISK}"

autrement dis, pourquoi tu n’utilises pas la variable que tu déclares précédemment dans la détection du répertoire ?

(perso, je préfère échapper ainsi l’utilisation des variables, mais c toi qui vois et ce n’est pas le propos de mon intervention ; mais je sais que tu as compris.)

#4

Petite digression:

C’est plus le style « développeur d’applications avec un framework Web » ou l’utilisation d’un frontend que le style « administrateur ».

Personnellement je préfère $TMPCIDISK dans ce contexte de scripting que ${TMPCIDISK} que je réserve au dev. Certains outils d’édition de code peuvent malheureusement privilégier un style plus tôt qu’un autre sans tenir compte du contexte.

Pour revenir au sujet proprement dit, dans l’état actuel des choses il convient d’identifier ou vient précisément le problème avant de le résoudre. En d’autres termes, dans un premier temps, ce n’est pas recommandé d’employer une nouvelle fois la variable: il est nécessaire de coder en dur sans même faire appel à l’utilisation d’une variable. Ceci dit, dans un second temps, c’est à dire lorsque la source du problème sera bien identifié, voir même corrigé, on pourra alors utiliser une variable autant de fois que nécessaire comme vous le proposez; c’est même généralement à privilégier au final dans un contexte professionnel donnant ainsi tout son sens et sa pertinence à votre remarque.

#5

la partie TMPCISDISK n’a rien à voir avec le problème.
Elle marche très bien. J’ai utilisé cette variable pour ne pas avoir à mettre le chemin d’accès partout.

C’est uniquement le point de montage qui pose problème.
Celui-ci fonctionnait très bien sous Debian 12.
les uid et gid sont root de toute façon.
Quand au répertoire lui même:

~# ls -l /media
total 16
drwxr-xr-x  2 root root 4096 11 août  12:56 cdrom
drwxr-xr-x  2 root root 4096  7 sept. 14:24 cisramdisk

D’un autre coté sur autre machine ca marche correctement…
me reste à trouver des logs qui me permette de savoir ce qui s’est passé…

#6

je pense que c’est lié à ma configuration « sécurisée » sur les modules du kernel.

#7

J’ai failli te soumettre l’idée, parce que ça y ressemble fortement.
Reprend ce que tu as précédemment configuré en ce sens… qui pourrait t’empêcher l’exécution réelle d’un script.

#8

J’ai appliqué la suppression de tous les modules à risques ou inutiles. Et je pense que dans l’un d’entre eux il y a une dépendance qui manque.
la difficulté c’est d’arriver à déboguer, car je n’ai rien à me mettre sous la dent pour le moment.

#9

Où une mauvaise dépendance avec des conflits de versions. J’ai recompilé hier une application (en l’occurrence la dernière version stable de PostgreSQL) et je n’arrivai tout simplement pas à lancer le serveur. L’erreur était due au fait que j’avais malencontreusement déjà installé avec apt une version antérieure de l’application. Les logs d’erreurs de lancement de l’application m’ont mis un peu sur la piste mais il a fallu les interpréter car ils relèvent plus de l’investigation que de l’indication de la provenance exacte du problème. Je suis finalement reparti sur une VM de base Debian Bookworm sans aucune version de PostgreSQL d’installée au préalable et tout est redevenu dans l’ordre; j’ai bien à présent la version 17.6 de PostgreSQL qui tourne.

#10

aucune possibilité, à moins d’un bug au niveau de l’installation de Trixie.
Il s’agit d’un système en installation directement, avec un script de postinstallation qui n’installe rien de bancal, car uniquement des repos trixie sans meme du backport.