Avoid APT::Default-Release (was: Re: nvidia vs nouveau driver and initrd.* size)

On 04/08/2024 06:24, Van Snyder wrote: Then, to avoid sucking anything more from unstable, I added /etc/apt/apt.conf.d/my-default containing APT::Default-Release "stable"; It prevents installing security updates

Re: nvidia vs nouveau driver and initrd.* size

On Sat, 2024-08-03 at 23:49 +0200, Vincent Lefevre wrote: > On 2024-08-01 12:12:31 -0700, Van Snyder wrote: > > On Thu, 2024-08-01 at 15:26 +0200, Vincent Lefevre wrote: > > > Should I switch to the proprietary nvidia driver on these > > > machines? > > > > Without NVidia's graphics accelerator, u

Re: nvidia vs nouveau driver and initrd.* size

On 2024-08-02 14:55:31 +0200, Franco Martelli wrote: > Sorry but have you read that bug report (#1076561)? Some users has posted > solutions to make smaller the initrd file: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076561#10 > and > https://bugs.debian.org/cgi-bin

Re: nvidia vs nouveau driver and initrd.* size

On 2024-08-01 12:12:31 -0700, Van Snyder wrote: > On Thu, 2024-08-01 at 15:26 +0200, Vincent Lefevre wrote: > > Should I switch to the proprietary nvidia driver on these machines? > > Without NVidia's graphics accelerator, using software rendering with > nouveau is painfully slow. Sometimes even t

Re: nvidia vs nouveau driver and initrd.* size

-6.9.12-amd64 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076561 No, bug 1076561 is fixed. FYI, without this fix, the initrd file was so big that the kernel package could not even be installed on this machine. Now, I can install it, but the initrd file is nevertheless much bigger. However

Re: nvidia vs nouveau driver and initrd.* size

On Thu, 2024-08-01 at 15:26 +0200, Vincent Lefevre wrote: > I have several Debian/unstable machines, all with a Nvidia card. > > On one of them, due to a bug in nouveau in the past, I use the > proprietary nvidia driver: libnvidia-legacy-390xx-* packages. > And the initrd siz

Re: nvidia vs nouveau driver and initrd.* size

On 2024-08-01 11:32:10 -0400, Felix Miata wrote: > Vincent Lefevre composed on 2024-08-01 17:18 (UTC+0200): > > > On 2024-08-01 10:23:53 -0400, Felix Miata wrote: > > >> the bug fix should trim initrd size considerably before > >> too long. > > > What

Re: nvidia vs nouveau driver and initrd.* size

Vincent Lefevre composed on 2024-08-01 17:18 (UTC+0200): > On 2024-08-01 10:23:53 -0400, Felix Miata wrote: >> the bug fix should trim initrd size considerably before >> too long. > What do you mean? After package containing bug fix is installed, newly generated initrds wi

Re: nvidia vs nouveau driver and initrd.* size

ia driver: libnvidia-legacy-390xx-* packages. > > And the initrd size is reasonable: > > > -rw-r--r-- 1 root root 66937544 2024-07-30 11:27:32 initrd.img-6.9.12-amd64 > > > Note that on this machine, firmware-nvidia-graphics is not installed. > > According to its de

Re: nvidia vs nouveau driver and initrd.* size

Vincent Lefevre composed on 2024-08-01 15:26 (UTC+0200): > I have several Debian/unstable machines, all with a Nvidia card. > On one of them, due to a bug in nouveau in the past, I use the > proprietary nvidia driver: libnvidia-legacy-390xx-* packages. > And the initrd size is reason

nvidia vs nouveau driver and initrd.* size

I have several Debian/unstable machines, all with a Nvidia card. On one of them, due to a bug in nouveau in the past, I use the proprietary nvidia driver: libnvidia-legacy-390xx-* packages. And the initrd size is reasonable: -rw-r--r-- 1 root root 66937544 2024-07-30 11:27:32 initrd.img-6.9.12

Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

On 2024-07-31 16:00, Celejar wrote: Update: FWIW, Debian Developer Ben Hutchings actually assigned this issue a "grave" severity, and it was ultimately moved to the initramfs-tools package. It's now fixed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076561 Well done! Thank you for helpin

Re: Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

t boot time, > but the recommends has this surprising side-effect for those with > a /boot partition with insufficient free space for such a large > firmware package. It is not dangerous because the old initrd is not > removed until the new one is written successfully, but it is annoying!

Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

missing firmware at boot time, > but the recommends has this surprising side-effect for those with a > /boot partition with insufficient free space for such a large firmware > package. It is not dangerous because the old initrd is not removed > until the new one is written successfull

Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

space for such a large firmware package. It is not dangerous because the old initrd is not removed until the new one is written successfully, but it is annoying! Kind regards, -- Ash Joubert (they/them) Director / Game Developer Transient Software Limited <https://transient.nz/> New Zealand

Re: Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

or : 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. > It turns out that the initrd for 6.9.9 is more than 7x the size of the > one for 6.9.8! > > &g

Debian Sid/Unstable is not a rolling user distro [WAS:Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size]

Le 19/07/2024 à 05:12, songbird a écrit : The Wanderer wrote: ... By taking on yourself the risk and burden of running sid, you are volunteering to be one of those who helps notice issues before they reach testing, and report those issues so that the machinery of the archive can stop the package

Re: Debian Sid/Unstable is not a rolling user distro [WAS:Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size]

Le 19/07/2024 à 09:25, didier gaumet a écrit : [...] You are perfectly right: there is no contract and one i free to use which Debian distro one wants to... [...] typo error, sorry: You are perfectly right: there is no contract and one is free to use which Debian distro one wants to...

Re: Debian Sid/Unstable is not a rolling user distro [WAS:Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size]

On Fri, Jul 19, 2024 at 10:07:14AM +0200, didier gaumet wrote: [...] > > One of the things I love Debian for. > > > > Cheers > > My bad, I do know the existence of the Debian social contract but have not > worded accurately enough what I wanted to say. I should have written > something like: N

Re: Debian Sid/Unstable is not a rolling user distro [WAS:Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size]

Le 19/07/2024 à 09:43, to...@tuxteam.de a écrit : On Fri, Jul 19, 2024 at 09:25:22AM +0200, didier gaumet wrote: Le 19/07/2024 à 05:12, songbird a écrit : [...] You are perfectly right: there is no contract and one i free to use which Debian distro one wants to... Actually, there /is/ a co

Re: Debian Sid/Unstable is not a rolling user distro [WAS:Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size]

On Fri, Jul 19, 2024 at 09:25:22AM +0200, didier gaumet wrote: > Le 19/07/2024 à 05:12, songbird a écrit : [...] > You are perfectly right: there is no contract and one i free to use which > Debian distro one wants to... Actually, there /is/ a contract: https://www.debian.org/social_contract

Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

The Wanderer wrote: ... > By taking on yourself the risk and burden of running sid, you are > volunteering to be one of those who helps notice issues before they > reach testing, and report those issues so that the machinery of the > archive can stop the package versions which those issues from mig

Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

ramfs failure zstd -q -9 -T0 70 update-initramfs: failed for /boot/initrd.img-6.9.9-amd64 with 1. It turns out that the initrd for 6.9.9 is more than 7x the size of the one for 6.9.8! I had the same problem. The cause is not the kernel upgrade but the refactoring of non-free firmware packages. firmware

Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

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. > * > > It turns out that the initrd for 6.9.9 is more than 7x the size of the > one for 6.9.8! > > * > ~$ ls

Re: Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

The Wanderer wrote: > On 2024-07-18 at 13:50, Celejar wrote: > > > Andrew M.A. Cater wrote: > > >> This is not the place for debugging Sid, I'm afraid, there are too > >> few > > > > It's not? Where, then, is the place for debugging Sid? > > I'm no longer anything *close* to an expert in this

Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

t;> state in a development tree. > > That's fair. I think I meant more that I was just going to stick with > 6.9.8 until this gets sorted out, rather than muck around and deviate > from the default kernel / initrd build settings without official > documentation of the process

Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

On 2024-07-18 at 13:50, Celejar wrote: > Andrew M.A. Cater wrote: >> This is not the place for debugging Sid, I'm afraid, there are too >> few > > It's not? Where, then, is the place for debugging Sid? I'm no longer anything *close* to an expert in this area (having not run sid myself in well o

Re: Re: Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

On Thu, Jul 18, 2024 at 13:50:21 -0400, Celejar wrote: > Really? I had the impression that lots of list subscribers / readers > run Sid. Are there statistics on this? Nah, sid users are just louder, on average. Stable users don't have as much to talk about, because our stuff just works. ;-)

Re: Re: Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

Andrew M.A. Cater wrote: > On Thu, Jul 18, 2024 at 03:42:30PM +, Andy Smith wrote: > > Hi, > > > > On Thu, Jul 18, 2024 at 11:35:15AM -0400, Celejar wrote: > > > I'd rather not mess around with stuff I don't really understand > > > without an official guide to the process. > > > > I don't me

Re: Re: Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

ted out, rather than muck around and deviate from the default kernel / initrd build settings without official documentation of the process. > Asking if a specific thing is a known issue that is being worked > on? Sure. Expecting it to be documented before any user hits it? Not > so much. I understand, and largely agree. > Thanks, > Andy -- Celejar

Re: Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

On Thu, Jul 18, 2024 at 03:42:30PM +, Andy Smith wrote: > Hi, > > On Thu, Jul 18, 2024 at 11:35:15AM -0400, Celejar wrote: > > I'd rather not mess around with stuff I don't really understand > > without an official guide to the process. > > I don't mean this to be snarky, but that desire seem

Re: Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

Hi, On Thu, Jul 18, 2024 at 11:35:15AM -0400, Celejar wrote: > I'd rather not mess around with stuff I don't really understand > without an official guide to the process. I don't mean this to be snarky, but that desire seems incompatible with running Debian sid. I honestly think it's an unreasona

Re: Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

really should document breaking changes like this. Is a bug report in order? > Do you need this firmware? If so, do you need it at boot time? > There are kernel build options. Building it as a module and > making sure that initrd doesn't include it is pretty normal for > a numbe

Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

ocumented somewhere? > Is there a straightforward fix / workaround? Of course something changed: it's Sid. It will probably be straightened out before it hits stable. Do you need this firmware? If so, do you need it at boot time? There are kernel build options. Building it as a module and m

Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

T0 70 update-initramfs: failed for /boot/initrd.img-6.9.9-amd64 with 1. * It turns out that the initrd for 6.9.9 is more than 7x the size of the one for 6.9.8! * ~$ ls -l /boot/initrd.img* -rw-r--r-- 1 root root 27491557 Jul 8 13:45 /boot/initrd.img-6.9.8-amd64 -rw-r--r-- 1 root root 2057

Re: Playing a sound when initrd wants a password

On 28/01/2024 00:07, Curt wrote: (Anyway, this is what my personal robot explained to me and may be subject to imperfection and error.) I find it over-sophisticated and, being put after the recipe, extremely unfriendly to those who get it in search engine results. Unfortunately bootup(7) is r

Re: Playing a sound when initrd wants a password

[ Sorry, didn't read the actual post, just answering the Subject: ] What makes you think initrd will be satisfied with a sound? Stefan 🙂

Re: Playing a sound when initrd wants a password

David Wright (12024-01-26): > It looks as if the root directory is decrypted by > /usr/share/initramfs-tools/scripts/local-top/cryptroot > and, from its prereqs, that this script makes sure it > is the last to run from scripts/local-top, by actually > being run from scripts/local-block/cryptroot. >

Re: Playing a sound when initrd wants a password

Curt (12024-01-27): > (Anyway, this is what my personal robot explained to me and may be subject to > imperfection and error.) I started explaining all the ways this answer is obviously nonsensical, but I got fed up and deleted it. If I wanted the answers from a stupid AI, I could have asked dire

Re: Playing a sound when initrd wants a password

On Sat, Jan 27, 2024 at 05:07:37PM -, Curt wrote: > On 2024-01-26, Nicolas George wrote: > > Curt (12024-01-26): > >> A play-sound.timer unit file in /usr/lib/systemd/system-generators/initrd > >> directory. > > > > I see no mention of this directory on

Re: Playing a sound when initrd wants a password

On 2024-01-26, Nicolas George wrote: > Curt (12024-01-26): >> A play-sound.timer unit file in /usr/lib/systemd/system-generators/initrd >> directory. > > I see no mention of this directory on the web. Where did yo find the > idea of using it, I want to check the doc. I g

Re: Playing a sound when initrd wants a password

On Fri 26 Jan 2024 at 16:13:26 (+0100), Nicolas George wrote: > Hi. > > Yet another strange question. Is there a supported¹ way to have > cryptsetup play a specific sound when it asks the password for the root > partition from the initrd? > > I think brttty (braille) is al

Re: Playing a sound when initrd wants a password

Curt (12024-01-26): > A play-sound.timer unit file in /usr/lib/systemd/system-generators/initrd > directory. I see no mention of this directory on the web. Where did yo find the idea of using it, I want to check the doc. And what should I put in the timer file to express “when a passw

Re: Playing a sound when initrd wants a password

On 2024-01-26, Nicolas George wrote: > Curt (12024-01-26): >> I guess a systemd timer unit constitutes a hack. > > A systemd timer in the initrd? Can you elaborate? > A play-sound.timer unit file in /usr/lib/systemd/system-generators/initrd directory. A play-sound.servic

Re: Playing a sound when initrd wants a password

Curt (12024-01-26): > I guess a systemd timer unit constitutes a hack. A systemd timer in the initrd? Can you elaborate? -- Nicolas George

Re: Playing a sound when initrd wants a password

On 2024-01-26, Nicolas George wrote: > Hi. > > Yet another strange question. Is there a supported¹ way to have > cryptsetup play a specific sound when it asks the password for the root > partition from the initrd? > > I think brttty (braille) is already running at this po

Playing a sound when initrd wants a password

Hi. Yet another strange question. Is there a supported¹ way to have cryptsetup play a specific sound when it asks the password for the root partition from the initrd? I think brttty (braille) is already running at this point (no occasion to test yet), but a recognizable sound would be something

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

On 07.01.24 20:33, songbird wrote: i see you've solved your issue, but i just wanted to point out that it works and is ok for people who want to try it out. Says who?

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

Richard Rosner wrote: > So, since for whatever reason Grub seems to be broken beyond repair, I > today tried to just replace it with rEFInd. Installation succeeded > without any trouble. But when I start my system, rEFInd just asks me if > I want to boot with fwupd or with the still very broken

Re: Possibly broken Grub or initrd after updates on Testing

t     insmod cryptodisk     insmod luks2     insmod gcry_rijndael     insmod gcry_rijndael     insmod gcry_sha256     insmod ext2     cryptomount -u     set root='cryptouuid/'     if [ x$feature_platform_search_hint = xy ]; then       search --no-floppy --fs-uuid --set=root --hint='c

Re: Possibly broken Grub or initrd after updates on Testing

On 07.01.24 18:07, David Wright wrote: I compared your new grub.cfg with mine (suitably decimated and edited) and the significant differences are very few; extra modules are loaded: cryptodisk, luks2, gcry_rijndael, gcry_rijndael and gcry_sha256. Myset root='hd0,gpt5' is replaced by set ro

Re: Possibly broken Grub or initrd after updates on Testing

On Thu 04 Jan 2024 at 19:49:43 (+0100), Richard Rosner wrote: > On 04.01.24 19:02, David Wright wrote: > > Could you post the new grub.cfg file, so that people running testing, > > and following along the thread later, can see how boot-repair fixed it? > > Keep in mind, this is based on the assump

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

On Thu, Jan 4, 2024 at 6:18 PM Joel Roth wrote: > > On Thu, Jan 04, 2024 at 06:19:01PM +0100, Richard Rosner wrote: > > In theory, it should > > be as simple as refind-install. So the only reason I could guess to be the > > reason would be that rEFInd might not be capable of handling LUKS, which >

Re: Possibly broken Grub or initrd after updates on Testing

    insmod luks2     insmod gcry_rijndael     insmod gcry_rijndael     insmod gcry_sha256     insmod ext2     set root='cryptouuid/'     if [ x$feature_platform_search_hint = xy ]; then       search --no-floppy --fs-uuid --set=root --hint='cryptouuid/'     else       sear

Re: Possibly broken Grub or initrd after updates on Testing

On Wed 03 Jan 2024 at 22:00:20 (+0100), Richard Rosner wrote: > On 03.01.24 21:04, Eddie wrote: > > On 1/3/24 14:23, Richard Rosner wrote: > > > So, since for whatever reason Grub seems to be broken beyond > > > repair, I today tried to just replace it with rEFInd. > > > Installation succeeded with

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

On Thu, Jan 04, 2024 at 06:19:01PM +0100, Richard Rosner wrote: > In theory, it should > be as simple as refind-install. So the only reason I could guess to be the > reason would be that rEFInd might not be capable of handling LUKS, which > would be quite disappointing. My experiences are with va

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

Well, that was a bust. I accidentally didn't just format the EFI partition, but deleted it. So I re-created it with the help of disks and gparted (to leave the first 3 MB empty, I remeber that being a fix added kinda recently to combat bad BIOS/EFI implementations, since Windows is doing the sa

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

You should really re-read the FAQ that was sent in just two days ago... On January 4, 2024 11:58:28 AM GMT+01:00, Jeffrey Walton wrote: >On Thu, Jan 4, 2024 at 2:45 AM Richard Rosner wrote: >> >> Wow, what a bunch of unhelpful comments. >> >> First, if it wasn't for Eddie recommending boot-repa

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

On Thu, Jan 4, 2024 at 2:45 AM Richard Rosner wrote: > > Wow, what a bunch of unhelpful comments. > > First, if it wasn't for Eddie recommending boot-repair, "broken beyond > repair" in fact was the very fitting term. Here was Eddie's comment" I have had very good results using "Boot-Repair" sof

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

Good to know that it should be possible. But as mentioned, these symbols only offer me to boot from grub or fwupd. F2 also doesn't show that much more, it merely gives me the option to boot into the BIOS settings. Maybe I'll have to completely purge all Grub packages, wipe the existing EFI partitio

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

On 1/4/24 02:45, Richard Rosner wrote: Wow, what a bunch of unhelpful comments. First, if it wasn't for Eddie recommending boot-repair, "broken beyond repair" in fact was the very fitting term. Second, have you maybe considered that I've already read the home page of rEFInd and came to the s

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

On Wed, Jan 03, 2024 at 08:23:29PM +0100, Richard Rosner wrote: > So, since for whatever reason Grub seems to be broken beyond repair, I today > tried to just replace it with rEFInd. Installation succeeded without any > trouble. But when I start my system, rEFInd just asks me if I want to boot > wi

Re: Possibly broken Grub or initrd after updates on Testing

I have kept the referral to the old problem in the topic for a reason. Been there, done that. I'm not entirely sure how, but boot-repair was the only thing that was able to fix Grub. Before that I've reinstalled it countless times, thanks. But since this is very much not an answer to the question

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

Wow, what a bunch of unhelpful comments. First, if it wasn't for Eddie recommending boot-repair, "broken beyond repair" in fact was the very fitting term. Second, have you maybe considered that I've already read the home page of rEFInd and came to the same conclusion? Besides the fact that the pa

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

On Wed, Jan 3, 2024 at 2:24 PM Richard Rosner wrote: > So, since for whatever reason Grub seems to be broken beyond repair, > I am not sure what you mean by "broken beyond repair." I have no issues with Grub on Debian 12 on AMD64. I had no issues with Grub on Debian 11 or Debian 10 on AMD64 eith

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

On Wed, Jan 3, 2024 at 2:24 PM Richard Rosner wrote: > > So, since for whatever reason Grub seems to be broken beyond repair, I seriously doubt this is the case. I'm guessing the problem lies elsewhere. > I today tried to just replace it with rEFInd. Installation succeeded without > any trouble

Re: Possibly broken Grub or initrd after updates on Testing

Thanks, this actually did the job. I don't know what it was, but my guess is it was the step "purge Grub before reinstalling it". PS: rewrote to the old subject, as this is clearly an answer to the original problem, as it doesn't have anything to do with replacing Grub all together. On 03.0

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

I have had very good results using "Boot-Repair" software to recover Grub difficulties. Eddie On 1/3/24 14:23, Richard Rosner wrote: So, since for whatever reason Grub seems to be broken beyond repair, I today tried to just replace it with rEFInd. Installation succeeded without any trouble. B

Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

So, since for whatever reason Grub seems to be broken beyond repair, I today tried to just replace it with rEFInd. Installation succeeded without any trouble. But when I start my system, rEFInd just asks me if I want to boot with fwupd or with the still very broken Grub. Am I missing something?

Re: Possibly broken Grub or initrd after updates on Testing

On 01.01.24 21:20, Richard Rosner wrote: On 01.01.24 20:30, David Wright wrote: On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote: On 01.01.24 18:13, David Wright wrote: I can boot by hand, but since this is all archived anyways and it's uneccessarily difficult to find some sort of

Re: Possibly broken Grub or initrd after updates on Testing

On 01.01.24 20:30, David Wright wrote: On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote: On 01.01.24 18:13, David Wright wrote: I can boot by hand, but since this is all archived anyways and it's uneccessarily difficult to find some sort of guide how to even do this, it might as we

Re: Possibly broken Grub or initrd after updates on Testing

On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote: > On 01.01.24 18:13, David Wright wrote: > > On Mon 01 Jan 2024 at 17:55:29 (+0100), Richard Rosner wrote: > > > On January 1, 2024 5:43:12 PM GMT+01:00, David Wright wrote: > > > > > > > Like this? > > > > > > > > └─sda6

Re: Possibly broken Grub or initrd after updates on Testing

I can boot by hand, but since this is all archived anyways and it's uneccessarily difficult to find some sort of guide how to even do this, it might as well be a documentation for users having such troubles in the future. Also, besides the way that I have no clue how it would have to look like

Re: Possibly broken Grub or initrd after updates on Testing

On Mon 01 Jan 2024 at 17:55:29 (+0100), Richard Rosner wrote: > On January 1, 2024 5:43:12 PM GMT+01:00, David Wright > wrote: > > >Like this? > > > > └─sda6 8:60 406.2G 0 part > >└─luks-f3fbb9ba-a556-406c-b276-555e3e8577bc 254:10 406.2G

Re: Possibly broken Grub or initrd after updates on Testing

Yes, exactly. Is there a way to show that from inside Grub? Lsblk and blkid aren't available there? On January 1, 2024 5:43:12 PM GMT+01:00, David Wright wrote: >Like this? > > └─sda6 8:60 406.2G 0 part >└─luks-f3fbb9ba-a556-406c-b276-555e3e

Re: Possibly broken Grub or initrd after updates on Testing

as (crypto1) > > set root=(crypto1) > linux /vmlinuz root=/dev/mapper/luks-UUID > initrd /initrd.img > boot > > The problem only is to get the UUID format right. When you're asked to enter > the decryption key in a normal boot, it's shown, but without any dashes. Bu

Re: Possibly broken Grub or initrd after updates on Testing

So, I found a way to manually mount luks partition in Grub and boot from it. What I did to get there: set root=(hd0,gpt2) cryptomount -a This gave me the unencrypted version of the root partition as (crypto1) set root=(crypto1) linux /vmlinuz root=/dev/mapper/luks-UUID initrd /initrd.img boot

Re: Possibly broken Grub or initrd after updates on Testing

I do not see an answer to my questions. > On Jan 1, 2024, at 11:52, Michael Kjörling <2695bd53d...@ewoof.net> wrote: > > On 1 Jan 2024 11:46 +0100, from rich...@rosner-online.de (Richard Rosner): >> I'm not sure what you meant with "rescue mode", but I've reinstalled >> grub anyways. The log of

Re: Possibly broken Grub or initrd after updates on Testing

On 1 Jan 2024 11:46 +0100, from rich...@rosner-online.de (Richard Rosner): > I'm not sure what you meant with "rescue mode", but I've reinstalled > grub anyways. The log of it doesn't look good though. Quite a bunch > of errors. The result also is the same. Please review the posts in the thread st

Re: Possibly broken Grub or initrd after updates on Testing

I'm not sure what you meant with "rescue mode", but I've reinstalled grub anyways. The log of it doesn't look good though. Quite a bunch of errors. The result also is the same. https://pastes.io/nvmlsxghlm > On Jan 1, 2024, at 11:03, Michael Kjörling <2695bd53d...@ewoof.net> wrote: > > On 1

Re: Possibly broken Grub or initrd after updates on Testing

t; prompt. You do mention that you regenerated the initrd, but the initrd doesn't really figure into GRUB; it comes into play after the kernel is loaded into memory, which itself happens past the boot menu which you don't get to. I know it likely won't point you toward what the actu

Re: Possibly broken Grub or initrd after updates on Testing

As far as I can tell, /boot and /boot/grub are the same filesystem. After all, I didn't really do anything custom. Just your default LUKS installation with the boot efi stuff on sda1/sdb1/whatever, LUKS on 2 and LUKS encrypted swap on 3. I did make a video. Nothing that's not showing up always.

Re: Possibly broken Grub or initrd after updates on Testing

On 29 Dec 2023 18:56 +0100, from rich...@rosner-online.de (Richard Rosner): > Hey, I have quite the strange issue. After updating a bunch of > packages today [1], mostly related to systemd, gstreamer and udev, > and restarting my device, it no longer boots. I have an encrypted > system. So I do get

Possibly broken Grub or initrd after updates on Testing

continuing to the Grub boot menu, my device simply reboots to the BIOS menu. It's not the first time I ran into such an issue. I did once after manually updating initrd because Grub wouldn't offer to boot the 6.5.0-4 kernel because of malformed grub.cfg. The solution was kinda simple.

Re: initrd sizes mushroomed several months ago

David Wright writes: > You presumably aren't running 686 and amd64 kernels, then, > unlike Felix. It depends on the system too. My amd64 based router doesn't have microcode in the initramfs but that's OK since microcode is handled by the BIOS (Coreboot). Also I think the microcode's not free to

Re: initrd sizes mushroomed several months ago

you implied they're not even necessary). Can you figure > out what the dracut initrd is replacing them with, if anything. The .kos are only needed when early drm is desired. When BIOS video is adequate to task, I can wait for KMS graphics to engage after switchroot, and keep initrds sma

Re: initrd sizes mushroomed several months ago

e.debian.net wasn't working when I started. So I noticed. When I looked for the files you pasted yesterday, whois claimed that it didn't exist. Summarising the above, I see: mymy systemsystem initrdinitrdinitrd buster bullseye 5.1

Re: initrd sizes mushroomed several months ago

David Wright composed on 2023-02-04 10:59 (UTC-0600): > I don't yet know which directories are being included in yours. 6 instances of lsinitramfs, with and without -l for 3 kernels: # initrd.img-5.17.0-1-amd64; gzip bytes:7,649,297; lines:445: https://termbin.com/2o3z https://paste.debian.net/1

Re: initrd sizes mushroomed several months ago

e just lives dangerously, > > I cannot say. :-) > > None of my ARM machines have a microcode update in their initrd. > Are they really "so old" or am I living dangerously (or both)? You presumably aren't running 686 and amd64 kernels, then, unlike Felix. Cheers, David.

Re: initrd sizes mushroomed several months ago

; zstd > >> before the newer kernel. It's specified by default in initramfs.conf, but > >> the > >> upgrades from 11 to 12 here have only been including libzstd1, which > >> apparently > >> is not used for initrd construction. > > > Tha

Re: initrd sizes mushroomed several months ago

have a microcode update in their initrd. Are they really "so old" or am I living dangerously (or both)? Stefan

Re: initrd sizes mushroomed several months ago

On Sat, Feb 04, 2023 at 10:38:12AM -0600, David Wright wrote: > Sure, I knew that. The problem was that AFAICT, Felix's > initrd had no first, uncompressed cpio, archive, so > $ cpio -t < /boot/initrd.img-6.0.0-6-amd64 > immediately ran into the compressed, main archive. That &

Re: initrd sizes mushroomed several months ago

to see the contents of the *second* archive in the initrd, > you have to call cpio a second time. Yes. Of course, it helps to ascertain what the second archive actually /is/ before running zcat on it, because zcat only deals with bzip2, gzip, lzip, and xz, not zstd. > unicorn:~$ { cpio -it

Re: initrd sizes mushroomed several months ago

s in /boot/. 3-apt update 4-time apt-get upgrade This did not add a new kernel. Dracut rebuilt all existing initrds. I noticed no activity from update-initramfs. 5-rebooted successfully using 6.0x's new initrd. 6-apt-get full-upgrade ... 34 upgraded, 21 newly installed, 0 to remov

Re: initrd sizes mushroomed several months ago

On Fri, Feb 03, 2023 at 06:45:14PM -0600, David Wright wrote: > It's useful, as seen in my post, to skip past the early archive in > order to see how the main archive has been compressed. If you want to see the contents of the *second* archive in the initrd, you have to call cpio a

Re: initrd sizes mushroomed several months ago

nuineIntel.align.0123456789abc > kernel/x86/microcode/GenuineIntel.bin > 9794 blocks > > Not sure how *useful* it is, since it only lists the TOC from the first > cpio archive in the initrd image, and there may be multiple. But it > should give a human-readable table of content

Re: initrd sizes mushroomed several months ago

conversation. > Maybe you're used to seeing super-mega-bloated 88Ms on Ubuntu or > Mint? :p I think it more likely that I'm used to considering the sizes of initrd etc. for a live-environment ISO, which needs to be able to work on almost any hardware and so has basically all potenti

Re: initrd sizes mushroomed several months ago

The Wanderer composed on 2023-02-03 07:16 (UTC-0500): > FTLIW, my own primary desktop has an AMD graphics card (and has since > before the initial Debian install), and doesn't have these large > initrds: Oh, but it does > $ lh /boot/initrd.img-* > -rw-r--r-- 1 root root 36M Sep 2 08:27 /bo

Re: initrd sizes mushroomed several months ago

Hi, David Wright wrote: > > > $ cpio -t < /boot/initrd.img-6.0.0-6-amd64 Felix Miata wrote: > > Is that a typo? I copied & pasted that and the screen loaded binary > > gibberish. Greg Wooledge wrote: > GNU cpio(1) says that -t implies -i, so it should work on

Re: initrd sizes mushroomed several months ago

e TOC from the first cpio archive in the initrd image, and there may be multiple. But it should give a human-readable table of contents. If it doesn't, then either you're not using GNU cpio (try cpio -it for portability), or your archive may be corrupt.

  1   2   3   4   5   6   7   8   9   >