Re: [sid] update-initramfs: Generating /boot/initrd.img-6.9.9-amd64 => zstd: error 70 : Write error : cannot write block : No space left on device
Le 18/07/2024 à 08:31, Sébastien NOBILI a écrit : Bonjour, Le 2024-07-17 20:17, Gaëtan Perrier a écrit : Peut-être n'y a-t-il pas assez de place pour 3 noyaux. Je n'en ai qu'un seul. Ça fait beaucoup de place occupée pour un seul noyau, et c'est assez inhabituel. En général il y en a au moins deux : le courant et le n-1 (ou le n+1 si on n'a pas encore reboot). Ici j'ai 152M d'occupés pour deux noyaux installés : ``` $ ls /boot/vmlinuz-* /boot/vmlinuz-6.1.0-22-amd64 /boot/vmlinuz-6.1.0-23-amd64 ``` Si tu n'as réellement qu'un seul noyau installé, tu as peut-être de la place perdue quelque part… Sébastien Un vieil initrd qui traîne ? Ce sont eux qui prennent de la place, surtout s'ils ont les firmware de tous les modules (ceux des cartes graphiques en particulier)
Re: [sid] update-initramfs: Generating /boot/initrd.img-6.9.9-amd64 => zstd: error 70 : Write error : cannot write block : No space left on device
Bonjour, Le 2024-07-17 20:17, Gaëtan Perrier a écrit : Peut-être n'y a-t-il pas assez de place pour 3 noyaux. Je n'en ai qu'un seul. Ça fait beaucoup de place occupée pour un seul noyau, et c'est assez inhabituel. En général il y en a au moins deux : le courant et le n-1 (ou le n+1 si on n'a pas encore reboot). Ici j'ai 152M d'occupés pour deux noyaux installés : ``` $ ls /boot/vmlinuz-* /boot/vmlinuz-6.1.0-22-amd64 /boot/vmlinuz-6.1.0-23-amd64 ``` Si tu n'as réellement qu'un seul noyau installé, tu as peut-être de la place perdue quelque part… Sébastien
Re: [sid] update-initramfs: Generating /boot/initrd.img-6.9.9-amd64 => zstd: error 70 : Write error : cannot write block : No space left on device
Le mercredi 17 juillet 2024 à 08:24 +0200, Jean-Marc a écrit : > > Le 17/07/24 à 00:52, Gaëtan Perrier a écrit : > > Bonjour, > > salut Gaëtan, > > > je rencontre un problème sur sid après les mises à jour de ce jour. > > > > Paramétrage de initramfs-tools (0.142) ... > > update-initramfs: deferring update (trigger activated) > > Traitement des actions différées (« triggers ») pour initramfs-tools > > (0.142) ... > > update-initramfs: Generating /boot/initrd.img-6.9.9-amd64 > > zstd: error 70 : Write error : cannot write block : No space left on device > > E: mkinitramfs failure zstd -q -9 -T0 70 > > update-initramfs: failed for /boot/initrd.img-6.9.9-amd64 with 1. > > dpkg: erreur de traitement du paquet initramfs-tools (--configure) : > > le sous-processus paquet initramfs-tools script post-installation > > installé a > > renvoyé un état de sortie d'erreur 1 > > Des erreurs ont été rencontrées pendant l'exécution : > > initramfs-tools > > Error: Sub-process /usr/bin/dpkg returned an error code (1) > > > > > > Pourtant il me reste de la place sur boot: > > > > Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur > > /dev/sdb2 474M 276M 170M 62% /boot > > Peut-être n'y a-t-il pas assez de place pour 3 noyaux. Je n'en ai qu'un seul. > > > Ça fait 12 ou 13 ans que je tourne avec cette partition boot sans problème. > > Est-ce qu'il y a eu des changements récents sur la conso disque des noyaux > > ? > > Difficile à dire. > > La dernière version d'apt sur sid donne aussi une indication de la place > nécessaire. > > Qu'utilises-tu pour tes mises à jour ? j'utilise apt. > > J'ai aussi fait face à ce genre de soucis avec un système installé il y > a longtemps. La taille du /boot n'est plus assez grande. > > J'ai résolu le problème en passant le paramètre MODULES=dep à la > commande update-initramfs via le fichier > /etc/initramfs-tools/conf.d/modules-dep pour n'embarquer que les modules > nécessaires. Merci, ça fonctionne ! :) Gaëtan signature.asc Description: This is a digitally signed message part
Re: [sid] update-initramfs: Generating /boot/initrd.img-6.9.9-amd64 => zstd: error 70 : Write error : cannot write block : No space left on device
Le 17 juillet 2024 Jean-Marc a écrit : > J'ai résolu le problème en passant le paramètre MODULES=dep à la commande > update-initramfs via le fichier /etc/initramfs-tools/conf.d/modules-dep pour > n'embarquer que les modules nécessaires. Sur bookworm le paramètre est dans /etc/initramfs-tools/initramfs.conf et surchargé dans /etc/initramfs-tools/conf.d/driver-policy
Re: [sid] update-initramfs: Generating /boot/initrd.img-6.9.9-amd64 => zstd: error 70 : Write error : cannot write block : No space left on device
Le 17/07/24 à 00:52, Gaëtan Perrier a écrit : Bonjour, salut Gaëtan, je rencontre un problème sur sid après les mises à jour de ce jour. Paramétrage de initramfs-tools (0.142) ... update-initramfs: deferring update (trigger activated) Traitement des actions différées (« triggers ») pour initramfs-tools (0.142) ... update-initramfs: Generating /boot/initrd.img-6.9.9-amd64 zstd: error 70 : Write error : cannot write block : No space left on device E: mkinitramfs failure zstd -q -9 -T0 70 update-initramfs: failed for /boot/initrd.img-6.9.9-amd64 with 1. dpkg: erreur de traitement du paquet initramfs-tools (--configure) : le sous-processus paquet initramfs-tools script post-installation installé a renvoyé un état de sortie d'erreur 1 Des erreurs ont été rencontrées pendant l'exécution : initramfs-tools Error: Sub-process /usr/bin/dpkg returned an error code (1) Pourtant il me reste de la place sur boot: Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/sdb2 474M276M 170M 62% /boot Peut-être n'y a-t-il pas assez de place pour 3 noyaux. Ça fait 12 ou 13 ans que je tourne avec cette partition boot sans problème. Est-ce qu'il y a eu des changements récents sur la conso disque des noyaux ? Difficile à dire. La dernière version d'apt sur sid donne aussi une indication de la place nécessaire. Qu'utilises-tu pour tes mises à jour ? J'ai aussi fait face à ce genre de soucis avec un système installé il y a longtemps. La taille du /boot n'est plus assez grande. J'ai résolu le problème en passant le paramètre MODULES=dep à la commande update-initramfs via le fichier /etc/initramfs-tools/conf.d/modules-dep pour n'embarquer que les modules nécessaires. A+ Bonne journée. Gaëtan -- Jean-Marc OpenPGP_signature.asc Description: OpenPGP digital signature
[sid] update-initramfs: Generating /boot/initrd.img-6.9.9-amd64 => zstd: error 70 : Write error : cannot write block : No space left on device
Bonjour, je rencontre un problème sur sid après les mises à jour de ce jour. Paramétrage de initramfs-tools (0.142) ... update-initramfs: deferring update (trigger activated) Traitement des actions différées (« triggers ») pour initramfs-tools (0.142) ... update-initramfs: Generating /boot/initrd.img-6.9.9-amd64 zstd: error 70 : Write error : cannot write block : No space left on device E: mkinitramfs failure zstd -q -9 -T0 70 update-initramfs: failed for /boot/initrd.img-6.9.9-amd64 with 1. dpkg: erreur de traitement du paquet initramfs-tools (--configure) : le sous-processus paquet initramfs-tools script post-installation installé a renvoyé un état de sortie d'erreur 1 Des erreurs ont été rencontrées pendant l'exécution : initramfs-tools Error: Sub-process /usr/bin/dpkg returned an error code (1) Pourtant il me reste de la place sur boot: Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/sdb2 474M276M 170M 62% /boot Ça fait 12 ou 13 ans que je tourne avec cette partition boot sans problème. Est-ce qu'il y a eu des changements récents sur la conso disque des noyaux ? A+ Gaëtan signature.asc Description: This is a digitally signed message part
Re: "I: update-initramfs is disabled (live system is running on read-only media)" ...
On Fri, Feb 16, 2024 at 06:43:19PM -0600, Albretch Mueller wrote: > On 2/16/24, to...@tuxteam.de wrote: > > On Fri, Feb 16, 2024 at 01:44:22PM -0600, Albretch Mueller wrote: [...] > > What is a "simple page" and what does "pixelation" mean in this > > context? Or is that irrelevant? > > A relatively simple, js-based web page I meant to say. Ah. A browser trying to render some thing from "out there". I see. > >> have searched and found out is that I will have to un/repack initramfs > >> ..., but I haven't found a relatively safe, complete procedure. > >> > >> How can you update the initramfs on read-only media? > > > > You can't. Initramfs resides in the boot medium. To update it, > > you have to write to said medium. > > Right on the Debian Kernel Handbook they tell you you may use > "initramfs hooks" for such things: > > > https://kernel-team.pages.debian.net/kernel-handbook/ch-update-hooks.html#s-initramfs-hooks > > even though I couldn't find exactly the > "/etc/initramfs/post-update.d/" directory used by update-initramfs > for post update hook options, I notice what seems to be a bunch of > those in: > > /usr/share/initramfs-tools/hooks/ AFAIK, those are rather to modify the result of the initramfs build in various ways (e.g. include additional software in the image, configure things in a different way, etc.). They are invoked at different steps in the build process. What you need, as others have said, is to rebuild your write-only medium. You can tell mkinitramfs to deposit its result in a regular file (option -o, the man page). How it goes to that read-only medium is left as an exercise to the reader (unless you tell us how you build that in the first place, that is :-) Usually it goes to somewhere /boot/initramfs.img, if /boot is mounted properly. Cheers -- t signature.asc Description: PGP signature
Re: "I: update-initramfs is disabled (live system is running on read-only media)" ...
On 2/16/24, to...@tuxteam.de wrote: > On Fri, Feb 16, 2024 at 01:44:22PM -0600, Albretch Mueller wrote: >> I've got a relatively old laptop with an ATI Radeon HD card, which >> firmware I can't update. Wild pixelations happen even on relatively >> simple pages not just videos. It seems to be a common problem. What I > > What is a "simple page" and what does "pixelation" mean in this > context? Or is that irrelevant? A relatively simple, js-based web page I meant to say. >> have searched and found out is that I will have to un/repack initramfs >> ..., but I haven't found a relatively safe, complete procedure. >> >> How can you update the initramfs on read-only media? > > You can't. Initramfs resides in the boot medium. To update it, > you have to write to said medium. Right on the Debian Kernel Handbook they tell you you may use "initramfs hooks" for such things: https://kernel-team.pages.debian.net/kernel-handbook/ch-update-hooks.html#s-initramfs-hooks even though I couldn't find exactly the "/etc/initramfs/post-update.d/" directory used by update-initramfs for post update hook options, I notice what seems to be a bunch of those in: /usr/share/initramfs-tools/hooks/ lbrtchx
Re: "I: update-initramfs is disabled (live system is running on read-only media)" ...
Hi, Albretch Mueller wrote: > > How can you update the initramfs on read-only media? to...@tuxteam.de wrote: > You can't. Initramfs resides in the boot medium. To update it, > you have to write to said medium. One will have to create a new read-only medium. In case the original is a Debian Live ISO: One would have to extract the initramfs file out of the ISO. If its name is not known, then the boot loader configuration file should tell. Like in /boot/grub/grub.cfg of debian-live-12.0.0-amd64-standard.iso: initrd /live/initrd.img-6.1.0-9-amd64 or in its /isolinux/live.cfg: initrd /live/initrd.img Next one would modify the extracted initramfs. (This is an adventure on its own. Other will know more about it than me.) Finally one would pack up a new ISO, taking all files from the old ISO but replacing the initramfs file by the modified one from hard disk. Roughly like in https://wiki.debian.org/RepackBootableISO#In_xorriso_load_ISO_tree_and_write_modified_new_ISO Details could be determined when the name of ISO and initramfs file is known. If it's about DVD media, it would be interesting to learn about the DVD drives at the computer which shall do the modification. Have a nice day :) Thomas
Re: "I: update-initramfs is disabled (live system is running on read-only media)" ...
On 2024-02-16 at 14:44, Albretch Mueller wrote: > I've got a relatively old laptop with an ATI Radeon HD card, which > firmware I can't update. Wild pixelations happen even on relatively > simple pages not just videos. It seems to be a common problem. What I > have searched and found out is that I will have to un/repack initramfs > ..., but I haven't found a relatively safe, complete procedure. > > How can you update the initramfs on read-only media? At a guess: * Copy the read-only media to a writable location. This is "the image tree". * Extract the initramfs from the file which contains it, into an empty directory. This is "the extracted initramfs". * Modify the files in the extracted initramfs. The result is "the updated extracted initramfs". * Create a new initramfs whose contents are the updated extracted initramfs. Copy it into the image tree. The result is "the updated image tree". * Write the updated image tree to new read-only media. Depending on what form the media is, this may require other steps first; for example, if it's a CD or DVD, you will probably need to create an ISO using a tool like genisoimage or (I think) xorriso. Read-only media is by definition not update-able. You can only create new media, using a modified copy of the files from the read-only media. I have successfully built updated versions of live-boot CDs, with updated kernels and initrd environments and so forth, using this basic method. It has been a long time, but I can confirm that it works, if done correctly. Now, if what you want to know is how to extract the initramfs... that depends on how it's compressed, which may depend on what live-system boot media you're working with, but typically it will be a gzip-compressed cpio archive. In that case, working from memory based on the last time I was doing such a thing, what you'd need to do is something like: $ mkdir /tmp/extract $ cp /path/to/image/tree/initrd.gz /tmp/extract $ gunzip /tmp/extract/initrd.gz $ mkdir /tmp/extract/extracted-initramfs $ cd /tmp/extract/extracted-initramfs $ cpio -i < ../initrd And to create a new one (without overwriting anything created during the above), you'd do something like: $ mv /tmp/extract/initrd /tmp/extract/initrd.unmodified $ cd /tmp/extract/extracted-initramfs $ find . | cpio -o > ../initrd $ gzip -9 /tmp/extract/initrd $ mv /tmp/extract/initrd.gz /path/to/image/tree/initrd.gz *DO* *NOT* just take this as a recipe to follow. Read the documentation of the programs involved, look for examples online if that documentation doesn't make things clear in your mind, and use this as a *starting point* to figure out what the correct thing to do in your circumstance actually is. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: "I: update-initramfs is disabled (live system is running on read-only media)" ...
On Fri, Feb 16, 2024 at 01:44:22PM -0600, Albretch Mueller wrote: > I've got a relatively old laptop with an ATI Radeon HD card, which > firmware I can't update. Wild pixelations happen even on relatively > simple pages not just videos. It seems to be a common problem. What I What is a "simple page" and what does "pixelation" mean in this context? Or is that irrelevant? > have searched and found out is that I will have to un/repack initramfs > ..., but I haven't found a relatively safe, complete procedure. > > How can you update the initramfs on read-only media? You can't. Initramfs resides in the boot medium. To update it, you have to write to said medium. [Rest deleted since it seems irrelevant to above question] Cheers -- t signature.asc Description: PGP signature
"I: update-initramfs is disabled (live system is running on read-only media)" ...
I've got a relatively old laptop with an ATI Radeon HD card, which firmware I can't update. Wild pixelations happen even on relatively simple pages not just videos. It seems to be a common problem. What I have searched and found out is that I will have to un/repack initramfs ..., but I haven't found a relatively safe, complete procedure. How can you update the initramfs on read-only media? $ sudo lspci | grep "VGA\|Radeon" 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler [Radeon HD 6320] $ sudo hwinfo --gfxcard 11: PCI 01.0: 0300 VGA compatible controller (VGA) [Created at pci.386] Unique ID: vSkL.bvK4VqmPxPA SysFS ID: /devices/pci:00/:00:01.0 SysFS BusID: :00:01.0 Hardware Class: graphics card Model: "ATI Wrestler [Radeon HD 6320]" Vendor: pci 0x1002 "ATI Technologies Inc" Device: pci 0x9806 "Wrestler [Radeon HD 6320]" SubVendor: pci 0x17aa "Lenovo" SubDevice: pci 0x21ec Driver: "radeon" Driver Modules: "radeon" Memory Range: 0xe000-0xefff (ro,non-prefetchable) I/O Ports: 0x3000-0x30ff (rw) Memory Range: 0xf030-0xf033 (rw,non-prefetchable) Memory Range: 0x000c-0x000d (rw,non-prefetchable,disabled) IRQ: 26 (4041584 events) I/O Ports: 0x3c0-0x3df (rw) Module Alias: "pci:v1002d9806sv17AAsd21ECbc03sc00i00" Driver Info #0: Driver Status: radeon is active Driver Activation Cmd: "modprobe radeon" Driver Info #1: Driver Status: amdgpu is active Driver Activation Cmd: "modprobe amdgpu" Config Status: cfg=new, avail=yes, need=no, active=unknown Primary display adapter: #11 $ sudo dmesg | grep --ignore-case "VGA\|video\|display\|Radeon" [0.226971] Console: colour VGA+ 80x25 [0.287622] smpboot: CPU0: AMD E-450 APU with Radeon(tm) HD Graphics (family: 0x14, model: 0x2, stepping: 0x0) [0.417444] acpi PNP0A08:00: ignoring host bridge window [mem 0x000ce000-0x000c window] (conflicts with Video ROM [mem 0x000c-0x000ce5ff]) [0.418510] pci :00:01.0: Video device with shadowed ROM at [mem 0x000c-0x000d] [0.457408] pci :00:01.0: vgaarb: setting as boot VGA device [0.457408] pci :00:01.0: vgaarb: bridge control possible [0.457408] pci :00:01.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none [0.457408] vgaarb: loaded [4.436446] ACPI: video: Video Device [VGA1] (multi-head: yes rom: no post: no) [4.436916] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:01/input/input9 [5.659994] [drm] radeon kernel modesetting enabled. [5.660219] radeon :00:01.0: vgaarb: deactivate vga console [5.662092] radeon :00:01.0: VRAM: 384M 0x - 0x17FF (384M used) [5.662100] radeon :00:01.0: GTT: 1024M 0x1800 - 0x57FF [5.662185] [drm] radeon: 384M of VRAM memory ready [5.662191] [drm] radeon: 1024M of GTT memory ready. [5.662317] radeon :00:01.0: firmware: direct-loading firmware radeon/PALM_pfp.bin [5.662374] radeon :00:01.0: firmware: direct-loading firmware radeon/PALM_me.bin [5.662433] radeon :00:01.0: firmware: direct-loading firmware radeon/SUMO_rlc.bin [5.662693] [drm] radeon: dpm initialized [5.663081] radeon :00:01.0: firmware: direct-loading firmware radeon/SUMO_uvd.bin [5.684961] radeon :00:01.0: WB enabled [5.684968] radeon :00:01.0: fence driver on ring 0 use gpu addr 0x18000c00 [5.684974] radeon :00:01.0: fence driver on ring 3 use gpu addr 0x18000c0c [5.685422] radeon :00:01.0: fence driver on ring 5 use gpu addr 0x00072118 [5.685956] radeon :00:01.0: radeon: MSI limited to 32-bit [5.686097] radeon :00:01.0: radeon: using MSI. [5.686153] [drm] radeon: irq initialized. [6.331634] radeon :00:01.0: [drm] Skipping radeon atom DIG backlight registration [6.338785] [drm] Radeon Display Connectors [6.338819] [drm] VGA-1 [6.785182] fbcon: radeondrmfb (fb0) is primary device [7.350484] radeon :00:01.0: [drm] fb0: radeondrmfb frame buffer device [7.363349] [drm] Initialized radeon 2.50.0 20080528 for :00:01.0 on minor 0 [ 25.811867] thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver $ lbrtchx
Re: update-initramfs
On Thu 13 Apr 2023 at 14:39:18 (-0600), Charles Curley wrote: > On Thu, 13 Apr 2023 13:57:04 -0500 > David Wright wrote: > > > https://lists.debian.org/debian-user/2023/04/msg00405.html > > > > I was left with a system whose Grub menu only contained entries for > > the new system, because os-prober no longer scours all the other > > partitions for OSes any more.¹ To get back to booting bullseye by > > default, the easiest way was to boot bullseye the once, and then run > > install-grub /dev/sda. Don't let me leave you with the impression that this was unexpected, or of concern to me. And the way I dealt with it was offered here to illustrate why the OP does not +need+ their kernel/initramfs backups to be mixed up with the originals in /boot/grub, or for Grub's menu to include them as a separate menuentry. Also bear in mind that the post cited, on bookworm RC1 installation, was to replicate the one made by the OP of that thread (right down to using a BIOS/GPT system), and elicit a response with more information (not forthcoming) on their "bug". > I believe the preferred way to get back to including other OSs in > grub's menu is to enable the OS prober by adding the following (if > necessary) to /etc/default/grub, un-commenting the last line, and > running update-grub. Yes, and in my footnote, I showed that you can, if you want, get the other OSes back /before/ the first reboot, remembering that that file is mounted on /target while the OS is being built by the debian-installer. > # Uncomment this to run os-prober to search for and add other OS > # installations to the grub boot menu > #GRUB_DISABLE_OS_PROBER=false All present and correct in RC1. Cheers, David.
Re: update-initramfs
On Thu, Apr 13, 2023 at 01:57:04PM -0500, David Wright wrote: os-prober no longer scours all the other partitions for OSes any more.¹ Which is wonderful--that was one of the most annoying misfeatures to have ever been enabled.
Re: update-initramfs
On Thu, 13 Apr 2023 13:57:04 -0500 David Wright wrote: > https://lists.debian.org/debian-user/2023/04/msg00405.html > > I was left with a system whose Grub menu only contained entries for > the new system, because os-prober no longer scours all the other > partitions for OSes any more.¹ To get back to booting bullseye by > default, the easiest way was to boot bullseye the once, and then run > install-grub /dev/sda. I believe the preferred way to get back to including other OSs in grub's menu is to enable the OS prober by adding the following (if necessary) to /etc/default/grub, un-commenting the last line, and running update-grub. # Uncomment this to run os-prober to search for and add other OS # installations to the grub boot menu #GRUB_DISABLE_OS_PROBER=false See: From: Cyril Brulebois To: debian-devel-annou...@lists.debian.org Cc: debian-b...@lists.debian.org Subject: Debian Installer Bookworm Alpha 2 release -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: update-initramfs
On Thu 13 Apr 2023 at 04:14:46 (+0200), Michel Verdier wrote: > Le 12 avril 2023 David Wright a écrit : > > > the menu/ is moot. I would maintain that this failure mode is rare > > enough for a reasonable penalty of having to type a few characters > > editing the Grub menu. > > > > The last time I booted a kernel that was on a different partition > > from my installed Grub, it took no more than typing 23 characters > > and a load of rubouts. (That was after installing bookworm RC1.) > > I agree with all you said. But on this point I don't follow you. Yes the > need is extremely rare. And so I was never able to remember this few > chars stance and each time rely on rescue boot to do this. So I > understand that a simple grub menu could be useful. When I tried installing bookworm RC1, which I reported in: https://lists.debian.org/debian-user/2023/04/msg00405.html I was left with a system whose Grub menu only contained entries for the new system, because os-prober no longer scours all the other partitions for OSes any more.¹ To get back to booting bullseye by default, the easiest way was to boot bullseye the once, and then run install-grub /dev/sda. So I rebooted, pressed e at the blue Grub screen to edit the first menuitem, and mangled just these lines: set root='hd0,gpt4' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4 --hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4 21c64c1c-2c0c-4376-922e-40ff9d46d08a else search --no-floppy --fs-uuid --set=root 21c64c1c-2c0c-4376-922e-40ff9d46d08a fi echo'Loading Linux 6.1.0-7-amd64 ...' linux /boot/vmlinuz-6.1.0-7-amd64 root=UUID=21c64c1c-2c0c-4376-922e-40ff9d46d08a ro quiet echo'Loading initial ramdisk ...' initrd /boot/initrd.img-6.1.0-7-amd64 to: set root='hd0,gpt5' search --no-floppy --label --set=root ezra05 linux /vmlinuz root=LABEL=ezra05 ro quiet initrd /initrd.img which sufficed to boot the default kernel on my bullseye root partition (via the symlinks, which saves having to know the version). 23 new characters: 5labelezra05LABELezra05, and lots of deletions. Running install-grub then rewrites the BIOS boot partition (/dev/sda1) with bullseye's Grub, overwriting bookworm's. (The MBR gets rewritten too, but it's unchanged.) ¹ I also tested uncommenting GRUB_DISABLE_OS_PROBER=false in /target/etc/default/grub at the point when the d-i first asks: ┌┤ [!] Install the GRUB boot loader ├─┐ This makes os-prober behave as it has done, up until bullseye. Cheers, David.
Re: update-initramfs
Le 12 avril 2023 David Wright a écrit : > the menu/ is moot. I would maintain that this failure mode is rare > enough for a reasonable penalty of having to type a few characters > editing the Grub menu. > > The last time I booted a kernel that was on a different partition > from my installed Grub, it took no more than typing 23 characters > and a load of rubouts. (That was after installing bookworm RC1.) I agree with all you said. But on this point I don't follow you. Yes the need is extremely rare. And so I was never able to remember this few chars stance and each time rely on rescue boot to do this. So I understand that a simple grub menu could be useful.
Re: update-initramfs
On Wed 12 Apr 2023 at 07:50:33 (-0400), The Wanderer wrote: > On 2023-04-12 at 07:44, Michel Verdier wrote: > > Le 12 avril 2023 The Wanderer a écrit : > > > >> Without anything more, wouldn't that just result in an extra > >> GRUB-menu entry pointing to the same copy of the kernel/etc.? > > > > Of course he can change menuentry to point to another kernel/initram > > From what I understand matters, the problem is that after he creates the > copy of the initrd, update-initramfs (as run by update-grub) fails, > because the underlying files which it thinks would be needed by an > initrd with the filename that the copy has don't exist. > > >> As I think I understand matters, the goal is to have a duplicate > >> copy of the kernel/etc. *and* a separate GRUB menu entry pointing > >> to it, so that if something blows away or otherwise messes up the > >> original the duplicate is still around to serve as a fallback. > > > > Yes if he points menuentry to the backup he got this fallback. By my reckoning, the "fallbacks" in this context are old kernel versions, kept in case the newer version of the kernel doesn't work. > The question would therefore be how to have the backup copy without > resulting in this update-initramfs failure happening. But in what other situation would you make backups, and then store them all mixed in with the active versions? > About the only possibility I can think of would be to *also* copy the > respective underlying files, so that they are available under the name > update-initramfs expects to see. That would probably make the backup - > and the process of creating it - noticeably more unwieldy, however. But why ever /process/ backup copies? Surely you just repeat backing up the latest updates whenever you've ascertained that they're good. If you place the backups under a different, non-active directory, then they won't get accidentally seen by update-initramfs and tampered with. > And it's entirely possible that there's some aspect of the process I'm > not seeing which would mean that that wouldn't work. The only minor difference I see from a typical backup scenario is that you probably want this set of backups to be quickly available for the Grub menu to read. Whether that means being included /in the menu/ is moot. I would maintain that this failure mode is rare enough for a reasonable penalty of having to type a few characters editing the Grub menu. The last time I booted a kernel that was on a different partition from my installed Grub, it took no more than typing 23 characters and a load of rubouts. (That was after installing bookworm RC1.) Cheers, David.
Re: update-initramfs
On 2023-04-12 at 07:44, Michel Verdier wrote: > Le 12 avril 2023 The Wanderer a écrit : > >> Without anything more, wouldn't that just result in an extra >> GRUB-menu entry pointing to the same copy of the kernel/etc.? > > Of course he can change menuentry to point to another kernel/initram From what I understand matters, the problem is that after he creates the copy of the initrd, update-initramfs (as run by update-grub) fails, because the underlying files which it thinks would be needed by an initrd with the filename that the copy has don't exist. >> As I think I understand matters, the goal is to have a duplicate >> copy of the kernel/etc. *and* a separate GRUB menu entry pointing >> to it, so that if something blows away or otherwise messes up the >> original the duplicate is still around to serve as a fallback. > > Yes if he points menuentry to the backup he got this fallback. The question would therefore be how to have the backup copy without resulting in this update-initramfs failure happening. About the only possibility I can think of would be to *also* copy the respective underlying files, so that they are available under the name update-initramfs expects to see. That would probably make the backup - and the process of creating it - noticeably more unwieldy, however. And it's entirely possible that there's some aspect of the process I'm not seeing which would mean that that wouldn't work. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: update-initramfs
Le 12 avril 2023 The Wanderer a écrit : > Without anything more, wouldn't that just result in an extra GRUB-menu > entry pointing to the same copy of the kernel/etc.? Of course he can change menuentry to point to another kernel/initram > As I think I understand matters, the goal is to have a duplicate copy of > the kernel/etc. *and* a separate GRUB menu entry pointing to it, so that > if something blows away or otherwise messes up the original the > duplicate is still around to serve as a fallback. Yes if he points menuentry to the backup he got this fallback.
Re: update-initramfs
On 2023-04-11 at 22:30, Michel Verdier wrote: > Le 11 avril 2023 davidson a écrit : >> I believe the OP just wants an extra entry in his grub menu that >> will boot a redundant copy of his latest working kernel. (But that >> is only my understanding, which might be wrong. OP can speak for >> himself on this point.) > > Ok to cover grub menu you just have to had it in /etc/grub.d. You > simply copy a block menuentry from /boot/grub/grub.cfg and put it in > something like /etc/grub.d/40_custom. In the copy you can change > kernel params, etc. update-grub will include it in generated > grub.cfg. Without anything more, wouldn't that just result in an extra GRUB-menu entry pointing to the same copy of the kernel/etc.? As I think I understand matters, the goal is to have a duplicate copy of the kernel/etc. *and* a separate GRUB menu entry pointing to it, so that if something blows away or otherwise messes up the original the duplicate is still around to serve as a fallback. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: update-initramfs
On Wed, 12 Apr 2023 davidson wrote: On Tue, 11 Apr 2023 davidson wrote: I haven't tried booting yet with my "5.10.0-21-amd63-kg" initrd, though. I'll leave that to you, if you want to try. Boot went fine, but it is worth mentioning that grub-update *update-grub decided that the "5.10.0-21-amd63-kg" copy of the 5.10.0-21-amd64 kernel should be the default grub entry. -- Sometimes it pays to have squirrels in your head running around making you question everything. -- Clive Robinson
Re: update-initramfs
On Tue, 11 Apr 2023 davidson wrote: On Tue, 11 Apr 2023 Marc Auslander wrote: On 4/10/2023 11:00 PM, David Wright wrote: On Mon 10 Apr 2023 at 20:17:11 (-0400), Marc Auslander wrote: I'm on Buster. In /boot I keep a copy of the current working linux named by appending -knowngood to the four files. My idea is that if an update fails, I have a recent working linux. This is different from vmlinuz.old which is the previous kernel version. The updates in question are not to the kernel but to initrd.image of course. Suddenly, update-initramfs insists in trying to first update initrd.-knowngood which of course fails because there are no underling file with that name. This never happened in the past, AFAIK. Once it fails it gives up. There seems no way to force update-initramfs to update the right kernel. [trim] # update-initramfs -u # update-initramfs: Generating /boot/initrd.img-5.10.0-21-amd64 # update-grub Generating grub configuration file ... Found linux image: /boot/vmlinuz-5.10.0-21-amd63-kg Found initrd image: /boot/initrd.img-5.10.0-21-amd63-kg Found linux image: /boot/vmlinuz-5.10.0-21-amd64 Found initrd image: /boot/initrd.img-5.10.0-21-amd64 Found linux image: /boot/vmlinuz-4.19.0-23-amd64 Found initrd image: /boot/initrd.img-4.19.0-23-amd64 Warning: os-prober will be executed to detect other bootable partitions. Its output will be used to detect bootable binaries on them and create new boot entries. done So update-grub didn't seem to complain. I haven't tried booting yet with my "5.10.0-21-amd63-kg" initrd, though. I'll leave that to you, if you want to try. Boot went fine, but it is worth mentioning that grub-update decided that the "5.10.0-21-amd63-kg" copy of the 5.10.0-21-amd64 kernel should be the default grub entry. -- Hackers are free people. They are like artists. If they are in a good mood, they get up in the morning and begin painting their pictures. -- Vladimir Putin
Re: update-initramfs
Le 11 avril 2023 davidson a écrit : > # update-initramfs -u > # update-initramfs: Generating /boot/initrd.img-5.10.0-21-amd64-kg > W: missing /lib/modules/5.10.0-21-amd64-kg Of course : /lib/modules/ is installed via package. You have to do it manually to get rid of this error. And without it you can't achieve a bootable kernel. > You didn't make backup copies of your most recent kernel, *give them > funny names*, and keep them in /boot. That is the distinction here, I > think. I don't have to do it *manually* I give funny names during build so the .deb include all is needed. And I only need backup of the package, not the /boot files. Obviously /boot is for operational files not for backup ones. > I believe the OP just wants an extra entry in his grub menu that will > boot a redundant copy of his latest working kernel. (But that is only > my understanding, which might be wrong. OP can speak for himself on > this point.) Ok to cover grub menu you just have to had it in /etc/grub.d. You simply copy a block menuentry from /boot/grub/grub.cfg and put it in something like /etc/grub.d/40_custom. In the copy you can change kernel params, etc. update-grub will include it in generated grub.cfg. > It seems to me that building and packaging like you suggest is more > work than warranted, just to make a backup copy. According to OP's > report, that simple practice used to work for him. Building a kernel is much less work than believed. And much much less complicated too. It requires apt install kernel sources, apt install deps for build, then do the build. I build with my custom make commands but I heard there is a dedicated debian stance to even more simplify this point. Overall it is much less work than manually following updates on a breaked /boot.
Re: update-initramfs
On Tue 11 Apr 2023 at 22:14:18 (+0200), zithro wrote: > I thought : > > - you can install as many kernel packages as you want, whether built > or downloaded > - updates don't automatically remove old kernels/initrd by default > > So I wonder, why handling it manually ? > What is the advantage, except for adding -confusion- ? There is one case where a kernel is silently removed, and that is when they tweak it without changing the minor number (or whatever that number is now called). IIRC it hasn't happened for quite some time; perhaps the last was in June 2020, when 4.19.118-2+deb10u1 replaced 4.19.118-2 for linux-image-4.19.0-9-amd64. Found in APT's history log with /linux-image.*\(([-0-9\.]+), \1 Cheers, David.
Re: update-initramfs
I thought : - you can install as many kernel packages as you want, whether built or downloaded - updates don't automatically remove old kernels/initrd by default So I wonder, why handling it manually ? What is the advantage, except for adding -confusion- ?
Re: update-initramfs
On Tue 11 Apr 2023 at 10:51:19 (-0400), Marc Auslander wrote: > On 4/10/2023 11:00 PM, David Wright wrote: > > On Mon 10 Apr 2023 at 20:17:11 (-0400), Marc Auslander wrote: > > > I'm on Buster. > > > > > > In /boot I keep a copy of the current working linux named by appending > > > -knowngood to the four files. My idea is that if an update fails, I > > > have a recent working linux. This is different from vmlinuz.old which > > > is the previous kernel version. The updates in question are not to > > > the kernel but to initrd.image of course. > > > > > > Suddenly, update-initramfs insists in trying to first update > > > initrd.-knowngood which of course fails because there are no > > > underling file with that name. This never happened in the past, > > > AFAIK. Once it fails it gives up. > > > > > > There seems no way to force update-initramfs to update the right kernel. [ … ] > thanks but that's the first thing I checked - it's yes, not all. But > my backup names contain the current version string. > > I'm not sure about the sort order hack. My goal is to have > update-grub see the knowngood as a bootable linux and include it in > the boot menu. That's also why .bak of initrd isn't good enough - I > need a complete copy. Oh, so it's update-grub calling update-initramfs, which could complicate things. Quite honestly, I don't see why you want to make what are essentially backup files into part of the working set for both Grub and initramfs, meaning they have to process duplicate files. Any time you have a set of files that you're happy with, why not just copy them to another directory, like /boot/backups/, adding suitable suffixes. With Grub's flexibility, it's very easy to boot from those copies instead. Press e at the blue screen, and tweak the filenames. If you forget where they are or what they're called, press c instead and go hunting with ls. Cheers, David.
Re: update-initramfs
On Tue, 11 Apr 2023 davidson wrote: On Tue, 11 Apr 2023 Michel Verdier wrote: Le 11 avril 2023 davidson a écrit : Experiment #2: see if I could tweak OP's practice enough so that update-grub would not care. ...and so that "update-initramfs -u" would not notice. -- Sometimes it pays to have squirrels in your head running around making you question everything. -- Clive Robinson
Re: update-initramfs
On Tue, 11 Apr 2023 Michel Verdier wrote:
Le 11 avril 2023 davidson a écrit :
The first experiment simply tried to replicate your observations (as I
understood them). Basically, I added "-kg" suffix to all the files in
/boot corresponding to latest installed kernel, so that I had
unsuffixed copies and "*-kg" ("knowngood") copies, and then tried
# update-initramfs -u
I don't understand a point.
Hi Michel.
To be clear, I am not the OP.
On my system I compiled kernel and thus build a linux-image-...deb
with a specific tag.
That is much more work than I did. I compiled no custom kernel. I just
made copies of the files in /boot installed from package
linux-image-5.10.0-21-amd64, and the corresponding initrd.
Here is a run of my Experiment #1, in full:
# knowngood=( /boot/*-$(uname -r) )
# for ((i=0; i<${#knowngood[@]}; i+=1)) ; do cp -a "${knowngood[i]}"
"${knowngood[i]/%/-kg}" ; done
# ls -l "${knowngood[@]}"
-rw-r--r-- 1 root root 236452 21 janv. 09:35 /boot/config-5.10.0-21-amd64
-rw-r--r-- 1 root root 29199065 10 avril 21:58 /boot/initrd.img-5.10.0-21-amd64
-rw-r--r-- 1 root root 83 21 janv. 09:35 /boot/System.map-5.10.0-21-amd64
-rw-r--r-- 1 root root 7019136 21 janv. 09:35 /boot/vmlinuz-5.10.0-21-amd64
# ls -l "${knowngood[@]/%/-kg}"
-rw-r--r-- 1 root root 236452 21 janv. 09:35 /boot/config-5.10.0-21-amd64-kg
-rw-r--r-- 1 root root 29199065 10 avril 21:58
/boot/initrd.img-5.10.0-21-amd64-kg
-rw-r--r-- 1 root root 83 21 janv. 09:35
/boot/System.map-5.10.0-21-amd64-kg
-rw-r--r-- 1 root root 7019136 21 janv. 09:35 /boot/vmlinuz-5.10.0-21-amd64-kg
# update-initramfs -u
# update-initramfs: Generating /boot/initrd.img-5.10.0-21-amd64-kg
W: missing /lib/modules/5.10.0-21-amd64-kg
W: Ensure all necessary drivers are built into the linux image!
depmod: ERROR: could not open directory /lib/modules/5.10.0-21-amd64-kg: No
such file or directory
depmod: FATAL: could not search modules: No such file or directory
cat:
/var/tmp/mkinitramfs_9UHxvD/lib/modules/5.10.0-21-amd64-kg/modules.builtin:
Aucun fichier ou dossier de ce type
find: ‘/var/tmp/mkinitramfs_9UHxvD/lib/modules/5.10.0-21-amd64-kg/kernel’:
Aucun fichier ou dossier de ce type
W: Can't find modules.builtin.modinfo (for locating built-in drivers' firmware,
supported in Linux >=5.2)
depmod: WARNING: could not open modules.order at
/var/tmp/mkinitramfs_9UHxvD/lib/modules/5.10.0-21-amd64-kg: No such file or
directory
depmod: WARNING: could not open modules.builtin at
/var/tmp/mkinitramfs_9UHxvD/lib/modules/5.10.0-21-amd64-kg: No such file or
directory
# ls -l "${knowngood[@]}"
-rw-r--r-- 1 root root 236452 21 janv. 09:35 /boot/config-5.10.0-21-amd64
-rw-r--r-- 1 root root 29199065 10 avril 21:58 /boot/initrd.img-5.10.0-21-amd64
-rw-r--r-- 1 root root 83 21 janv. 09:35 /boot/System.map-5.10.0-21-amd64
-rw-r--r-- 1 root root 7019136 21 janv. 09:35 /boot/vmlinuz-5.10.0-21-amd64
# ls -l "${knowngood[@]/%/-kg}"
-rw-r--r-- 1 root root 236452 21 janv. 09:35 /boot/config-5.10.0-21-amd64-kg
-rw-r--r-- 1 root root 5924752 10 avril 22:07
/boot/initrd.img-5.10.0-21-amd64-kg
^^^
-rw-r--r-- 1 root root 83 21 janv. 09:35
/boot/System.map-5.10.0-21-amd64-kg
-rw-r--r-- 1 root root 7019136 21 janv. 09:35 /boot/vmlinuz-5.10.0-21-amd64-kg
I install package so I have kernel and initram in /boot with the
tag. Same as your system I think ?
You didn't make backup copies of your most recent kernel, *give them
funny names*, and keep them in /boot. That is the distinction here, I
think.
And when I update-initramfs it generate right files with right
names. And never break anything on further updates.
That makes sense, of course.
So why change only filenames and not rebuild a package with a
different tag ?
I believe the OP just wants an extra entry in his grub menu that will
boot a redundant copy of his latest working kernel. (But that is only
my understanding, which might be wrong. OP can speak for himself on
this point.)
It seems to me that building and packaging like you suggest is more
work than warranted, just to make a backup copy. According to OP's
report, that simple practice used to work for him.
Myself, I was only curious to do
Experiment #1: replicate the OP's observations
and
Experiment #2: see if I could tweak OP's practice enough so that
update-grub would not care.
--
Hackers are free people. They are like artists. If they are in a good
mood, they get up in the morning and begin painting their pictures.
-- Vladimir Putin
Re: update-initramfs
Le 11 avril 2023 davidson a écrit :
> The first experiment simply tried to replicate your observations (as I
> understood them). Basically, I added "-kg" suffix to all the files in
> /boot corresponding to latest installed kernel, so that I had
> unsuffixed copies and "*-kg" ("knowngood") copies, and then tried
>
> # update-initramfs -u
I don't understand a point. On my system I compiled kernel and thus build
a linux-image-...deb with a specific tag. I install package so I have
kernel and initram in /boot with the tag. Same as your system I think ?
And when I update-initramfs it generate right files with right names. And
never break anything on further updates. So why change only filenames and
not rebuild a package with a different tag ?
Re: update-initramfs
On Tue, 11 Apr 2023 Marc Auslander wrote:
On 4/10/2023 11:00 PM, David Wright wrote:
On Mon 10 Apr 2023 at 20:17:11 (-0400), Marc Auslander wrote:
I'm on Buster.
In /boot I keep a copy of the current working linux named by appending
-knowngood to the four files. My idea is that if an update fails, I
have a recent working linux. This is different from vmlinuz.old which
is the previous kernel version. The updates in question are not to
the kernel but to initrd.image of course.
Suddenly, update-initramfs insists in trying to first update
initrd.-knowngood which of course fails because there are no
underling file with that name. This never happened in the past,
AFAIK. Once it fails it gives up.
There seems no way to force update-initramfs to update the right kernel.
Perhaps check that "all" hasn't been accidentally inserted:
$ grep update /etc/initramfs-tools/update-initramfs.conf
# Configuration file for update-initramfs(8)
# update_initramfs [ yes | all | no ]
# If set to all update-initramfs will update all initramfs
# If set to no disables any update to initramfs beside kernel upgrade
update_initramfs=yes
$
A workaround: change the sort order of the backup initrd files
by adding an appropriate prefix, like backup-knowngood-…
so the "real" ones get updated first.
Cheers,
David.
thanks but that's the first thing I checked - it's yes, not all. But my
backup names contain the current version string.
I'm not sure about the sort order hack. My goal is to have update-grub see
the knowngood as a bootable linux and include it in the boot menu. That's
also why .bak of initrd isn't good enough - I need a complete copy.
Caveat: I don't know WTH I'm doing. Also, I used a bullseye system for
experiments below, not buster.
I read update-initramfs(8) and did a couple experiments, one to
replicate your observations on my bullseye system, and then a variant
of David's version-naming hack.
Results are summarised below, in case you find them interesting.
EXPERIMENT #1
The first experiment simply tried to replicate your observations (as I
understood them). Basically, I added "-kg" suffix to all the files in
/boot corresponding to latest installed kernel, so that I had
unsuffixed copies and "*-kg" ("knowngood") copies, and then tried
# update-initramfs -u
which, as you report, targeted the "*-kg" files (and turned a 28M
initrd.img-*-kg into a 6M file... no longer warranting the suffix
"-kg").
Also (after making fresh "*-kg" copies), I tried
# update-initramfs -u -k all
which went first for the "*-kg" files, trashed the initrd.img-*-kg as
before, but then continued on to update all the other versions.
EXPERIMENT #2
The second experiment is similar to david's suggestion, but alters the
end of the name instead. (I didn't think of using a prefix.)
The manual implies that...
update-initramfs -u
...by default tries to update the "latest" kernel version. The
following result suggests that it determines which files correspond to
that "latest" version by just looking at their filenames.
So basically instead of only adding "-kg" to the files in /boot, I
decremented the last character of uname -r and *then* added "-kg", so
that it wouldn't look like a later version.
# knowngood=( /boot/*-$(uname -r) )
# for ((i=0 ; i<${#knowngood[@]}; i+=1)) ; do cp -a "${knowngood[i]}"
"${knowngood[i]/%4/3-kg}" ; done
# ls -l
total 105464
-rw-r--r-- 1 root root 206413 20 déc. 17:56 config-4.19.0-23-amd64
-rw-r--r-- 1 root root 236452 21 janv. 09:35 config-5.10.0-21-amd63-kg
-rw-r--r-- 1 root root 236452 21 janv. 09:35 config-5.10.0-21-amd64
drwxr-xr-x 5 root root 4096 11 avril 01:28 grub
-rw-r--r-- 1 root root 26109076 10 avril 21:59 initrd.img-4.19.0-23-amd64
-rw-r--r-- 1 root root 29199065 10 avril 21:58 initrd.img-5.10.0-21-amd63-kg
-rw-r--r-- 1 root root 29199065 10 avril 21:58 initrd.img-5.10.0-21-amd64
-rw-r--r-- 1 root root 3418327 20 déc. 17:56 System.map-4.19.0-23-amd64
-rw-r--r-- 1 root root 83 21 janv. 09:35 System.map-5.10.0-21-amd63-kg
-rw-r--r-- 1 root root 83 21 janv. 09:35 System.map-5.10.0-21-amd64
-rw-r--r-- 1 root root 5303616 20 déc. 17:56 vmlinuz-4.19.0-23-amd64
-rw-r--r-- 1 root root 7019136 21 janv. 09:35 vmlinuz-5.10.0-21-amd63-kg
-rw-r--r-- 1 root root 7019136 21 janv. 09:35 vmlinuz-5.10.0-21-amd64
# update-initramfs -u
# update-initramfs: Generating /boot/initrd.img-5.10.0-21-amd64
# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.10.0-21-amd63-kg
Found initrd image: /boot/initrd.img-5.10.0-21-amd63-kg
Found linux image: /boot/vmlinuz-5.10.0-21-amd64
Found initrd image: /boot/initrd.img-5.10.0-21-amd64
Found linux image: /boot/vmlinuz-4.19.0-23-amd64
Found initrd image: /boot/initrd.img-4.19.0-23-amd64
Warning: os-prober will be executed t
Re: update-initramfs
On 11 Apr 2023 16:43, Marc Auslander wrote: On 4/11/2023 9:30 AM, zithro wrote: The solution is in "man update-initramfs" : update-initramfs -c -k $KERNEL_VERSION -c creates a new initramfs -k specifies the version of the kernel This breaks when package update tries to update-initramfs. My copies have the kernel version in their names - with -knowngood appended. Breaks how ? In Bullseye you have to remove old kernels/initrd manually (with for example apt autoremove) I just checked some logs and it also worked like this in Buster You can keep as many versions as you want. Also, I found this old post on this very ML: On Thu, Dec 13, 2007 at 09:54:49PM -0500, Marc Auslander wrote: > The problem is operator (that's me) stupidity. > > I have an overloaded find so I can say find foo and have it mean > find . -name foo -print > > mkinitramfs uses find . | cpio to build the initrd.img >
Re: update-initramfs
On 4/10/2023 11:00 PM, David Wright wrote: On Mon 10 Apr 2023 at 20:17:11 (-0400), Marc Auslander wrote: I'm on Buster. In /boot I keep a copy of the current working linux named by appending -knowngood to the four files. My idea is that if an update fails, I have a recent working linux. This is different from vmlinuz.old which is the previous kernel version. The updates in question are not to the kernel but to initrd.image of course. Suddenly, update-initramfs insists in trying to first update initrd.-knowngood which of course fails because there are no underling file with that name. This never happened in the past, AFAIK. Once it fails it gives up. There seems no way to force update-initramfs to update the right kernel. Perhaps check that "all" hasn't been accidentally inserted: $ grep update /etc/initramfs-tools/update-initramfs.conf # Configuration file for update-initramfs(8) # update_initramfs [ yes | all | no ] # If set to all update-initramfs will update all initramfs # If set to no disables any update to initramfs beside kernel upgrade update_initramfs=yes $ A workaround: change the sort order of the backup initrd files by adding an appropriate prefix, like backup-knowngood-… so the "real" ones get updated first. Cheers, David. thanks but that's the first thing I checked - it's yes, not all. But my backup names contain the current version string. I'm not sure about the sort order hack. My goal is to have update-grub see the knowngood as a bootable linux and include it in the boot menu. That's also why .bak of initrd isn't good enough - I need a complete copy.
Re: update-initramfs
On 4/11/2023 9:30 AM, zithro wrote: On 11 Apr 2023 02:17, Marc Auslander wrote: I'm on Buster. In /boot I keep a copy of the current working linux named by appending -knowngood to the four files. My idea is that if an update fails, I have a recent working linux. This is different from vmlinuz.old which is the previous kernel version. The updates in question are not to the kernel but to initrd.image of course. In addition to what David wrote, why are you not using the backup facility of initramfs instead of doing it manually ? $ cat /etc/initramfs-tools/update-initramfs.conf [...] # # backup_initramfs [ yes | no ] # # Default is no # If set to no leaves no .bak backup files. backup_initramfs=yes [...] Suddenly, update-initramfs insists in trying to first update initrd.-knowngood which of course fails because there are no underling file with that name. This never happened in the past, AFAIK. Once it fails it gives up. There seems no way to force update-initramfs to update the right kernel. Ideas? RTFM ? :) The solution is in "man update-initramfs" : update-initramfs -c -k $KERNEL_VERSION -c creates a new initramfs -k specifies the version of the kernel This breaks when package update tries to update-initramfs. My copies have the kernel version in their names - with -knowngood appended.
Re: update-initramfs
On 11 Apr 2023 02:17, Marc Auslander wrote: I'm on Buster. In /boot I keep a copy of the current working linux named by appending -knowngood to the four files. My idea is that if an update fails, I have a recent working linux. This is different from vmlinuz.old which is the previous kernel version. The updates in question are not to the kernel but to initrd.image of course. In addition to what David wrote, why are you not using the backup facility of initramfs instead of doing it manually ? $ cat /etc/initramfs-tools/update-initramfs.conf [...] # # backup_initramfs [ yes | no ] # # Default is no # If set to no leaves no .bak backup files. backup_initramfs=yes [...] Suddenly, update-initramfs insists in trying to first update initrd.-knowngood which of course fails because there are no underling file with that name. This never happened in the past, AFAIK. Once it fails it gives up. There seems no way to force update-initramfs to update the right kernel. Ideas? RTFM ? :) The solution is in "man update-initramfs" : update-initramfs -c -k $KERNEL_VERSION -c creates a new initramfs -k specifies the version of the kernel
Re: update-initramfs
On Mon 10 Apr 2023 at 20:17:11 (-0400), Marc Auslander wrote: > I'm on Buster. > > In /boot I keep a copy of the current working linux named by appending > -knowngood to the four files. My idea is that if an update fails, I > have a recent working linux. This is different from vmlinuz.old which > is the previous kernel version. The updates in question are not to > the kernel but to initrd.image of course. > > Suddenly, update-initramfs insists in trying to first update > initrd.-knowngood which of course fails because there are no > underling file with that name. This never happened in the past, > AFAIK. Once it fails it gives up. > > There seems no way to force update-initramfs to update the right kernel. Perhaps check that "all" hasn't been accidentally inserted: $ grep update /etc/initramfs-tools/update-initramfs.conf # Configuration file for update-initramfs(8) # update_initramfs [ yes | all | no ] # If set to all update-initramfs will update all initramfs # If set to no disables any update to initramfs beside kernel upgrade update_initramfs=yes $ A workaround: change the sort order of the backup initrd files by adding an appropriate prefix, like backup-knowngood-… so the "real" ones get updated first. Cheers, David.
update-initramfs
I'm on Buster. In /boot I keep a copy of the current working linux named by appending -knowngood to the four files. My idea is that if an update fails, I have a recent working linux. This is different from vmlinuz.old which is the previous kernel version. The updates in question are not to the kernel but to initrd.image of course. Suddenly, update-initramfs insists in trying to first update initrd.-knowngood which of course fails because there are no underling file with that name. This never happened in the past, AFAIK. Once it fails it gives up. There seems no way to force update-initramfs to update the right kernel. Ideas?
Re: update-initramfs outside of /boot
On Sat 01 Oct 2022 at 20:07:13 +0200, Erwan David wrote: > Le 01/10/2022 à 18:25, Felix Miata a écrit : > > Erwan David composed on 2022-10-01 16:21 (UTC+0200): > > > > > My /boot is 235 MB (from deb 10 installer), however in testing I now > > > have 56MB initramfs files and update-initramfs cannot work for the 3rd > > > kernel to install (and apt autoremove keeps 2 kernels, thus at upgrade > > > there are temporarily 3 kernels). > > > I see that all the files of the initramfs are put in /boot before > > > creating the compressed image, thus the need for place. Is there a way > > > to cofigure update-initrams so that the creation of the im age is done > > > in another filesystem before instalation in /boot ? > > Alternative options: > > > > 1-Move the oldest kernel files to another filesystem, or everything, from > > /boot. > > You don't need them there until time to reboot. > > > > 2-You're not forced to keep two kernels. Remove the non-running one > > manually. > > > > 3-As Stefan already suggested, MODULES=dep. It's routine here. Big initrds > > take > > more time to load, which can be quite noticeable on old hardware. > > > > 4-Is your /boot adjacent to your swap? If yes, easily recreate both, with > > smaller > > swap, larger /boot. Don't forget to adjust fstab for UUID change of swap, > > or apply > > the one from fstab on the new. > > > My /boot is next to an encrypted lvm containing te rest of the disk. I fear > resizing /boot would require a reinstall, I'll set modules=dep It seems that a larger /boot is not an option for you. I also suspect modules=dep may not give you sufficient extra space, but it is worth a try. A lack of success with modules=dep just might propel you towards purging one or more of the installed kernels to improve the situation. -- Brian.
Re: update-initramfs outside of /boot
> Le 01/10/2022 à 18:25, Felix Miata a écrit : > > Erwan David composed on 2022-10-01 16:21 (UTC+0200): > > > >> My /boot is 235 MB (from deb 10 installer), however in testing I > >> now have 56MB initramfs files and update-initramfs cannot work for > >> the 3rd kernel to install (and apt autoremove keeps 2 kernels, > >> thus at upgrade there are temporarily 3 kernels). > >> I see that all the files of the initramfs are put in /boot before > >> creating the compressed image, thus the need for place. Is there a > >> way to cofigure update-initrams so that the creation of the im age > >> is done in another filesystem before instalation in /boot ? > > Alternative options: > > > > 1-Move the oldest kernel files to another filesystem, or > > everything, from /boot. You don't need them there until time to > > reboot. > > > > 2-You're not forced to keep two kernels. Remove the non-running one > > manually. > > > > 3-As Stefan already suggested, MODULES=dep. It's routine here. Big > > initrds take more time to load, which can be quite noticeable on > > old hardware. > > > > 4-Is your /boot adjacent to your swap? If yes, easily recreate > > both, with smaller swap, larger /boot. Don't forget to adjust fstab > > for UUID change of swap, or apply the one from fstab on the new. > > > My /boot is next to an encrypted lvm containing te rest of the disk. > I fear resizing /boot would require a reinstall, I'll set modules=dep If you happen to have extra disk space somewhere else, you could migrate your LVM to the spare disk, then shrink the 'real' LVM and move it to leave space adjacent to /boot, which you could then extend. Finally, migrate the LVM contents back (or copy them piecemeal, I don't know exactly what is possible). Whether that is simpler than a reinstallation will depend on your circumstances.
Re: update-initramfs outside of /boot
> I alreaady have compres=zstd (should be better than lzma). I'd be surprised if `zstd` compresses better than `lzma` (which itself should compress about the same as `xz`). I just tested here and I get zstd => 11049378 xz => 9989884 lzma => 9965122 Maybe with more control over the compression parameters `zstd` can be more competitive, I don't know. In any case, my quick tests do suggest that indeed changing to `lzma` probably won't help you very much (not nearly as much as changing to MODULES=dep). Stefan
Re: update-initramfs outside of /boot
Le 01/10/2022 à 18:25, Felix Miata a écrit : Erwan David composed on 2022-10-01 16:21 (UTC+0200): My /boot is 235 MB (from deb 10 installer), however in testing I now have 56MB initramfs files and update-initramfs cannot work for the 3rd kernel to install (and apt autoremove keeps 2 kernels, thus at upgrade there are temporarily 3 kernels). I see that all the files of the initramfs are put in /boot before creating the compressed image, thus the need for place. Is there a way to cofigure update-initrams so that the creation of the im age is done in another filesystem before instalation in /boot ? Alternative options: 1-Move the oldest kernel files to another filesystem, or everything, from /boot. You don't need them there until time to reboot. 2-You're not forced to keep two kernels. Remove the non-running one manually. 3-As Stefan already suggested, MODULES=dep. It's routine here. Big initrds take more time to load, which can be quite noticeable on old hardware. 4-Is your /boot adjacent to your swap? If yes, easily recreate both, with smaller swap, larger /boot. Don't forget to adjust fstab for UUID change of swap, or apply the one from fstab on the new. My /boot is next to an encrypted lvm containing te rest of the disk. I fear resizing /boot would require a reinstall, I'll set modules=dep
Re: update-initramfs outside of /boot
Erwan David composed on 2022-10-01 16:21 (UTC+0200): > My /boot is 235 MB (from deb 10 installer), however in testing I now > have 56MB initramfs files and update-initramfs cannot work for the 3rd > kernel to install (and apt autoremove keeps 2 kernels, thus at upgrade > there are temporarily 3 kernels). > I see that all the files of the initramfs are put in /boot before > creating the compressed image, thus the need for place. Is there a way > to cofigure update-initrams so that the creation of the im age is done > in another filesystem before instalation in /boot ? Alternative options: 1-Move the oldest kernel files to another filesystem, or everything, from /boot. You don't need them there until time to reboot. 2-You're not forced to keep two kernels. Remove the non-running one manually. 3-As Stefan already suggested, MODULES=dep. It's routine here. Big initrds take more time to load, which can be quite noticeable on old hardware. 4-Is your /boot adjacent to your swap? If yes, easily recreate both, with smaller swap, larger /boot. Don't forget to adjust fstab for UUID change of swap, or apply the one from fstab on the new. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: update-initramfs outside of /boot
On 2022-10-01 17:26 +0200, Erwan David wrote: > Le 01/10/2022 à 17:16, Stefan Monnier a écrit : >>> My /boot is 235 MB (from deb 10 installer), however in testing I now have >>> 56MB initramfs files and update-initramfs cannot work for the 3rd kernel to >>> install (and apt autoremove keeps 2 kernels, thus at upgrade there are >>> temporarily 3 kernels). The most sustainable solution is to increase your /boot filesystem, which unfortunately might not be convenient. >> MODULES=dep >> >> and >> >> COMPRESS=lzma >> >> in `initramfs.conf` can make a big difference. >> >> >> Stefan >> >> > I alreaady have compres=zstd (should be better than > lzma). modules=most because I do not like the "guess". MODULES=dep should be fine as long as you do not intend to move your disk to another machine. > An d It would > be a temporary mesuer since initramfs siuze keeps growing. I just do > not see the point of building it in /boot rather than eg /tmp or > another directory specified in conf. It would be possible to create the initramfs in another directory, but to ensure atomic upgrades it would have to be copied to /boot anyway _before_ unlinking the old one (if any). Otherwise the system could become unbootable if it crashes at the wrong moment. Cheers, Sven
Re: update-initramfs outside of /boot
Le 01/10/2022 à 17:16, Stefan Monnier a écrit : My /boot is 235 MB (from deb 10 installer), however in testing I now have 56MB initramfs files and update-initramfs cannot work for the 3rd kernel to install (and apt autoremove keeps 2 kernels, thus at upgrade there are temporarily 3 kernels). MODULES=dep and COMPRESS=lzma in `initramfs.conf` can make a big difference. Stefan I alreaady have compres=zstd (should be better than lzma). modules=most because I do not like the "guess". An d It would be a temporary mesuer since initramfs siuze keeps growing. I just do not see the point of building it in /boot rather than eg /tmp or another directory specified in conf.
Re: update-initramfs outside of /boot
> My /boot is 235 MB (from deb 10 installer), however in testing I now have > 56MB initramfs files and update-initramfs cannot work for the 3rd kernel to > install (and apt autoremove keeps 2 kernels, thus at upgrade there are > temporarily 3 kernels). MODULES=dep and COMPRESS=lzma in `initramfs.conf` can make a big difference. Stefan
update-initramfs outside of /boot
My /boot is 235 MB (from deb 10 installer), however in testing I now have 56MB initramfs files and update-initramfs cannot work for the 3rd kernel to install (and apt autoremove keeps 2 kernels, thus at upgrade there are temporarily 3 kernels). I see that all the files of the initramfs are put in /boot before creating the compressed image, thus the need for place. Is there a way to cofigure update-initrams so that the creation of the im age is done in another filesystem before instalation in /boot ?
[Résolu par update-initramfs -u]Devenu lenteur au boot
Je fais un résumé de mon problème résolu dans un même message, pour faciliter la recherche de ceux qui le rencontraient. Comme ça ne bootait plus après le déplacement d'une deb sur un autre disque, j’ai utilisé le net install, il y a un sous-menu pour réparer une install… De plus, l’UUID de la partition swap n’était plus le bon, car comme elle n’était plus reconnue comme tel par gparted, je fais un mkswap, ce qui a peut-être modifié l’UUID... Du coup ça bootait, mais ça restait calé des plombes après "loading initial ramdisk" J'avais corrigé l'UUID de la swap qui n'était plus le bon, mais pas fait de : # update-initramfs -u Ce qui a résolu le problème…. Envoyé avec la messagerie sécurisée Proton Mail. --- Original Message --- Le jeudi 14 juillet 2022 à 11:18, didier gaumet a écrit : > Bonjour, > > J'ai suivi ça de loin mais je crois que tu as recréé ta partition EFI, > en VFAT? > Vérifie avec un outil de partitionnement qu'elle a bien les drapeaux > "boot" et "esp" et si ce n'est pas le cas, positionne ces drapeaux pour > cette partition (avec parted c'est la commande toggle, avec gparted > c'est le menu contextuel "gérer les drapeaux", avec d'autres outils je > ne sais pas). > Une hypothèse (pas forcément judicieuse) est que la partition EFI > n'étant pas identifiée comme telle (drapeau "esp"), il y a un mécanisme > pour chercher parmi les partitions si il y en a une formatée en VFAT qui > contient des fichiers UEFI, ce qui expliquerait le délai. > Je connais très mal tout ça donc je raconte peut-être n'importe quoi: > mon intervention est un grand suppositoire ;-)
Re: No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
> Yes, and my impression/guess is that because 'apt' docs describe it > as being basically a front end with more convenient defaults for > interactive use, what happens when 'apt' is given these (or other > similar) options that it does not recognise as its own as documented > in the 'apt' man page, it behaves the same as if it handed these > options off to whatever command it runs as its back-end. I wonder if documentation for options like -s belongs only in apt-get, both in apt-get and apt or something else. Currenly, the option is accepted by apt but not documented in the man page I have on my system for apt.
Re: No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
On Thu, 8 Apr 2021 at 23:33, Marco Ippolito wrote: > Gotcha. I like the long option names there, almost all of which are > immediately > suggestive of what the change of behaviour might be: > > --simulate, --just-print, --dry-run, --recon, --no-act Yes, and my impression/guess is that because 'apt' docs describe it as being basically a front end with more convenient defaults for interactive use, what happens when 'apt' is given these (or other similar) options that it does not recognise as its own as documented in the 'apt' man page, it behaves the same as if it handed these options off to whatever command it runs as its back-end. So 'apt -s install ...' behaves like 'apt-get -s install ...'. I don't know if that's literally how it is implemented, but it's the general behaviour that I would expect. 'apt' is still under development so the details of it's behaviour might change between releases.
Re: No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
> > Where would I put the -s please? > > Explanation of how to find the answer: > He was talking about 'apt' commands. > If you read 'man apt' it hints that it is a front-end to > various 'apt-*' commands like 'apt-get'. > The hints look like "apt-get(8)" which is a reference > to the 'apt-get' man page in Section 8, which can > be read using the command: > man 8 apt-get > And if you read that man page, you can find an > explanation of the -s option when used with a > 'apt-get' command. Gotcha. I like the long option names there, almost all of which are immediately suggestive of what the change of behaviour might be: --simulate, --just-print, --dry-run, --recon, --no-act Especially: --simulate and --dry-run (for users of rsync and other commands that use the same long option name)
Re: No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
On Thu, 8 Apr 2021 at 22:23, Marco Ippolito wrote: > > And I'm a big fan of -s with commands like these, so that > > you know what's going to be changed. Then recall the command > > and remove the -s. > Where would I put the -s please? Explanation of how to find the answer: He was talking about 'apt' commands. If you read 'man apt' it hints that it is a front-end to various 'apt-*' commands like 'apt-get'. The hints look like "apt-get(8)" which is a reference to the 'apt-get' man page in Section 8, which can be read using the command: man 8 apt-get And if you read that man page, you can find an explanation of the -s option when used with a 'apt-get' command.
Re: No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
> And I'm a big fan of -s with commands like these, so that > you know what's going to be changed. Then recall the command > and remove the -s. Where would I put the -s please?
Re: No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
> I decided to let MY initramfs images go on diet > and added a little script which removes a few drivers that I certainly > don't need (checked with lsmod) and which contained lots of firmwares > and similar stuff. Creative. I liked it. Indeed the ``most'' strategy produces large files.
Re: No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
Hallo,
* Marco Ippolito [Wed, Apr 07 2021, 09:20:46AM]:
> dpkg: error processing package initramfs-tools (--configure):
> installed initramfs-tools package post-installation script subprocess
> returned
> error exit status 1
> Errors were encountered while processing:
> initramfs-tools
>
> # df -h /boot
> Filesystem Size Used Avail Use% Mounted on
> /dev/nvme0n1p1 236M 233M 0 100% /boot
That's not much if you have more than a few kernels installed. They are
simply too fat nowadays, too many drivers included. And with the "most"
strategy (which you normally want to have a bootable system), they are
just too fat nowadays. I decided to let MY initramfs images go on diet
and added a little script which removes a few drivers that I certainly
don't need (checked with lsmod) and which contained lots of firmwares
and similar stuff.
So, one _might_ try that but only on your own risk, it could render your
system unbootable. I selected those three because they contributed most
to the overall usage (unpacked initramfs image with unmkinitramfs and
checking with "du|sort -n").
$ cat /etc/initramfs-tools/hooks/zz_drop_stuff
#!/bin/sh
if ! test "$DESTDIR"; then
. /usr/share/initramfs-tools/hook-functions
fi
set -x
#experiments: radeon infiniband lpfc qla2xxx qla4xxx cxgb4 drbd nfs bfa f2fs
xfs btrfs aic7xxx gma500
for nam in i915 amdgpu ethernet
do
find ${DESTDIR} -name $nam | xargs --no-run-if-empty rm -rv
done
#USEDMODPAT=$(lsmod | grep -v " 0 " | sed -e "s, .*,,;s,_,.,g;s,$,.ko,")
#for pat in $USEDMODPAT
#do
#find ${DESTDIR} | grep "/${pat}$" || echo "WARNING: $pat not found,
essential module missing!"
That script probably should be set executable.
Best regards,
Eduard.
Re: No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
On Wed 07 Apr 2021 at 14:02:58 (-0400), Greg Wooledge wrote: > On Wed, Apr 07, 2021 at 08:40:58PM +0300, Andrei POPESCU wrote: > > While I'm a big fan of aptitude's patterns it's also not installed by > > default. For basic uses 'apt' is fine as well and supports globs: > > > > apt list --installed linux-image-4* > > > > apt purge linux-image-4.9.10-?-amd64 > > Remember that you need to quote these globs (at least the special > characters in them), or else one day you *will* get a nasty surprise > when one of them matches a file in your current working directory. And I'm a big fan of -s with commands like these, so that you know what's going to be changed. Then recall the command and remove the -s. I'm also a big fan of mv -i rather than rm, for similar reasons. Remove the files only when you're sure the system still works without them. Cheers, David.
Re: No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
Am Mittwoch, 7. April 2021, 19:40:58 CEST schrieb Andrei POPESCU: Hi Andrei, yes, you casn do this also with using apt. However, I forgot how to do this, it was a litttle bit more complicated. The syntax was something like "apt-get --purge remove `somestring` " or similar. Apt was then using regexp, and the string had to be put in backticks or ticks whatever. Really, maybe google is telling more. I just forgot, how to do it. Last time I used it many years ago and my history is not that long. :-) Best regards Hans > On Mi, 07 apr 21, 11:11:55, Marco Ippolito wrote: > > > Hi Marco, > > > > Hi Hans :) > > > > > aptitude purge ~n4.9.10-amd64-* > > > > Hadn't thought of matching a pattern, thanks. > > While I'm a big fan of aptitude's patterns it's also not installed by > default. For basic uses 'apt' is fine as well and supports globs: > > apt list --installed linux-image-4* > > apt purge linux-image-4.9.10-?-amd64 > > > (just an example, adjust as needed) > > Hope this helps, > Andrei
Re: No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
On Wed, Apr 07, 2021 at 08:40:58PM +0300, Andrei POPESCU wrote: > While I'm a big fan of aptitude's patterns it's also not installed by > default. For basic uses 'apt' is fine as well and supports globs: > > apt list --installed linux-image-4* > > apt purge linux-image-4.9.10-?-amd64 Remember that you need to quote these globs (at least the special characters in them), or else one day you *will* get a nasty surprise when one of them matches a file in your current working directory.
Re: No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
On Mi, 07 apr 21, 11:11:55, Marco Ippolito wrote: > > Hi Marco, > > Hi Hans :) > > > aptitude purge ~n4.9.10-amd64-* > > Hadn't thought of matching a pattern, thanks. While I'm a big fan of aptitude's patterns it's also not installed by default. For basic uses 'apt' is fine as well and supports globs: apt list --installed linux-image-4* apt purge linux-image-4.9.10-?-amd64 (just an example, adjust as needed) Hope this helps, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
>> where `MODULES=dep` and `COMPRESS=lzma` have made a big difference for >> me (more or less shrunk the initrd images by a factor 3-4). > Thank you. > Why did you choose lzma Vs xz or zstd, by the way? Measured diff? `lzma` and `xz` should be pretty much identical, it was a toss-up (I have a preference for `lzip` in that space, but it's not available ;-). `zstd` should compress significantly less (but is significantly faster both to compress and to uncompress). I focused on disk space usage (but I did notice that uncompression takes a non-negligible amount of time on my old Thinkpad X30 when the initrd image is large (e.g. with `modules=most`)). >> > Doubt: after this, by default old kernels will be cleaned up in >> >Bullseye Vs Buster? >> I don't think APT ever cleans up old kernels for you (at least in its >> default configuration). > Read something about it during the upgrade.. was checking here. Maybe my info is out of date then. Stefan
Re: No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
> Hi Marco, Hi Hans :) > aptitude purge ~n4.9.10-amd64-* Hadn't thought of matching a pattern, thanks.
Re: No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
> Recently that was fixed at unstable [1] I thought I had noticed a warning about this clean-up, but it does not happen during the upgrade so I run out of space. > I found a interesting manpage for this issue [2] Good catch. Functionality now in apt and purge-old-kernels got deprecated.
Re: No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
> where `MODULES=dep` and `COMPRESS=lzma` have made a big difference for > me (more or less shrunk the initrd images by a factor 3-4). Thank you. Why did you choose lzma Vs xz or zstd, by the way? Measured diff? > > Doubt: after this, by default old kernels will be cleaned up in Bullseye Vs > >Buster? > I don't think APT ever cleans up old kernels for you (at least in its > default configuration). Read something about it during the upgrade.. was checking here.
Re: No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
Le 07/04/2021 à 14:58, Stefan Monnier a écrit : What do you recommend I do? Other than purging old kernels, I also recommend you check /etc/initramfs-tools/initramfs.conf where `MODULES=dep` and `COMPRESS=lzma` have made a big difference for me (more or less shrunk the initrd images by a factor 3-4). Doubt: after this, by default old kernels will be cleaned up in Bullseye Vs Buster? I don't think APT ever cleans up old kernels for you (at least in its default configuration). Stefan I also found that firmware need space, especially amd64 graphics firmware.
Re: No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
El mié., 7 abr. 2021 14:58, Stefan Monnier escribió: > > What do you recommend I do? > > Other than purging old kernels, I also recommend you check > > /etc/initramfs-tools/initramfs.conf > > where `MODULES=dep` and `COMPRESS=lzma` have made a big difference for > me (more or less shrunk the initrd images by a factor 3-4). > Thanks I will test! > > > Doubt: after this, by default old kernels will be cleaned up in Bullseye > Vs > >Buster? > > I don't think APT ever cleans up old kernels for you (at least in its > default configuration). > Recently that was fixed at unstable [1] I found a interesting manpage for this issue [2] Regards [1] https://blog.jak-linux.org/2021/02/18/apt-2.2/ [2] https://manpages.debian.org/stretch/byobu/purge-old-kernels.1.en.html > > > Stefan > >
Re: No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
Am Mittwoch, 7. April 2021, 14:20:46 CEST schrieb Marco Ippolito: Hi Marco, just get rid of older kernels. This is may way: 1st, check your running actual kernel: uname -a Then check all installed kernel versions: ls /boot You will see several kernels. I suppose, apt-get autoremove will not unistall them, so just use aptitude with the version you want to uninstall: aptitude purge ~n4.9.10-amd64-* This will uninstall all stuff with "4.9.10-amd64-" in its name, this means kernel, headers and maybe selfcompiled kernel modules like the nvidia-stuff. Please check before saying "Y" what is going to be uninstalled. Do this with all the kernels, except the one you are actually running. This is working well for me, so good luck! Best regards Hans > Was upgrading from buster to bullseye. Space ran out, UI crashed, restarted > in recovery mode and cleaned up space. Restarted and run: > > # dpkg --configure -a > Setting up initramfs-tools (0.139) ... > update-initramfs: deferring update (trigger activated) > Processing triggers for initramfs-tools (0.139) ... > update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64 > cat: write error: No space left on device > update-initramfs: failed for /boot/initrd.img-5.10.0-5-amd64 with 1. > dpkg: error processing package initramfs-tools (--configure): > installed initramfs-tools package post-installation script subprocess > returned error exit status 1 > Errors were encountered while processing: > initramfs-tools > > # df -h /boot > Filesystem Size Used Avail Use% Mounted on > /dev/nvme0n1p1 236M 233M 0 100% /boot > > What do you recommend I do? > > Doubt: after this, by default old kernels will be cleaned up in Bullseye Vs >Buster? -- *Hans-J. Ullrich* zertifizierter Datenschutzbeauftragter zertifizierter Datenschutzauditor zertifizierter Penetrationtester zertifizierter IT-Security Professionell zertifizierter IT-Forensik Professionell zertifizierter Network Vulnerabilty Professionell
Re: No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
> What do you recommend I do? Other than purging old kernels, I also recommend you check /etc/initramfs-tools/initramfs.conf where `MODULES=dep` and `COMPRESS=lzma` have made a big difference for me (more or less shrunk the initrd images by a factor 3-4). > Doubt: after this, by default old kernels will be cleaned up in Bullseye Vs >Buster? I don't think APT ever cleans up old kernels for you (at least in its default configuration). Stefan
Re: No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
>
>
> # df -h /boot
> Filesystem Size Used Avail Use% Mounted on
> /dev/nvme0n1p1 236M 233M 0 100% /boot
>
> What do you recommend I do?
>
1. Autoremove old automatically installed stuff
$ apt purge --autoremove
2. Check packages:
$ dpkg-query --show -f='${Installed-Size}\t${Package}\t${Status}\n' | sort
-nr | head
This will give you the biggest packages (latest field should show if they
are really installed).
Find the one you do not need (old kernel probably, but be sure not to
delete the current kernel: check "uname -r" !)
Then, purge them:
apt purge "package name"
>
> Doubt: after this, by default old kernels will be cleaned up in Bullseye Vs
>Buster?
>
>
AFAIK yes, when you call "autoremove" , but one prev. kernel left untouched.
see
/etc/apt/apt.conf.d/01autoremove-kernels
or something like this
Re: No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
On Wed, Apr 07, 2021 at 09:20:46AM -0300, Marco Ippolito wrote: > # df -h /boot > Filesystem Size Used Avail Use% Mounted on > /dev/nvme0n1p1 236M 233M 0 100% /boot > > What do you recommend I do? Purge one or more of your kernel images.
No space left when: update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64
Was upgrading from buster to bullseye. Space ran out, UI crashed, restarted in recovery mode and cleaned up space. Restarted and run: # dpkg --configure -a Setting up initramfs-tools (0.139) ... update-initramfs: deferring update (trigger activated) Processing triggers for initramfs-tools (0.139) ... update-initramfs: Generating /boot/initrd.img-5.10.0-5-amd64 cat: write error: No space left on device update-initramfs: failed for /boot/initrd.img-5.10.0-5-amd64 with 1. dpkg: error processing package initramfs-tools (--configure): installed initramfs-tools package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: initramfs-tools # df -h /boot Filesystem Size Used Avail Use% Mounted on /dev/nvme0n1p1 236M 233M 0 100% /boot What do you recommend I do? Doubt: after this, by default old kernels will be cleaned up in Bullseye Vs Buster?
Re : Impossible d’utiliser update-initramfs
Bonjour à tous, Après étude de la sortie de pstree -l, il se trouve que mdadm faisait de la bouse. Je l’ai viré (je n’utilise pas de RAID) et ça semble reparti. Je reconstruis les divers initramfs (y compris de vieux noyaux au cas où) et ça semble reparti. Merci à vous, nicolas patrois : pts noir asocial -- RÉALISME M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ? P : Non... Une carte bleue suffirait...
Re: Impossible d’utiliser update-initramfs
Bonjour Peut être que lancer manuellement update-initramfs avec l'argument -v donnerait des détails utiles ? Il me semble que sur certaines de mes machines la construction peut mettre plusieurs minutes. Est ce que update-initramfs déclenche le build de modules noyau quand utilise des pilotes propriétaires comme ceux de NVIDIA, ou virtualbox ? Le 18 juillet 2020 15:01:10 GMT+02:00, nicolas.patr...@gmail.com a écrit : >Bonjour à tous, > >Lors de la dernière mise à jour, je me retrouve avec l’impossibilité de >créer ou de mettre à jour un initramfs, que ce soit un initramfs pour >le noyau 5.4.0 actuel ou lors de l’installation du 5.7.0. >J’ai cherché sur internet et aucune des solutions ne fonctionne. >En fait, update-initramfs s’arrête et ne fait plus rien. Impossible de >le tuer avec Ctrl-C, je dois tuer apt* avec SIGKILL et éventuellement >nettoyer les verrous. > >nicolas patrois : pts noir asocial >-- >RÉALISME > >M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des >humains ? Un cerveau plus gros ? >P : Non... Une carte bleue suffirait... -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Impossible d’utiliser update-initramfs
Bonjour à tous, Lors de la dernière mise à jour, je me retrouve avec l’impossibilité de créer ou de mettre à jour un initramfs, que ce soit un initramfs pour le noyau 5.4.0 actuel ou lors de l’installation du 5.7.0. J’ai cherché sur internet et aucune des solutions ne fonctionne. En fait, update-initramfs s’arrête et ne fait plus rien. Impossible de le tuer avec Ctrl-C, je dois tuer apt* avec SIGKILL et éventuellement nettoyer les verrous. nicolas patrois : pts noir asocial -- RÉALISME M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ? P : Non... Une carte bleue suffirait...
Re: KVM Debian guests fail to boot after update-initramfs
On 2020-07-09 05:11, Stewart Middleton wrote: (Wow -- lots of debugging hours there...) So it appears that `virt-resize` triggers a behavior where `update- initramfs` does not build the initramfs correctly. Could anybody give me any pointers as to either what may be wrong, or the best route to troubleshoot this further? Many thanks in advance. I would file a bug report against virt-resize and include all of your hard-earned debugging information. I would eliminate virt-resize from the workflow until the bug is fixed. Who uses the guests? Do they have root? Do they have shell accounts? Do they require Debian, CentOS, or Linux? Have you tried other host operating systems and/or hypervisors? David
KVM Debian guests fail to boot after update-initramfs
(I have already posted to the libguestfs mailing list, without any luck) I run a number of virtualisation hosts, the host OS is Debian 10 (tho this issue has also been present with 9) and the virtualisation tech is KVM. All packages are current & from 'stable'. I am encountering a problem where Debian guests, specifically built using `virt-resize`, work flawlessly until the first time `update- initramfs` is run, when they then fail to boot with the following error: "mount: mounting /dev/vda1 on /root failed: No such device" after which the system fails to the initramfs Busybox debug shell. If I use the `break=premount` kernel param to drop out of boots to the debug shell before and after `update-initramfs` is run, and then compare the output of `dmesg` it is clear that the necessary IO drivers are not being loaded after the initramfs has been rebuilt: BEFORE `update-initramfs` [0.736291] Run /init as init process [0.795060] lpc_ich :00:1f.0: I/O space for GPIO uninitialized [0.800259] PCI Interrupt Link [GSIA] enabled at IRQ 16 [0.800363] i801_smbus :00:1f.3: SMBus using PCI interrupt [0.811428] cryptd: max_cpu_qlen set to 1000 [0.821407] AVX2 version of gcm_enc/dec engaged. [0.821407] AES CTR mode by8 optimization enabled [0.823702] ACPI: bus type USB registered [0.823712] usbcore: registered new interface driver usbfs [0.823717] usbcore: registered new interface driver hub [0.823726] usbcore: registered new device driver usb [0.829766] SCSI subsystem initialized [0.830240] input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input3 [0.830430] input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input2 [0.844882] virtio_blk virtio2: [vda] 41943040 512-byte logical blocks (21.5 GB/20.0 GiB) [0.854231] vda: vda1 vda2 [0.857633] xhci_hcd :02:00.0: xHCI Host Controller [0.857638] xhci_hcd :02:00.0: new USB bus registered, assigned bus number 1 [0.857900] xhci_hcd :02:00.0: hcc params 0x00087001 hci version 0x100 quirks 0x0010 [0.859088] virtio_net virtio0 enp1s0: renamed from eth0 [0.860055] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19 [0.860056] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [0.860056] usb usb1: Product: xHCI Host Controller [0.860057] usb usb1: Manufacturer: Linux 4.19.0-9-amd64 xhci-hcd [0.860057] usb usb1: SerialNumber: :02:00.0 ... AFTER `update-initramfs` [0.743940] Run /init as init process [0.801833] lpc_ich :00:1f.0: I/O space for GPIO uninitialized [0.814263] cryptd: max_cpu_qlen set to 1000 [0.817594] input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input3 [0.817785] input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input2 [0.820087] PCI Interrupt Link [GSIA] enabled at IRQ 16 [0.820187] i801_smbus :00:1f.3: SMBus using PCI interrupt [0.829008] AVX2 version of gcm_enc/dec engaged. [0.829008] AES CTR mode by8 optimization enabled [0.839844] virtio_blk virtio2: [vda] 41943040 512-byte logical blocks (21.5 GB/20.0 GiB) [0.843734] vda: vda1 vda2 [0.846319] virtio_net virtio0 enp1s0: renamed from eth0 (In the BEFORE case I have snipped the output of `dmesg` as it just goes on to load the expected drivers, however in the case of AFTER, that is the end of the `dmesg` output) My workflow to create guests is as follows: Initially manually install a minimal 'reference' guest to a small LVM backed disk containing two partitions (/ & swap). The rest is then scripted each time I want to 'clone' a new guest from this reference: * take an LVM snapshot of the reference host disk volume * `kpartx -a` on the snapshot, to gain access to the partitions, mount / and modify two files to set hostname and IP * `kpartx -d` * create a new LVM volume at the desired size to be used as the disk for the finished guest * `virt-resize` to copy the partitions from the snapshot to the new volume, resizing swap to a fixed size and letting `virt-resize` grow / to fill the remaining space * `kpartx -a` on the new volume and then `mkswap` on the new swap partition * `kpartx -d` * define the new host in KVM using the new volume as the backing disk * `virt-sysprep -d --enable bash- history,customize,logfiles,mail-spool,package-manager-cache,ssh- hostkeys,tmp-files` to clean up ahead of first boot At this point the guest will operate flawlessly, will boot & reboot without issue. However when update-initramfs first runs (usually as part of a kernel upgrade, but this happens if it is run directly as well), the problem is then present on next boot. CentOS guests built the same way do not encounter this problem. If I skip the `virt-resize` step and either use the snapshot as the backing disk for the new guest, or `dd` the reference disk volume to
Re : Gros problème avec update-initramfs
Le 05/03/2020 00:17:08, Dethegeek a écrit : > Bonjour > De mémoire j'ai eu le souci il y a quelques mois. La cause était une > saturation du volume dédié à /boot. J’ai 1,7 Go de libre dans /boot, ça devrait suffire. Finalement, après un redémarrage bourrin (le PC a planté, je pense qu’il commence à fatiguer) sur une sauvegarde d’un initrd fait par dpkg, tout est redevenu normal : dpkg --configure -a arrive au bout et je peux de nouveau mettre à jour le système. Merci quand même. nicolas patrois : pts noir asocial -- RÉALISME M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ? P : Non... Une carte bleue suffirait...
Re: Gros problème avec update-initramfs
Bonjour De mémoire j'ai eu le souci il y a quelques mois. La cause était une saturation du volume dédié à /boot. Le 4 mars 2020 12:41:48 GMT+01:00, nicolas.patr...@gmail.com a écrit : >Bonjour, > >La mise à jour de ce matin a planté avec update-initramfs qui refuse de >finir la mise à jour d’aptitude (et de dpkg --configure -a). >update-initramfs -u -k 4.17.0-3-686-pae -v s’arrête juste après le >module raid10 que je n’utilise pas. Je l’ai blacklisté, pour voir, ça >ne change rien. >Je n’arrive même pas à tuer le processus avec CTRL-C, il me faut >suspendre le processus (CTRL-Z) et le tuer avec killall. >Voici les derniers modules ajoutés avant le plantage : >Calling hook cryptpassdev >Calling hook cryptopensc >Calling hook cryptkeyctl >Calling hook cryptgnupg-sc >Calling hook cryptgnupg >Calling hook ntfs_3g >Adding binary /bin/ntfs-3g >Adding library-link /lib/i386-linux-gnu/libntfs-3g.so.883.0.0 >Adding library /lib/i386-linux-gnu/libntfs-3g.so.883.0.0 >Calling hook reiserfsprogs >Calling hook mdadm >Adding binary /sbin/mdadm >Adding binary /sbin/mdmon >Adding module /lib/modules/4.17.0-3-686-pae/kernel/drivers/md/linear.ko >Adding module >/lib/modules/4.17.0-3-686-pae/kernel/drivers/md/multipath.ko >Adding module /lib/modules/4.17.0-3-686-pae/kernel/drivers/md/raid0.ko >Adding module /lib/modules/4.17.0-3-686-pae/kernel/drivers/md/raid1.ko >Adding module /lib/modules/4.17.0-3-686-pae/kernel/drivers/md/raid10.ko >Et là, boum. >Je n’ai aucune information supplémentaire avec strace. > >Est-ce que quelqu’un a une idée ? > >nicolas patrois : pts noir asocial >-- >RÉALISME > >M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des >humains ? Un cerveau plus gros ? >P : Non... Une carte bleue suffirait... -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Gros problème avec update-initramfs
Bonjour, La mise à jour de ce matin a planté avec update-initramfs qui refuse de finir la mise à jour d’aptitude (et de dpkg --configure -a). update-initramfs -u -k 4.17.0-3-686-pae -v s’arrête juste après le module raid10 que je n’utilise pas. Je l’ai blacklisté, pour voir, ça ne change rien. Je n’arrive même pas à tuer le processus avec CTRL-C, il me faut suspendre le processus (CTRL-Z) et le tuer avec killall. Voici les derniers modules ajoutés avant le plantage : Calling hook cryptpassdev Calling hook cryptopensc Calling hook cryptkeyctl Calling hook cryptgnupg-sc Calling hook cryptgnupg Calling hook ntfs_3g Adding binary /bin/ntfs-3g Adding library-link /lib/i386-linux-gnu/libntfs-3g.so.883.0.0 Adding library /lib/i386-linux-gnu/libntfs-3g.so.883.0.0 Calling hook reiserfsprogs Calling hook mdadm Adding binary /sbin/mdadm Adding binary /sbin/mdmon Adding module /lib/modules/4.17.0-3-686-pae/kernel/drivers/md/linear.ko Adding module /lib/modules/4.17.0-3-686-pae/kernel/drivers/md/multipath.ko Adding module /lib/modules/4.17.0-3-686-pae/kernel/drivers/md/raid0.ko Adding module /lib/modules/4.17.0-3-686-pae/kernel/drivers/md/raid1.ko Adding module /lib/modules/4.17.0-3-686-pae/kernel/drivers/md/raid10.ko Et là, boum. Je n’ai aucune information supplémentaire avec strace. Est-ce que quelqu’un a une idée ? nicolas patrois : pts noir asocial -- RÉALISME M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ? P : Non... Une carte bleue suffirait...
Re: Update-initramfs Most vs Dep
On Tuesday 22 May 2012 18:32:55 David Baron wrote: On Tuesday 22 May 2012 16:59:30 Pascal Hambourg wrote: David Baron a écrit : On Tuesday 22 May 2012 02:10:06 Pascal Hambourg wrote: You can add the missing required modules in /etc/initramfs-tools/modules and rebuild the initramfs. However, with latest initramfs-tools, I do not get a list of missing modules, You have to guess which modules are needed to mount the final root filesystem, e.g. by looking at the bottom of the output of lsmod after booting with a full initramfs. ext3 would be obvious jbd ? (dep ext3) btrfs? ata_beneric ? ata_piix ? I placed all these in modules in addition to a few others I had tried because of previous error messages. A dep update-initramfs still produces the complaint about :/ Is a directory but at least the one I tried booted! 1/3 the size. The first work-around I tried was a phony symlink rootfs-/ which can be on my home directory where I am logged in. This is what produces the complaint but enables an initrd-img to be produced. /proc/mounts certainly does have a rootfs on / so this certainly is a bug and nothing to do with the original knoppix (though I have not tried it on a pure chroot produced be debootstrap--my system will not accept a dep-based bootup sequence and that certainly could be related). -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201205231635.40992.d_ba...@012.net.il
Re: Update-initramfs Most vs Dep
On Wed, May 23, 2012 at 9:35 AM, David Baron d_ba...@012.net.il wrote: On Tuesday 22 May 2012 18:32:55 David Baron wrote: On Tuesday 22 May 2012 16:59:30 Pascal Hambourg wrote: David Baron a écrit : On Tuesday 22 May 2012 02:10:06 Pascal Hambourg wrote: You can add the missing required modules in /etc/initramfs-tools/modules and rebuild the initramfs. However, with latest initramfs-tools, I do not get a list of missing modules, You have to guess which modules are needed to mount the final root filesystem, e.g. by looking at the bottom of the output of lsmod after booting with a full initramfs. ext3 would be obvious jbd ? (dep ext3) btrfs? ata_beneric ? ata_piix ? I placed all these in modules in addition to a few others I had tried because of previous error messages. A dep update-initramfs still produces the complaint about :/ Is a directory but at least the one I tried booted! 1/3 the size. The first work-around I tried was a phony symlink rootfs-/ which can be on my home directory where I am logged in. This is what produces the complaint but enables an initrd-img to be produced. /proc/mounts certainly does have a rootfs on / so this certainly is a bug and nothing to do with the original knoppix (though I have not tried it on a pure chroot produced be debootstrap--my system will not accept a dep-based bootup sequence and that certainly could be related). Are the extra 16MB (4MB with dep and 20MB with most) that big a problem?! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=Sxfur26WxGutwaeTDi1t6Zv8+=nnuhenj1r8khklxh...@mail.gmail.com
Re: Update-initramfs Most vs Dep
On Tuesday 22 May 2012 02:10:06 Pascal Hambourg wrote: Hello, David Baron a écrit : Up until recent upgrades, it worked fine with dep producing initrd of 3.7 meg. After recent upgrades, this no longer worked. Various errors about rootfs or /root is a folder. The boot would fail at the tso point. Now have to use most and get 11 meg initrds, 5 x bigger than the whole kernel image! The excuse was that my system is a bastion one, born of Knoppix. Problem seem to me more of regression. It worked for years, what now? Anyone know of any fix or workaround? You can add the missing required modules in /etc/initramfs-tools/modules and rebuild the initramfs. However, with latest initramfs-tools, I do not get a list of missing modules, just: /: is a directory. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201205221131.53733.d_ba...@012.net.il
Re: Update-initramfs Most vs Dep
David Baron a écrit : On Tuesday 22 May 2012 02:10:06 Pascal Hambourg wrote: You can add the missing required modules in /etc/initramfs-tools/modules and rebuild the initramfs. However, with latest initramfs-tools, I do not get a list of missing modules, You have to guess which modules are needed to mount the final root filesystem, e.g. by looking at the bottom of the output of lsmod after booting with a full initramfs. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/59d7c395de399f1dcc0d27da922b600d.squir...@webmail.nerim.net
Re: Update-initramfs Most vs Dep
On Tuesday 22 May 2012 16:59:30 Pascal Hambourg wrote: David Baron a écrit : On Tuesday 22 May 2012 02:10:06 Pascal Hambourg wrote: You can add the missing required modules in /etc/initramfs-tools/modules and rebuild the initramfs. However, with latest initramfs-tools, I do not get a list of missing modules, You have to guess which modules are needed to mount the final root filesystem, e.g. by looking at the bottom of the output of lsmod after booting with a full initramfs. ext3 would be obvious jbd ? (dep ext3) btrfs? ata_beneric ? ata_piix ? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201205221832.56220.d_ba...@012.net.il
Re: Update-initramfs Most vs Dep
David Baron a écrit : On Tuesday 22 May 2012 16:59:30 Pascal Hambourg wrote: You have to guess which modules are needed to mount the final root filesystem, e.g. by looking at the bottom of the output of lsmod after booting with a full initramfs. ext3 would be obvious jbd ? (dep ext3) btrfs? ata_beneric ? ata_piix ? Whatever is needed to handle the host controller and disk which has the root, and the root filesystem type. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fbbf08d.80...@plouf.fr.eu.org
Re: Update-initramfs Most vs Dep
Hello, David Baron a écrit : Up until recent upgrades, it worked fine with dep producing initrd of 3.7 meg. After recent upgrades, this no longer worked. Various errors about rootfs or /root is a folder. The boot would fail at the tso point. Now have to use most and get 11 meg initrds, 5 x bigger than the whole kernel image! The excuse was that my system is a bastion one, born of Knoppix. Problem seem to me more of regression. It worked for years, what now? Anyone know of any fix or workaround? You can add the missing required modules in /etc/initramfs-tools/modules and rebuild the initramfs. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fbacb4e.3030...@plouf.fr.eu.org
Update-initramfs Most vs Dep
Up until recent upgrades, it worked fine with dep producing initrd of 3.7 meg. After recent upgrades, this no longer worked. Various errors about rootfs or /root is a folder. The boot would fail at the tso point. Now have to use most and get 11 meg initrds, 5 x bigger than the whole kernel image! The excuse was that my system is a bastion one, born of Knoppix. Problem seem to me more of regression. It worked for years, what now? Anyone know of any fix or workaround? (Hopefully this post will appear with a normal title and headers but I am not holding my breath :-( ) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201205202323.36926.d_ba...@012.net.il
Re: Can't run update-initramfs
On Fri, Feb 18, 2011 at 5:53 PM, Andre [debian] debian...@gmail.com wrote: On Fri, Feb 18, 2011 at 3:39 PM, Noah Duffy n.milo.du...@gmail.com wrote: I was trying to install Plymouth on Debain Squeeze. I followed the basic instructions, but the only thing I was unable to run was update-initramfs. It just tells me that the command isn't found. I'm a little confused. Is there something else I need to install or do? I did have initramfs-tools installed (it came with Plymouth). Are you using sudo or logged in as root? It's likely not in your path if you're not root. Andre I disabled the root user by not setting a password. So, I'm using sudo from my account. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTim_=h+us9bqvjbp9nsc-f_j0tgdkvbo8st2t...@mail.gmail.com
Re: Can't run update-initramfs
On Sat, 19 Feb 2011 11:46:12 -0500 (EST), Noah Duffy wrote: On Fri, Feb 18, 2011 at 5:53 PM, Andre [debian] debian...@gmail.com wrote: On Fri, Feb 18, 2011 at 3:39 PM, Noah Duffy n.milo.du...@gmail.com wrote: I was trying to install Plymouth on Debain Squeeze. I followed the basic instructions, but the only thing I was unable to run was update-initramfs. It just tells me that the command isn't found. I'm a little confused. Is there something else I need to install or do? I did have initramfs-tools installed (it came with Plymouth). Are you using sudo or logged in as root? It's likely not in your path if you're not root. Andre I disabled the root user by not setting a password. So, I'm using sudo from my account. Which means that you need to issue sudo update-initramfs ... -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1148982237.926326.1298136790423.javamail.r...@md01.wow.synacor.com
Can't run update-initramfs
I was trying to install Plymouth on Debain Squeeze. I followed the basic instructions, but the only thing I was unable to run was update-initramfs. It just tells me that the command isn't found. I'm a little confused. Is there something else I need to install or do? I did have initramfs-tools installed (it came with Plymouth). Noah Duffy Skype - Noah0504 | Jabber/Google Talk - n.milo.du...@gmail.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimocv9ebcfi7tijqm-rta3rrzfmhrdn+djcw...@mail.gmail.com
Re: Can't run update-initramfs
On Fri, 18 Feb 2011 17:39:02 -0600 Noah Duffy n.milo.du...@gmail.com wrote: I was trying to install Plymouth on Debain Squeeze. I followed the basic instructions, but the only thing I was unable to run was update-initramfs. It just tells me that the command isn't found. I'm a little confused. Is there something else I need to install or do? I did have initramfs-tools installed (it came with Plymouth). Noah Duffy Skype - Noah0504 | Jabber/Google Talk - n.milo.du...@gmail.com I just did this less than a week ago on Squeeze. I ran exactly... update-initramfs -u Everything works as expected. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110218184413.406d7477@t61.debian-linux
Re: Can't run update-initramfs
On Fri, Feb 18, 2011 at 3:39 PM, Noah Duffy n.milo.du...@gmail.com wrote: I was trying to install Plymouth on Debain Squeeze. I followed the basic instructions, but the only thing I was unable to run was update-initramfs. It just tells me that the command isn't found. I'm a little confused. Is there something else I need to install or do? I did have initramfs-tools installed (it came with Plymouth). Are you using sudo or logged in as root? It's likely not in your path if you're not root. Andre -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinh_6q+dp4lxmwhn6zeokqrqsbgkff1ptyeb...@mail.gmail.com
Re: update-initramfs produces unusable initrd.img
Hi again -- Does anyone have any post-thanksgiving suggestions for how to handle this issue? Thanks in advance, -PT On Tue, Nov 23, 2010 at 8:56 AM, Peter Tenenbaum peter.g.tenenb...@gmail.com wrote: In my recent experiments with moving my home Debian desktop to RAID-1 arrays, I discovered that update-initramfs is producing intrd.img-* files which are unusable. What I mean by that is this: When I do update-initramfs -u (or -c), it produces a new initrd.img-2.6.32-5-amd64. When I attempt to boot with the new file, I get the following: Loading, please wait [long wait, and then:] Gave up waiting for root device ...[some suggestions about looking at /proc/cmdline and /proc/modules] Alert: /dev/md3 does not exist! Dropping to a shell! [etc] Note that /dev/md3 is the RAID-1 array which is mounted as / . When I replace the initrd.img-2.6.32-5-amd64 which was generated when I installed squeeze, the computer boots without any problems, informs me that /dev/md3 has been started with 2 drives, etc. My /etc/initramfs-tools/initramfs.conf has MODULES=most, my /etc/initramfs-tools/modules has nothing enabled, and /etc/initramfs-tools/update-initramfs.conf has update-initramfs=yes and backup-initramfs=no. My suspicion is that I need to add some modules to the modules file. Is this correct? If so, which ones do I need for a system running software RAID-1 configured with mdadm? Thanks in advance, -PT
update-initramfs produces unusable initrd.img
In my recent experiments with moving my home Debian desktop to RAID-1 arrays, I discovered that update-initramfs is producing intrd.img-* files which are unusable. What I mean by that is this: When I do update-initramfs -u (or -c), it produces a new initrd.img-2.6.32-5-amd64. When I attempt to boot with the new file, I get the following: Loading, please wait [long wait, and then:] Gave up waiting for root device ...[some suggestions about looking at /proc/cmdline and /proc/modules] Alert: /dev/md3 does not exist! Dropping to a shell! [etc] Note that /dev/md3 is the RAID-1 array which is mounted as / . When I replace the initrd.img-2.6.32-5-amd64 which was generated when I installed squeeze, the computer boots without any problems, informs me that /dev/md3 has been started with 2 drives, etc. My /etc/initramfs-tools/initramfs.conf has MODULES=most, my /etc/initramfs-tools/modules has nothing enabled, and /etc/initramfs-tools/update-initramfs.conf has update-initramfs=yes and backup-initramfs=no. My suspicion is that I need to add some modules to the modules file. Is this correct? If so, which ones do I need for a system running software RAID-1 configured with mdadm? Thanks in advance, -PT
update-initramfs
J'ai mon initramfs qui est defectueux. J'ai trouvé la command update-initramfs mais ca n'apporte pas de solution avez-vous une idée des outils ou cmd a utiliser? Merci
Re: update-initramfs
Le 20 octobre 2010 14:00, Maurice Guerrier guelo...@yahoo.com a écrit : J'ai mon initramfs qui est defectueux. J'ai trouvé la command update-initramfs mais ca n'apporte pas de solution avez-vous une idée des outils ou cmd a utiliser? Merci Lire le man, puis tester la commande avec des paramêtres... update-initramfs -k `uname-r` -u Si ça ne fonctionne pas, décrire le problème correctement et sinon seppuku. -- Kévin -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=9um3ftrj3zvkludvnbehoaf0=dj5bp7yyx...@mail.gmail.com
Re: Where does update-initramfs get info?
On Tuesday 27 April 2010, Chris Davies wrote: Steve newsdeb...@jetcity.org wrote: grep of /etc/initramfs-tools/... for hda, crypt or boot returns nothing useful. Where else should I look? /usr/share/initramfs-tools Chris Thanks Chris! I shouda looked harder. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004281703.59454.newsdeb...@jetcity.org
Where does update-initramfs get info?
In upgrading from lenny to sid my new kernel fails to boot my encrypted lvm volume. Unpacking initrd I find cryptsetup is looking for /dev/hda3. This is correct for lenny (2.6.26) , but under sid (2.6.32) its /dev/sda3. Edited and repacked boots fine. If I could understand how initramfs builds the image maybe I could suggest a fix, or at least report a bug. grep of /etc/initramfs-tools/... for hda, crypt or boot returns nothing useful. Where else should I look? steve -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004271031.48798.newsdeb...@jetcity.org
Re: Where does update-initramfs get info?
On Tuesday 27 April 2010 12:31:48 Steve wrote: In upgrading from lenny to sid my new kernel fails to boot my encrypted lvm volume. Unpacking initrd I find cryptsetup is looking for /dev/hda3. This is correct for lenny (2.6.26) , but under sid (2.6.32) its /dev/sda3. Where should I look? /etc/fstab? -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Where does update-initramfs get info?
Steve newsdeb...@jetcity.org wrote: grep of /etc/initramfs-tools/... for hda, crypt or boot returns nothing useful. Where else should I look? /usr/share/initramfs-tools Chris -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/25rja7xnfj@news.roaima.co.uk
[squeeze-sid] kernel 2.6.32-trunk-686 ... et pbm update-initramfs
Bonsoir à tous.
J'ai soumis un rapport de bogue au bug-tracking system de debian concernant ce
problème (concernant le mauvais paquet au départ --
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571003 mais fusionné ensuite
avec http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570321)
A ce jour (bug + 6 jours) pas la moindre réponse de la kernel team...
... alors je me tourne vers vous.
Pour résumer lors d'une màj nécessitant un 'update-initramfs' le processus
plante sans message d'erreur lors d'un modprobe.
# pstree -a
[...]
│ │ └─update-initramf /usr/sbin/update-initramfs -uv
│ │ └─mkinitramfs /usr/sbin/mkinitramfs -v -o
/boot/initrd.img-2.6.32-trunk-686.new 2.6.32-trunk-686
│ │ └─mkinitramfs /usr/sbin/mkinitramfs -v -o
/boot/initrd.img-2.6.32-trunk-686.new 2.6.32-trunk-686
│ │ ├─awk /^insmod/ { print $2 }
│ │ └─modprobe --set-version=2.6.32-trunk-686 --ignore-install --show-depends
amd64_agp
Je ne peux, depuis, ni installer, ni supprimer, ni mettre à jour le moindre
paquet. (apt me demande d'effectuer #dpkg --configure -a ... qui bloque comme
ci-dessus)
Que puis-je faire ?
Booter sur un autre kernel changera-t-il l'affaire ?
Toute piste bienvenue !
merci d'avance,
Jerome
Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive:
http://lists.debian.org/6395852.482.1267044046145.javamail@wwinf8216
Re: etch - lenny, update-initramfs interrupts dpkg
On Fri, Mar 6, 2009 at 9:13 PM, Osamu Aoki os...@debian.org wrote: On Fri, Mar 06, 2009 at 05:30:47PM -0600, Mark Copper wrote: Hi, Updating from etch to lenny following release notes. aptitude upgrade ends with Processing triggers for initramfs-tools ... update-initramfs: Generating /boot/initrd.img-2.6.18 /usr/sbin/mkinitramfs: line 164: mktemp: command not found update-initramfs: failed for /boot/initrd.img-2.6.18 dpkg: subprocess post-installation script returned error exit status 1 E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem. but running dpkg --configure -a results in the sam error. Besides it's strange that mktem should not be installed already, but aptitude show mktemp says, no, it's not installed. But if I do try to install it: deneb:~# apt-get install mktemp E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem. So it seems I'm stuck in a vicious circle. Did you try downloading mktemp package with wget/curl or apt-get -d ... and use dpkg to install with some -f options in man pages? No I didn't, but I would have if the thought had occurred to me. What made you think of it? I don't know how to get the deb manually, but I managed to compile from source. And then 'dpkg -i' worked without any coaxing. And then 'dpkg --configure -a' ran without complaint (OK it choked on vim). Thank you. Can this circle be broken? Unless you did something funny, this is bug worth reporting. I almost surely did. But it bothers me the mktemp pkg would vanish... Osamu -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
