Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #257023 > unrolled thread

update-initramfs

Back to article view | Back to linux.debian.user

Contents

  update-initramfs Marc Auslander <marcslists@gmail.com> - 2023-04-11 02:30 +0200
    Re: update-initramfs David Wright <deblis@lionunicorn.co.uk> - 2023-04-11 05:00 +0200
      Re: update-initramfs Marc Auslander <marcslists@gmail.com> - 2023-04-11 17:10 +0200
        Re: update-initramfs davidson <davidson@freevolt.org> - 2023-04-11 19:40 +0200
          Re: update-initramfs Michel Verdier <mv524@free.fr> - 2023-04-11 21:00 +0200
            Re: update-initramfs davidson <davidson@freevolt.org> - 2023-04-11 21:50 +0200
              Re: update-initramfs davidson@freevolt.org - 2023-04-11 22:00 +0200
                Re: update-initramfs zithro <slack@rabbit.lu> - 2023-04-11 22:20 +0200
                  Re: update-initramfs David Wright <deblis@lionunicorn.co.uk> - 2023-04-12 04:10 +0200
              Re: update-initramfs Michel Verdier <mv524@free.fr> - 2023-04-12 04:40 +0200
                Re: update-initramfs The Wanderer <wanderer@fastmail.fm> - 2023-04-12 13:40 +0200
                  Re: update-initramfs Michel Verdier <mv524@free.fr> - 2023-04-12 13:50 +0200
                    Re: update-initramfs The Wanderer <wanderer@fastmail.fm> - 2023-04-12 14:00 +0200
                      Re: update-initramfs David Wright <deblis@lionunicorn.co.uk> - 2023-04-12 22:50 +0200
                        Re: update-initramfs Michel Verdier <mv524@free.fr> - 2023-04-13 04:20 +0200
                          Re: update-initramfs David Wright <deblis@lionunicorn.co.uk> - 2023-04-13 21:00 +0200
                            Re: update-initramfs Charles Curley <charlescurley@charlescurley.com> - 2023-04-13 22:40 +0200
                              Re: update-initramfs David Wright <david@lionunicorn.co.uk> - 2023-04-15 00:50 +0200
                            Re: update-initramfs Michael Stone <mstone@debian.org> - 2023-04-13 22:50 +0200
                              Re: EPSON ET M 1120   new printer: If You can read this, you are  using the wrong driver David <curmudgeon@telaman.net.au> - 2023-04-14 23:40 +0200
                              Re: EPSON ET M 1120   new printer: If You can read this, you are  using the wrong driver Brian <ad44@cityscape.co.uk> - 2023-04-15 00:20 +0200
                                Re: EPSON ET M 1120   new printer: If You can read this, you are  using the wrong driver The Wanderer <wanderer@fastmail.fm> - 2023-04-15 00:30 +0200
                                  Re: EPSON ET M 1120 new printer: If You can read this, you are using  the wrong driver Jeremy Ardley <jeremy@ardley.org> - 2023-04-15 00:40 +0200
                                    Re: EPSON ET M 1120 new printer: If You can read this, you are  using the wrong driver Charles Curley <charlescurley@charlescurley.com> - 2023-04-15 01:00 +0200
                                  Re: EPSON ET M 1120   new printer: If You can read this, you are  using the wrong driver Brian <ad44@cityscape.co.uk> - 2023-04-15 01:00 +0200
                                    Re: EPSON ET M 1120   new printer: If You can read this, you are  using the wrong driver The Wanderer <wanderer@fastmail.fm> - 2023-04-15 01:10 +0200
                                      Re: EPSON ET M 1120   new printer: If You can read this, you are  using the wrong driver Brian <ad44@cityscape.co.uk> - 2023-04-15 01:20 +0200
                                        Re: EPSON ET M 1120   new printer: If You can read this, you are  using the wrong driver The Wanderer <wanderer@fastmail.fm> - 2023-04-15 01:30 +0200
                                          Re: EPSON ET M 1120   new printer: If You can read this, you are  using the wrong driver Brian <ad44@cityscape.co.uk> - 2023-04-15 13:40 +0200
                                    Re: EPSON ET M 1120 new printer: If You can read this, you are using  the wrong driver Jeremy Ardley <jeremy@ardley.org> - 2023-04-15 01:10 +0200
                                      Re: EPSON ET M 1120 new printer: If You can read this, you are using  the wrong driver Brian <ad44@cityscape.co.uk> - 2023-04-15 01:20 +0200
                                        Re: EPSON ET M 1120 new printer: If You can read this, you are using  the wrong driver Bret Busby <bret@busby.net> - 2023-04-15 01:50 +0200
                                          Re: EPSON ET M 1120 new printer: If You can read this, you are  using the wrong driver David <curmudgeon@telaman.net.au> - 2023-04-15 01:50 +0200
                                          Re: EPSON ET M 1120 new printer: If You can read this, you are using  the wrong driver "Andrew M.A. Cater" <amacater@einval.com> - 2023-04-15 12:10 +0200
                                            Pillow fight [was: EPSON ET M 1120 ...] <tomas@tuxteam.de> - 2023-04-15 12:20 +0200
                                            Re: EPSON ET M 1120 new printer: If You can read this, you are using the wrong driver "Thomas Schmitt" <scdbackup@gmx.net> - 2023-04-15 13:00 +0200
                                              On strange threads [was: EPSON ET M 1120 new printer...] <tomas@tuxteam.de> - 2023-04-15 15:40 +0200
                                                Re: On strange threads [was: EPSON ET M 1120 new printer...] Brian <ad44@cityscape.co.uk> - 2023-04-15 21:50 +0200
                                                  Re: On strange threads [was: EPSON ET M 1120 new printer...] <tomas@tuxteam.de> - 2023-04-16 07:40 +0200
                                                    Re: On strange threads [was: EPSON ET M 1120 new printer...] davidson <davidson@freevolt.org> - 2023-04-16 09:10 +0200
                                          Re: EPSON ET M 1120 new printer: If You can read this, you are using  the wrong driver Brian <ad44@cityscape.co.uk> - 2023-04-15 13:50 +0200
                                            Re: EPSON ET M 1120 new printer: If You can read this, you are using  the wrong driver Bret Busby <bret@busby.net> - 2023-04-15 22:00 +0200
                                              Re: EPSON ET M 1120 new printer: If You can read this, you are using  the wrong driver Bret Busby <bret@busby.net> - 2023-04-15 22:30 +0200
                                                Re: EPSON ET M 1120 new printer: If You can read this, you are using  the wrong driver Jeffrey Walton <noloader@gmail.com> - 2023-04-16 00:20 +0200
                                                  Re: EPSON ET M 1120 new printer: If You can read this, you are using  the wrong driver Bret Busby <bret@busby.net> - 2023-04-16 01:40 +0200
                                            Re: EPSON ET M 1120 new printer: If You can read this, you are  using the wrong driver Curt <curty@free.fr> - 2023-04-22 16:30 +0200
                                              Re: EPSON ET M 1120 new printer: If You can read this, you are using  the wrong driver chris <tknchris@gmail.com> - 2023-04-22 16:40 +0200
                                    Re: EPSON ET M 1120   new printer: If You can read this, you are  using the wrong driver David <curmudgeon@telaman.net.au> - 2023-04-15 01:30 +0200
                                      Re: EPSON ET M 1120   new printer: If You can read this, you are  using the wrong driver <tomas@tuxteam.de> - 2023-04-23 11:20 +0200
                                      Re: EPSON ET M 1120   new printer: If You can read this, you are  using the wrong driver <tomas@tuxteam.de> - 2023-04-23 11:50 +0200
                                Re: EPSON ET M 1120   new printer: If You can read this, you are using the wrong driver Stefan Monnier <monnier@iro.umontreal.ca> - 2023-04-15 00:40 +0200
                                  Re: EPSON ET M 1120   new printer: If You can read this, you are  using the wrong driver Brian <ad44@cityscape.co.uk> - 2023-04-15 14:00 +0200
                              Re: EPSON ET M 1120 new printer: If You can read this, you are using  the wrong driver Jeffrey Walton <noloader@gmail.com> - 2023-04-29 13:50 +0200
                                Re: EPSON ET M 1120 new printer: If You can read this, you are using  the wrong driver Greg Wooledge <greg@wooledge.org> - 2023-05-01 13:40 +0200
                                  Re: EPSON ET M 1120 new printer: If You can read this, you are using  the wrong driver Thomas Hochstein <thh@thh.name> - 2023-05-01 14:40 +0200
                                    Re: EPSON ET M 1120 new printer: If You can read this, you are using  the wrong driver gene heskett <gheskett@shentel.net> - 2023-05-01 15:30 +0200
          Re: update-initramfs davidson <davidson@freevolt.org> - 2023-04-12 13:00 +0200
            Re: update-initramfs davidson@freevolt.org - 2023-04-12 13:00 +0200
        Re: update-initramfs David Wright <deblis@lionunicorn.co.uk> - 2023-04-11 22:10 +0200
    Re: update-initramfs zithro <slack@rabbit.lu> - 2023-04-11 15:30 +0200
      Re: update-initramfs Marc Auslander <marcslists@gmail.com> - 2023-04-11 17:00 +0200
        Re: update-initramfs zithro <slack@rabbit.lu> - 2023-04-11 18:10 +0200

