el 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/" d
ght 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
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 Liv
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
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 pag
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 foun
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-pro
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.
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 b
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
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,
ing 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 underl
int 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.
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 dup
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
>> hims
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-
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
i
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 w
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, ex
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- ?
ux 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
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.
--
Somet
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 wo
;*-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 sys
pdate 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
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-init
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
.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
| 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.
om 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
> unde
ot 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 w
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 ini
> 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
> &
> 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 t
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
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
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
>>> insta
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
> 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
COMPR
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
> 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
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 becau
> > 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' ma
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
> 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?
> 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.
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
>
> #
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 --ins
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 re
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
Re
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 suppo
>> 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 pref
> Hi Marco,
Hi Hans :)
> aptitude purge ~n4.9.10-amd64-*
Hadn't thought of matching a pattern, thanks.
> 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.
> 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
> >
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
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
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
> 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
>
>
> # 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
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.
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
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
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
ve 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?
>>
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 previou
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
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
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 mo
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
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 in
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 i
s, 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).
>>
On Fri, Feb 18, 2011 at 5:53 PM, Andre [debian] wrote:
> On Fri, Feb 18, 2011 at 3:39 PM, Noah Duffy 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 j
On Fri, Feb 18, 2011 at 3:39 PM, Noah Duffy 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 litt
On Fri, 18 Feb 2011 17:39:02 -0600
Noah Duffy 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 litt
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 initr
t; 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:
>
>
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
On Tuesday 27 April 2010, Chris Davies wrote:
> Steve 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-us
Steve 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.de
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 loo
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 bu
On Fri, Mar 6, 2009 at 9:13 PM, Osamu Aoki 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
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
On Sat, 7 Mar 2009 02:57:48 +
Graham wrote:
> > 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
On Fri, 6 Mar 2009 17:30:47 -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
> /u
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.
the manpage:
EXAMPLES
Update the initramfs of the newest kernel:
update-initramfs -u
Confusing newest (is that even a valid word?) and existing, if you can
see what I mean. :-)
--
Chris.
==
Don't forget to check that your /etc/apt/sources.lst entries point to
etch and not
Chris Bannister wrote:
On Sun, Mar 04, 2007 at 02:19:54PM -0600, Hugo Vanwoerkom wrote:
Hi,
I run this:
~Sun Mar 04-13:57:19SDA6# update-initramfs -u
and I get:
/boot/initrd.img-2.6.18-4-486 does not exist. Cannot update.
That happens to be true. (Surprise!)
But how does he know that
On Sun, Mar 04, 2007 at 02:19:54PM -0600, Hugo Vanwoerkom wrote:
> Hi,
>
> I run this:
>
> ~Sun Mar 04-13:57:19SDA6# update-initramfs -u
>
> and I get:
>
> /boot/initrd.img-2.6.18-4-486 does not exist. Cannot update.
>
> That happens to be true. (Surprise
On Sun, Mar 04, 2007 at 04:29:24PM -0600, Hugo Vanwoerkom wrote:
> Hugo Vanwoerkom wrote:
> >Hi,
> >
> >I run this:
> >
> >~Sun Mar 04-13:57:19SDA6# update-initramfs -u
> >
> >and I get:
> >
> >/boot/initrd.img-2.6.18-4-486 does not exist.
Hugo Vanwoerkom wrote:
Hi,
I run this:
~Sun Mar 04-13:57:19SDA6# update-initramfs -u
and I get:
/boot/initrd.img-2.6.18-4-486 does not exist. Cannot update.
That happens to be true. (Surprise!)
But how does he know that initrd.img-2.6.18-4-486 is the 'newest kernel'
as the man-p
Hi,
I run this:
~Sun Mar 04-13:57:19SDA6# update-initramfs -u
and I get:
/boot/initrd.img-2.6.18-4-486 does not exist. Cannot update.
That happens to be true. (Surprise!)
But how does he know that initrd.img-2.6.18-4-486 is the 'newest kernel'
as the man-page has it?
uname -r h
94 matches
Mail list logo
