SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have the same netbook, so I had the same problem.
After some google searching I found that the delay/error at boot is caused
by a change in udev. They changed the way it loads drivers with firmware,
if udev detects the driver is not updated for that, it pauses for a 30seconds delay.
This can only be fixed by the author of the kernel module which is causing it.
(Thats why your 3.5 kernel is fine, probably its fixed there)
A workaround for that problem is to blacklist the offending module in /etc/modprobe.d/blacklist.conf
(in my case it was brcmsmac, the wifi driver) and later load it in rc.local (modprobe brcmsmac)
BTW, What's the reason to haste to udev-182 instead of staying with udev-175, while still using Linux-3.2 to let so many people suffer from the long delay on start-up?
... and to go so fast to the RC2 stage?
(I know there must be a reason I saw it somewhere but I just forgot it. So I'm asking. Thanks!)
BTW, What's the reason to haste to udev-182 instead of staying with udev-175, while still using Linux-3.2 to let so many people suffer from the long delay on start-up?
... and to go so fast to the RC2 stage?
(I know there must be a reason I saw it somewhere but I just forgot it. So I'm asking. Thanks!)
I have an inherent distrust of new udev versions. However, 175 wasn't going to do it... that version had some firmware loading bugs that were breaking wireless drivers, and 182 fixed them. 182 has some problems as well, but overall they aren't nearly as bad.
Concerning RC2, if there's a big batch of updates, it's going to be called a new RC. Don't take those version numbers to indicate haste.
I have an inherent distrust of new udev versions. However, 175 wasn't going to do it... that version had some firmware loading bugs that were breaking wireless drivers, and 182 fixed them. 182 has some problems as well, but overall they aren't nearly as bad.
Yes. You are right.
And if those who have problems with udev-182 have their problems solved with Linux-3.5 (at least one of them said so), could slackware-14 include a Linux-3.5 kernel config in the "testing" directory?
Quote:
Originally Posted by volkerdi
Concerning RC2, if there's a big batch of updates, it's going to be called a new RC. Don't take those version numbers to indicate haste.
Thanks! I thought RC2 meant "much more close to a release". My mistake.
Remember THAT bug? Well, it's nearly 3 years later and the bug remains. I'm unsure if the bug is specifically related to Slackware or GNU/Linux in general since my solitary distribution of GNU/Linux is Slackware. I suspect a combination of problems.
For those members who aren't familiar with this bug, the main symptom is read or mount failure of a newly inserted disc. If the disc is inserted in the drive at boot, the disc can generally be read, mounted, and written without error. If the disc is inserted into the drive AFTER the operating system is booted, then the failures to read and mount begin. If a user manually reloads udev's rules and ejects the disc and then reinserts the disc, then it's generally possible to read and mount the disc without error ... but not always. In my experience the only method of ensuring an accurate read, mount, or write to an optical disc REQUIRES the disc to be inserted into the drive BEFORE the operating system is booted. The motherboard is a 5 year old M2N68-LA (Ivy) with nForce 430 chipset.
That is where you are wrong in your assumptions. There were some changes between Slackware 13.37 and 14.0 which require you to pay heed to the .new files (do not discard them so easily!).
Distribution: Slackware (personalized Window Maker), Mint (customized MATE)
Posts: 1,309
Rep:
Quote:
Originally Posted by brianL
Well, that fell flat. I was expecting someone to ask if I could see the light at the end of it.
OK. I turned on the light at the end of the tunnel. Do you see that? It’s white. Caution: don’t follow the red one – it leads to the bad womb.
(The explanation for the laymen: following the red light will result in reincarnation as a smart chimp in a zoo watching dumb people all day long or as a dumb politician watched by the smart people all day long. Misfortune.)
That is where you are wrong in your assumptions. There were some changes between Slackware 13.37 and 14.0 which require you to pay heed to the .new files (do not discard them so easily!).
... showing you that KDM will look in other directories too, now. And guess what's in one of them:
Code:
$ ls /usr/share/xsessions/
xfce.desktop
You're not the first one to fall for that trap, though.
Eric
Thanks for pointing this out! I should have known some obscure change was buried in that kdmrc file. This might be a good candidate for the CHANGES_AND_HINTS.TXT.
install in virtualbox, connect via vnc, run xfce in it.
open a terminal with multi-tab, after some work, on the terminal can not input any char, CRTL+D doesn't work also. but ALT+# still working.
after drag the window with mouse, or do some switch between tabs, the keyboard is ok
do a check with the system, the difference is upgrade scim to 1.4.14. after I disable the scim program, the issue never happen again.
my locale is zh_CN.utf8, the scim is started in xinitrc with command: "scim -d"
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.