Any more bright ideas?
--
ciao,
Marco
signature.asc
Description: Digital signature
On May 25, maximilian attems [EMAIL PROTECTED] wrote:
These packages are not actually needed by udev, and again they may be
unpacked in the wrong order. Next?
i know that these packages are not needed by udev itself,
they are going to be installed on an upgrade to a new linux-image
So
On May 15, Marco d'Itri [EMAIL PROTECTED] wrote:
These packages are not actually needed by udev, and again they may be
unpacked in the wrong order. Next?
I am still waiting for your proposals.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Wed, 24 May 2006, Marco d'Itri wrote:
On May 15, Marco d'Itri [EMAIL PROTECTED] wrote:
These packages are not actually needed by udev, and again they may be
unpacked in the wrong order. Next?
i know that these packages are not needed by udev itself,
they are going to be installed on an
On Fri, 12 May 2006, Marco d'Itri wrote:
On May 12, maximilian attems [EMAIL PROTECTED] wrote:
This does not work, because if for some reason the user were not ready
to upgrade the kernel then the would have already been upgraded and
would not start again at the next reboot. Is this
On May 15, maximilian attems [EMAIL PROTECTED] wrote:
This does not work, because if for some reason the user were not ready
to upgrade the kernel then the would have already been upgraded and
would not start again at the next reboot. Is this what you really want?
do you propose
as upgrades work out if you touch that special conf file
i would propose to check against a version range in which
the sarge release falls and allow those an smooth upgrade
without running kernel check.
of course with a big warning that the user should reboot soonest.
regards
--
maks
--
To
On May 11, maximilian attems [EMAIL PROTECTED] wrote:
as upgrades work out if you touch that special conf file
i would propose to check against a version range in which
the sarge release falls and allow those an smooth upgrade
without running kernel check.
of course with a big warning that
On Fri, May 12, 2006 at 12:02:37AM +0200, Marco d'Itri wrote:
On May 11, maximilian attems [EMAIL PROTECTED] wrote:
as upgrades work out if you touch that special conf file
i would propose to check against a version range in which
the sarge release falls and allow those an smooth upgrade
On May 12, maximilian attems [EMAIL PROTECTED] wrote:
This does not work, because if for some reason the user were not ready
to upgrade the kernel then the would have already been upgraded and
would not start again at the next reboot. Is this what you really want?
do you propose
This should have been fixed by udev 0.085-1 and initramfs-tools 0.53, so
unless somebody will report more problems soon I will close the bug.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Mon, 2006-03-06 at 08:01 +0100, maximilian attems wrote:
On Sun, Mar 05, 2006 at 10:54:33PM -0500, Adam C Powell IV wrote:
Okay, 0.53 is in testing now (maybe a day or two ago). But again, with
the new initramfs-tools unpacked (but not configured):
Setting up udev (0.085-1) ...
On Sat, 2006-03-04 at 00:47 +0100, maximilian attems wrote:
On Thu, 02 Mar 2006, Adam C Powell IV wrote:
The new upgrade procedure fails on alpha, regardless of the kernel
workaround, there's still a udev - initramfs-tools dependency loop which
interrupts the udev postinst, and the
On Sun, Mar 05, 2006 at 10:54:33PM -0500, Adam C Powell IV wrote:
Okay, 0.53 is in testing now (maybe a day or two ago). But again, with
the new initramfs-tools unpacked (but not configured):
Setting up udev (0.085-1) ...
Kernel version too old. initramfs-tools requires at least 2.6.12.
On Mar 03, Adam C Powell IV [EMAIL PROTECTED] wrote:
Kernel upgrade mode, udevd has not been restarted.
Please reboot the system as soon as possible.
Kernel version too old. initramfs-tools requires at least 2.6.12.
dpkg: error processing udev (--configure):
subprocess post-installation
On Thu, Mar 02, 2006 at 07:54:08PM -0500, Adam C Powell IV wrote:
The new upgrade procedure fails on alpha, regardless of the kernel
workaround, there's still a udev - initramfs-tools dependency loop which
interrupts the udev postinst, and the failures cascade from there:
# touch
On Mar 03, maximilian attems [EMAIL PROTECTED] wrote:
could you put as local workaround an set -x on top in
/usr/sbin/mkinitramfs, would really like to know how we got called
there.
The udev postinst always runs update-initramfs -u.
--
ciao,
Marco
signature.asc
Description: Digital
On Fri, 03 Mar 2006, Marco d'Itri wrote:
On Mar 03, maximilian attems [EMAIL PROTECTED] wrote:
could you put as local workaround an set -x on top in
/usr/sbin/mkinitramfs, would really like to know how we got called
there.
The udev postinst always runs update-initramfs -u.
indeed you
On Thu, 02 Mar 2006, Adam C Powell IV wrote:
The new upgrade procedure fails on alpha, regardless of the kernel
workaround, there's still a udev - initramfs-tools dependency loop which
interrupts the udev postinst, and the failures cascade from there:
please upgrad initramfs-tools to latest
I implemented in udev 0.085-1 a first attempt to solve this problem.
It's totally untested and I will not able to test it myself soon, so
reports are appreciated.
The upgrade procedure should be something like:
# switch sources.list to testing
apt-get update
touch /etc/udev/kernel-upgrade
Greetings,
The new upgrade procedure fails on alpha, regardless of the kernel
workaround, there's still a udev - initramfs-tools dependency loop which
interrupts the udev postinst, and the failures cascade from there:
# touch /etc/udev/kernel-upgrade
# dselect
Reading package lists... Done
severity 349354 important
stop dude
as discussed with vorlon this needs to be resolved soon.
but latest klibc in testing needs that i-t release,
so let it slip for now, or we'll break to many systems.
--
maks
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
severity 349354 serious
thanks
On Sun, Feb 05, 2006 at 01:01:09PM +0100, maximilian attems wrote:
as discussed with vorlon this needs to be resolved soon.
as not discussed with the kernel team, this is a problem and the release
team can decide to overwrite this on there own.
Bastian
--
Ahead
severity 349354 critical
thanks
On Sun, Jan 22, 2006 at 05:27:43PM +0300, Nikita V. Youshchenko wrote:
Package: initramfs-tools,kernel,udev
Currently:
- recent linux-image packages depend on 'initramfs-tools | yaird |
linux-initramfs-tool', so initramfs-tools is the 'default'
Package: initramfs-tools,kernel,udev
Currently:
- recent linux-image packages depend on 'initramfs-tools | yaird |
linux-initramfs-tool', so initramfs-tools is the 'default' alternative
- initramfs-tools depends on recent udev
- recent udev refuses to install unless recent kernel is
25 matches
Mail list logo