Page 1 of 4  [1] 2 3 4  Next page →

#257023 — 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?

[toc] | [next] | [standalone]

#257026

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.

[toc] | [prev] | [next] | [standalone]

#257050

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.

[toc] | [prev] | [next] | [standalone]

#257057

[Multipart message — attachments visible in raw view] — view raw

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 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.

-- 
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

[toc] | [prev] | [next] | [standalone]

#257060

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 ?

[toc] | [prev] | [next] | [standalone]

#257062

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#257063

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#257066

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- ?

[toc] | [prev] | [next] | [standalone]

#257078

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.

[toc] | [prev] | [next] | [standalone]

#257080

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/<kernel version> 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.

[toc] | [prev] | [next] | [standalone]

#257090

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#257091

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.

[toc] | [prev] | [next] | [standalone]

#257092

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#257128

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.

[toc] | [prev] | [next] | [standalone]

#257138

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.

[toc] | [prev] | [next] | [standalone]

#257150

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.

[toc] | [prev] | [next] | [standalone]

#257151

On Thu, 13 Apr 2023 13:57:04 -0500
David Wright <deblis@lionunicorn.co.uk> 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 <kibi@debian.org>
To: debian-devel-announce@lists.debian.org
Cc: debian-boot@lists.debian.org
Subject: Debian Installer Bookworm Alpha 2 release


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#257184

On Thu 13 Apr 2023 at 14:39:18 (-0600), Charles Curley wrote:
> On Thu, 13 Apr 2023 13:57:04 -0500
> David Wright <deblis@lionunicorn.co.uk> 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.

[toc] | [prev] | [next] | [standalone]

#257152

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.

[toc] | [prev] | [next] | [standalone]

#257177 — Re: EPSON ET M 1120 new printer: If You can read this, you are using the wrong driver

On Fri, 2023-04-14 at 14:40 +0000, Schwibinger Michael wrote:
> Good afternoon.
> The new printer is not  working.
> EPSON is saying
> You cant use EPSON with Linux.

It depends on which printer you are using?
It sounds like the person you are talking to at Epson doesn't know what
he/she's talking about.
Epson supply many Linux drivers for their printers on their site.
I have a WF-C5290 which works just fine that way.
Cheers!

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | linux.debian.user

csiph-web