reassign 586404 debian-installer
retitle 586404 d-i must not mix udev packages from different releases
thanks
On Jul 06, Otavio Salvador wrote:
> I agree with you; this shouldn't be fixed on udev but a new installer
> version to be released.
Looks like there are no objections about this.
Now the
Hello,
On Sun, Jul 4, 2010 at 4:30 PM, Frans Pop wrote:
> On Sunday 04 July 2010, Petter Reinholdtsen wrote:
>> > Looks so, I never expected that the two packages could get out of
>> > sync.
>>
>> Is there some way to get the udevadm settle command work also with
>> older udevd versions? Can the
On Jul 04, Petter Reinholdtsen wrote:
> > Looks so, I never expected that the two packages could get out of sync.
> Is there some way to get the udevadm settle command work also with
> older udevd versions? Can the protocol be changed?
No.
--
ciao,
Marco
signature.asc
Description: Digital si
On Sunday 04 July 2010, Petter Reinholdtsen wrote:
> > Looks so, I never expected that the two packages could get out of
> > sync.
>
> Is there some way to get the udevadm settle command work also with
> older udevd versions? Can the protocol be changed?
This is a D-I release management problem a
[Marco d'Itri]
> Looks so, I never expected that the two packages could get out of sync.
Is there some way to get the udevadm settle command work also with
older udevd versions? Can the protocol be changed?
> But I have no idea about how to restart the daemon from the udeb.
I do not know either
On Jul 02, Petter Reinholdtsen wrote:
> Perhaps the udeb should be written to handle upgrades and restart
> udevd when it is? Not quite sure how to do that, as the postinst
Looks so, I never expected that the two packages could get out of sync.
But I have no idea about how to restart the daemon
[Petter Reinholdtsen]
> This make me suspect the problem is caused by the upgrade of
> udev-udeb. Perhaps the udev daemons is not restarted during
> upgrades, and the daemon and udevsettle binary end up using
> different protocols?
I tried to restart udevd when udevadm settle started to hang for
Just a quick note from a DVD test I do at the moment. The slow
udevadm settle problem do not show up with a DVD build, where the
udev-udeb package is not on the DVD. Because of this the udev-udeb
package is not upgraded within d-i, and the installation is not slowed
down like it is when I do PXE
>
> This is useful, but we were talking about the parent udevd process.
>
Right :)
Will try to strace.
Regards,
Allard
On Jun 25, Allard Hoeve wrote:
> > You need to strace the parent process for the whole time udevadm settle
> > is running.
This is useful, but we were talking about the parent udevd process.
--
ciao,
Marco
signature.asc
Description: Digital signature
Hello Marco, Petter,
> You need to strace the parent process for the whole time udevadm settle
> is running.
>
I spent some time today doing the above. Please find several strace files
attached. The files have their original mtimes, so you'll be able to deduce
easily which of the files came firs
On Jun 24, Petter Reinholdtsen wrote:
> There are three udevd processes running. stracing two of them show
> ppoll(), while the last one with the lowest pid number do not show
> which system call it is doing. Not quite sure what is going on here.
You need to strace the parent process for the wh
[Marco d'Itri]
>> Where can I see the udev entries currently in the queue?
> Run "udevadm settle --timeout=0".
After the udev-udeb package is upgraded, this call hang the same way
as 'udevadm settle', for 180 seconds before its alarm trigger. Did
not test before the upgrade.
There are three udev
On Jun 24, Petter Reinholdtsen wrote:
> Where can I see the udev entries currently in the queue?
Run "udevadm settle --timeout=0".
> I can see that the udev-udeb package is upgraded from version 150-2 to
> version 157-1 when the installer runs. Is this a problem?
In theory, it should not be.
-
[Marco d'Itri]
> Can you try rebuilding your initramfs, just to be sure that udevd and
> udevadm are from the same version.
Not easily. Is there a way to figure out which version of udevd and
udevadm I got by looking inside the binaries?
Where can I see the udev entries currently in the queue?
On Jun 24, Allard Hoeve wrote:
> Thanks for the feedback. I should've added that it's reproducable using the
> d-i daily build. Will check versions tomorrow. But I issue they're the same
> version in testing so will also be the same version in d-i.
If it happens while installing it has to be the
Marco,
Thanks for the feedback. I should've added that it's reproducable using the
d-i daily build. Will check versions tomorrow. But I issue they're the same
version in testing so will also be the same version in d-i.
Regards,
Allard
On Jun 24, 2010 9:06 PM, "Marco d'Itri" wrote:
Can you try
Can you try rebuilding your initramfs, just to be sure that udevd and
udevadm are from the same version.
--
ciao,
Marco
signature.asc
Description: Digital signature
[Marco d'Itri]
> It does not "hang", unless you can prove the contrary it is waiting
> for completion of pending events.
How can I "prove the contrary"? Have in mind that I do not really
know much about the inner workings of udev.
> Check /dev/.udev/queue/ while it is waiting, for a start.
That
On Jun 19, Petter Reinholdtsen wrote:
> The process hang after the sendto() call and the rt_sigsuspend() call,
> and time out with SIGALRM after what I suspect is 3 minutes.
It does not "hang", unless you can prove the contrary it is waiting for
completion of pending events.
Check /dev/.udev/queu
Package: udev-udeb
Version: 157-1
Severity: important
User: debian-...@lists.debian.org
UserTags: debian-edu
Since some days ago, the debian-installer run in Squeeze is very slow
some times. Looking at the process list, I was able to trace it to
the calls to 'udevadm settle' being done sev
21 matches
Mail list logo
