VirtualBox su Slackware64 con supporto a guest a 32-bit

[gian_d]

Seguendo un suggerimento di Ponce di qualche anno fa (non ricordo il thread), avevo installato una Slackware 15.0 a 32 bit in macchina virtuale. Uso regolarmente questo sistema per testare i miei slackbuild su sistemi a 32 bit. Per comodità uso VirtualBox sulla current, dato che è il mio sistema predefinito, mentre i test sulla Slackware64 stable li faccio in un'altra macchina alla quale mi collego sempre con SecureShell e quindi facendo tutto da terminale.
Come al solito prima o poi saltano i problemini: oggi ho aggiornato il kernel alla versione 6.6.6 e dopo tanto tempo sono incappato in errori di compilazione dei moduli di VirtualBox.

Faccio presente che uso una vecchia versione di VirtualBox, la 6.1.32. Il motivo è che la versione funziona regolarmente con la Slack 32bit installata e ho sempre ritenuto preferibile non aggiornarla. Infatti, se provo a compilare una nuova versione (mi sembra che attualmente sia disponibile lo slackbuild per la 6.1.44) lo script si arresta impostando la variabile d'ambiente SOFTWARE_VIRTUALIZATION=yes.
Da quello che so (almeno così c'è scritto in README) questo settaggio è indispensabile per poter installare sistemi guest a 32 bit, ma è necessario che il compilatore supporti la compilazione a 32 bit e questo sembra sia possibile solo installando le multilib di AlienBob. Questo succede anche con la mia attuale versione, la 6.1.32.

A questo punto non riesco a spiegarmi l'arcano: non ricordo di aver mai installato le multilib nella mia Slackware64 e allora come è possibile che sia riuscito a compilare la 6.1.32 e farla funzionare con un guest a 32 bit? Purtroppo sono passati anni e non ricordo cosa avevo fatto, ma dubito di aver installato le multilib e poi rimosse, perché sono fortemente restio a installare pacchetti precompilati ad eccezione di quelli ufficiali rilasciati da Pat.

Ho anche provato a compilare la 6.1.44 senza impostare il flag SOFTWARE_VIRTUALIZATION ma il processo si arresta perché a quanto pare anche lo slackbuild di virtualbox deve essere riadattato per renderlo compatibile con il nuovo libxml2.

Alla fine, prima di tentare di risolvere il problema con xml, non sapendo se effettivamente mi serviva per risolvere il mio problema specifico, ho preferito cercare di risolvere il problema della compilazione dei moduli cercando la patchare la 6.1.32 e alla fine ci sono riuscito, anche se mi ci sono volute ore e pazienza.

Per ora il problema è risolto, ma prima o poi dovrò affrontare seriamente quello di un aggiornamento del pacchetto di VirtualBox, perciò chiedo: è proprio necessario installare le multilib di AlienBob o posso farne a meno? Non vorrei imbarcarmi in configurazioni che poi finirebbero per aggiungere problemi ai problemi per una macchina virtuale che uso solo per uno scopo limitato.

[gian_d]

Per chi avesse un problema analogo al mio, ovvero far funzionare VirtualBox 6.1.32 sulla current aggiornata con i kernel della serie 6.6, queste sono le modifiche che ho apportato:

1) nello slackbuild ho aggiunto le seguenti righe:

Codice: Seleziona tutto

sed -i ./vboxdrv/r0drv/linux/memobj-r0drv-linux.c -e "s/pte_offset_map/pte_offset_kernel/g"

patch -p1 < $CWD/linux-6.6.patch

Il codice della patch è il seguente:

Codice: Seleziona tutto

--- ./vboxdrv/r0drv/linux/memobj-r0drv-linux.c
+++ ./vboxdrv/r0drv/linux/memobj-r0drv-linux.c
@@ -1236,6 +1236,9 @@
                                 fWrite,                 /* force write access. */
 # endif
-                                &pMemLnx->apPages[0],   /* Page array. */
-                                papVMAs);               /* vmas */
+                                &pMemLnx->apPages[0]    /* Page array. */
+# if GET_USER_PAGES_API < KERNEL_VERSION(6, 5, 0)
+                                , papVMAs               /* vmas */
+# endif
+                                );
         /*
          * Actually this should not happen at the moment as call this function
@@ -1258,6 +1258,8 @@
                                 fWrite,                 /* force write access. */
 # endif
-                                &pMemLnx->apPages[0],   /* Page array. */
-                                papVMAs                 /* vmas */
+                                &pMemLnx->apPages[0]    /* Page array. */
+# if GET_USER_PAGES_API < KERNEL_VERSION(6, 5, 0)
+                                , papVMAs               /* vmas */
+# endif
 # if GET_USER_PAGES_API >= KERNEL_VERSION(4, 10, 0)
                                 , NULL                  /* locked */
@@ -1301,7 +1301,13 @@
             while (rc-- > 0)
             {
                 flush_dcache_page(pMemLnx->apPages[rc]);
+# if GET_USER_PAGES_API < KERNEL_VERSION(6, 5, 0)
+#  if RTLNX_VER_MIN(6,3,0)
+                vm_flags_set(papVMAs[rc], VM_DONTCOPY | VM_LOCKED);
+#  else
                 papVMAs[rc]->vm_flags |= VM_DONTCOPY | VM_LOCKED;
+#  endif
+# endif
             }
 
             LNX_MM_UP_READ(pTask->mm);
@@ -1771,7 +1771,10 @@
                     /* Thes flags help making 100% sure some bad stuff wont happen (swap, core, ++).
                      * See remap_pfn_range() in mm/memory.c */
-#if    RTLNX_VER_MIN(3,7,0)
+
+#if    RTLNX_VER_MIN(6,3,0)
+                    vm_flags_set(vma, VM_DONTEXPAND | VM_DONTDUMP);
+#elif  RTLNX_VER_MIN(3,7,0)
                     vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
 #else
                     vma->vm_flags |= VM_RESERVED;
 #endif

--- ./vboxnetflt/linux/VBoxNetFlt-linux.c
+++ ./vboxnetflt/linux/VBoxNetFlt-linux.c
@@ -38,4 +38,7 @@
 # include <linux/nsproxy.h>
 #endif
+#if RTLNX_VER_MIN(6,4,10) || RTLNX_RHEL_MAJ_PREREQ(9,4)
+# include <net/gso.h>
+#endif
 #include <linux/netdevice.h>
 #if RTLNX_VER_MAX(2,6,29) || RTLNX_VER_MIN(5,11,0)

La patch l'ho elaborata per tentativi apportando le modifiche estrapolate da un confronto con i codici dei sorgenti delle nuove versioni rilasciate di VirtualBox. Mi è andata bene perché alla fine non c'era molto da modificare, se non aggiungere i nuovi fix man mano che intercettavo gli errori.

[targzeta]

Grande!