Hello, since a du in april I have to wait a long time until boot is finished. Lots of lines can be viewed scrolling across the display. As I can see all of them begin with "libudev" or similar. Is there anyone who has an idea how to solve this problem?

Systeminformation in the attachment "systeminfo"
A photograph of the sreen during boot in the attachment "screen photo".

Hello Moderators: What is the reason that my question was moved to the Experimental Forums: I don't understand where you have seen "Procedures depicted therein are considered dangerous ..." in my question, in the screen shot, in the system information? Please tell me what the problem is.
josch

The following I want to address to the aptosid moderators especially to the person who moved my post: I am using sidux/aptosid since several years and I followed aptosid when you divorced from sidux. I use aptosid on different hardware (6 machines and in VMs). When I face a problem I am looking for information in the aptosid forums and the internet and usually I find something helpful. The actual problem is the first I ever posted in the aptosid forum and this is because I didn’t find useful information anywhere. My IT knowledge is rather self made and my English not so fluently to describe these sort of problems in a professional manner. So I provided the photo and the systeminfo. Therefore, of course I hoped anyone of the experienced users of aptosid can help me.

If DonKult is right, why someone moved my posting to „Experimental“ I want to send the following information: My first post from July 25th was written using Kernel „3.3-3.slh.2-aptosid-amd64“. Over a longer period it was my „Standardkernel“ because I faced problems with the 3.4 kernels. Before writing this message I made a du on the hardware in question (including kernel 3.5) and until now it is working. The kernels viewable on the photo remain of some testing purposes some time ago. Once again I enclose an actual photo, a short systeminfo and the output of uname -a.

I appreciate if someone will move my question to a forum, where I will get the chance of being helped by experienced users.

These messages all don't look like errors. They sound more like debug information from libudev. Beside a lot of floating by messages, do you experience any problems? (seems like your machine boots just fine into KDE if the running konsole in the uname screenshot is an indication …) Without any error it is hard to help.

I would suggest removing at least the very old kernels (i usually have 3 kernel, the current [e.g. 3.5-0.slh.2], the previous [e.g. 3.5-0.slh.1] and one from the previous kernelrelease [e.g. 3.4-something] just in case something breaks). udev doesn't work [reliable] with kernels < 2.6.32 anymore (maybe the limit is even higher now…) and while other tools do not have such proclaimed limits they aren't tested on these kernels usually, so they tend to be more fragile in such an environment. Might be that udev activates debugmode because you have such old kernels and could potentially boot into them.

Ensure also that no packages are on hold, that you have the most recent system (dist-upgrade) and tell us the udev version spitting out all these messages (apt-cache policy udev).

(You will get potentially as much help here as in any other subforum, the difference is that it avoids scaring newbies here as opposed to in a support or upgrades warning forum. Nobody else seems to have this problem, so there is some difference between yours and the "usual" setup - and dmz-kernels and such suggest that the diff might be pretty big.)

_________________MfG. DonKult
"I never make stupid mistakes. Only very, very clever ones." ~ The Doctor

Currently I don't experience problems to boot into KDE; there were lots of problems when the change was made to xserver 1.12 because I used the on-board-graphic-chip and this one behaves like a Radeon HD 4290. Finally I decided to install a fanless Asus GT 440 together with the nouveau-driver; but not until installing the proprietary driver the booting of KDE was fine.

OK, all older kernels are removed now; the 3.5-0.slh.1 is running and the 3.3-3.slh.2 remains for fall back. Dist-upgrade is most recent (ia32-libs, ia32-libs-gtk and wine are kept back by du; libfm-gtk0 and libfm0 were on hold during du).

In /etc/udev/udev.conf the log level was defined as "info" - I tried to reduce it to "err"; the result of this change could be that now the boot process is like normal beginning with booting of "init".

Currently I don't experience problems to boot into KDE; there were lots of problems when the change was made to xserver 1.12 because I used the on-board-graphic-chip and this one behaves like a Radeon HD 4290. Finally I decided to install a fanless Asus GT 440 together with the nouveau-driver; but not until installing the proprietary driver the booting of KDE was fine.

I read that 3.5 is better in that area (graphic card hotplugging) but this needs a newer xserver version (to be released upstream in September). [I don't have these a Intel+Radeon/Nvidia setup available, but a DisplayLink (= an usb graphic card) so I have some interest in that topic, but it seems like we have to wait a thin bit longer]

josch wrote:

OK, all older kernels are removed now; the 3.5-0.slh.1 is running and the 3.3-3.slh.2 remains for fall back. Dist-upgrade is most recent (ia32-libs, ia32-libs-gtk and wine are kept back by du; libfm-gtk0 and libfm0 were on hold during du).

In /etc/udev/udev.conf the log level was defined as "info" - I tried to reduce it to "err"; the result of this change could be that now the boot process is like normal beginning with booting of "init".

"err" seems to be the default. At least it is what is set here and I don't remember changing it. Do you?

_________________MfG. DonKult
"I never make stupid mistakes. Only very, very clever ones." ~ The Doctor

"err" seems to be the default. At least it is what is set here and I don't remember changing it. Do you?

The problem I adressed to the forum is solved! I don't remenber when I changed udev.conf to "info" but obviously it was the reason of the problem. Since I changed it back to "err" I rebooted the system several times and it is still working correctly. So thanks DonKult for your essential hint.

DonKult wrote:

libfm*0 seems to be gone. It's at least not in sid (and wheezy) - and I don't have it installed. Try removing it to see what holds it back.

To set libfm*0 on hold seems not to be necessary at all because I didn't find any dependencies. Therefore I removed these libs.

Thanks for the hint regarding ia32* and wine!

DonKult wrote:

I read that 3.5 is better in that area (graphic card hotplugging) but this needs a newer xserver version (to be released upstream in September) ... but it seems like we have to wait a thin bit longer.

At the moment I am monitoring the stability of my actual graphics system. According to the evolution of the 3.5 Kernels and xservers I will change back to the free drivers because I have to make no use of the most technological advanced levels of actual graphics systems.

By the way I am looking for a Debian solution to use on a netbook touch screen (Samsung NB 30).

By the way I am looking for a Debian solution to use on a netbook touch screen (Samsung NB 30).

I don't have this specific device, but I have debian on two touchscreen devices where the touchscreen works out of the box (nowadays -- they are phones, so this is usually harder than netbooks). Depends on kernel support for the touchscreen of course, but this seems like pretty mainstream hardware (as it is shipped with windows by default). So, just get a livecd/usb-stick, plug it in and try. You should have a good chance for working out-of-the-box …

_________________MfG. DonKult
"I never make stupid mistakes. Only very, very clever ones." ~ The Doctor