Linux Day 2026 – Aperta la Call for Papers

Sabato 24 ottobre torna il Linux Day, la principale conferenza comunitaria italiana dedicata al software libero, alla cultura aperta e alla condivisione. L’evento comprenderà una giornata gratuita di talk, laboratori e comunità attorno a Linux, al software libero e alla cultura open.

Come l’anno scorso, anche quest’anno il GOLEM organizzerà il Linux Day nella città di Prato, insieme a LuccaLUG, GULLi e ovviamente PLUG.

La call for papers è aperta fino al 15 settembre: il Linux Day è fatto dalle persone che lo raccontano. Hai un progetto, un’idea o un’esperienza da condividere? Manda la tua proposta.

You need to load the kernel first (parte 2)

Dopo anni di modalità BIOS Legacy ho effettuato il passaggio a UEFI per sfruttarne alcune delle sue caratteristiche.
Andrà quindi reinstallato grub in modalità EFI, ma per mia paranoia maggiore sicurezza ho aggiunto anche altre due alternative “salva” boot:

  • refind: un Bootloader che può caricare kernel o EFI stub presenti nella partizione EFI di boot. Rinominandolo come /EFI/BOOT/bootx64.efi il sistema lo caricherà di default quando non trova altre immagini disponibili
  • EFI stub realizzata con Buildroot contenente kernel + ramdisk con varie utility di rescue. In meno di 30MB si riesce ad avere un sistema con driver ethernet, wifi, busybox completo, RAID, BTRFS…

    Occorre fare attenzione ad alcune cose: l’immagine Buildroot va creata in modo che l’initrd sia linkata nel kernel creando così un solo file all-inclusive.
    # make menuconfig
    Filesystem images —>
    seleziona initial RAM filesystem linked into the kernel (cpio)

    Nel kernel va abilitato il supporto all’EFI stub affinché l’immagine creata sia in formato .efi e dato che UEFI funziona via framebuffer anche questo va abilitato altrimenti lo schermo rimarrà fisso al logo del bootloader.
    # make linux-menuconfig
    Processor type and features —>
    EFI runtime service support —>
    EFI stub supportDevice Drivers —>
    Graphics support —>
    Frame buffer Devices —>
    Support for frame buffer devices —>
    EFI-based Framebuffer Support

You need to load the kernel first (parte 1)

Avete presente quella sensazione di sconforto che si prova quando, dopo un aggiornamento, il sistema si blocca su una misera shell di ripristino privandoci del nostro rassicurante login grafico? Incasinare l’avvio di Linux è un’eventualità piuttosto probabile: sovrascrittura del MBR, aggiornamenti di kernel e bootloader, apt-get dist-upgrade… In questi casi spesso non resta che dover recuperare un LiveCD, chrootarsi o addirittura reinstallare tutto.
Cosa si può fare per prevenirlo?

Svariati anni fa, ai tempi in cui “la mia vita fin lì, entrava tutta dentro uno Iomega ZIP”, nel tentativo compilare un nuovo kernel per una RedHat riuscii nell’impresa di cancellare tutti i file vmlinuz-* in /boot ad eccezione del mio. Risultato? Sistema bloccato perché mancavano i driver per montare il filesystem. Da allora tengo sempre almeno due kernel funzionanti e testati in /boot.

Per i successivi 22 anni ho dormito sogni tranquilli, tra snapshots di btrfs e kernel di scorta, finché dopo un aggiornamento di grub su Archlinux mi sono ritrovato con un sistema non avviabile. Tutto risolvibile con un LiveCD, arch-chroot e grub-install… ma è stato fastidioso e nel prossimo articolo vedremo qualche accorgimento per salvarci le chiappe il boot anche nei casi più disperati.

Sondaggio 3

i486

Scrivendo l’articolo NO GRAPHIC NO PARTY mi sono accorto che non esistono distribuzioni moderne capaci di girare su un 486.

La soluzione più semplice è quella di costruirsi il proprio sistema Linux personalizzato con Buildroot, come descritto nella guida Linux minimale per PC i386/i486.

Con questo tool non è stato difficile realizzare un sistema Linux che supportasse PCI, ISA, IDE legacy, IPV4/6, le principali schede di rete ethernet dell’epoca e degli attuali emulatori, l’hotplug; che comprendesse busybox completo, svariati tool come iptables, nano, openssl, dropbear, ncftp, lynx, mutt, mpg123 e si accontentasse di un 486 con 24MB RAM ed un hard disk da 40MB.

Realizzare un sistema Linux recente per i386 è invece fuori discussione, anche usando l’ultimo kernel disponibile per 386 (3.7.10) ed un buildroot di una decina di anni fa è si fa molta fatica a stare sotto alle 16MB RAM. In questo caso conviene accontentarsi di una vecchia distro floppy minimale.