Re: [lfs-support] /usr/lib/libstdc++.so.6.0.14-gdb.py?
I've also been bedeviled by the ldconfig problem reported by Andy so I'm wondering if there has been any new thinking emerged in the past two years on this topic. Bruce sends the interested reader to a Bug report wherein someone seemed to be comfortable with a suggested fix(?) found there. Unfortunately, my Korean has become a little rusty lately, so what I managed to make out was that the fix would recommend the offending -gdb.py file be tucked away in something like '/usr/share/gdb/auto-load/'. I mustered up the courage and moved my file to the indicated location. 'ldconfig' has been quiet like a mouse ever since but now I'm uneasy about potentially new perils lurking in my system due to the change of venue. Thanks for any comments, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] usb mouse connects=disconnects repeatedly
Hi Martins, ... the usb mouse I have connected seems to be constantly disconnecting and reconnecting after the system boots, filling the screen constantly connect/disconnect messages like the following ... I wouldn't chuck my mouse out the window yet. I've been plagued by these nonsensical (to me) messages for quite a long time. For additional fun I even went to the '/etc/rc.d/init.d/localnet' script and inserted a read line ... stop) log_info_msg Bringing down the loopback interface... read ip link set lo down ... Obviously after making a backup of the original file, etc. The read command forces the script to stop advancing beyond it until the user hits a key. On rebooting the machine the display will stop at this next-to-last script (the last is 'reboot') and after every minute or so I'd get a bunch of four messages similar to yours (disconnect/connect) related to my USB Microsoft mouse existence on my system I'd watch the screen rapturously for about 5-10 min. (I don't have much of a life) and then give up (hitting a key) and go to yet another productive activity. I'm truly very busy now but I remember I wrote to the guy who was responsible for the kernel input drivers (and then some) and asked about this USB phenomenon. He answered my technical question very clearly and logically. He should know. I didn't understand (or agree) too much but it made me accept the USB mouse with a smile on my face and live with it from then on. Obviously, you get to accept the situation like car alarms and other life vicissitudes but life goes on anyway. If you haven't gotten rid of your mouse and are still interested in his wise words, I might be able to publish his answer for you in a few days. Good luck in all your endeavors, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] Headers in the system's include directory. Still Confused.
A recent incident in compiling 'udev-181' TRIGGERed me to again wonder what's going on and where and how I've been doing things wrong. I figure maybe this time, with a real world example, a good soul will understand what's been bothering me and take the time to calmly explain in _plain_ English the Header situation. Note: can actually be in any language as long as it is PLAIN. REFERENCES 1. Excerpt from the latest LFS kernel 3.2.6 installation text: Warning The headers in the system's include directory should always be the ones against which Glibc was compiled, that is, the sanitised headers from this Linux kernel tarball. Therefore, they should never be replaced by either the raw kernel headers or any other kernel sanitized headers. 2. My Glibc is v2.14.1 (recently installed, on Dec. 30, 2011) Note: at the time I was on kernel 3.0.20 (or thereabouts). 3.1. In trying to compile 'udev-181' I got this 'make' error, udev-builtin-input_id.c: In function 'test_key': error: 'BTN_TRIGGER_HAPPY' undeclared (first use in this function) 3.2. The 'BTN_TRIGGER_HAPPY' is not defined in '/usr/include/linux/input.h' as obviously expected by 'udev-builtin-input_id.c', but is clearly defined in '/linux-3.0.20/inclide/linux/input.h', probably a later addition to the Dec. 30, 2011 environment. Note: To spare the reader from a possible heart attack or some other indignity, I'm hastening to add that I managed to successfully worked this around by stuffing a definition of BTN_TRIGGER_HAPPY (0x2c0) in the offending source file which mercifully lead to a beautiful compile/check/install experience and my machine has been humming HAPPYly ever since. So, some of the questions kicking around in my head, for anybody who'd care to take the time to enlighten me on: Q1. Was I supposed to move the 'linux-x.y.z/include/' files to '/usr/include/' immediately after I installed Glibc? Q2. Am I supposed to move the 'linux-x.y.z/include/' files to '/usr/include/' each time after I install a new kernel? Q3. Which is the system's include directory - the '/usr/include/'? Q4. sanitised headers are those in this (?) Linux kernel tarball against which Glibc was compiled? Glibc is compiled at a certain point in time. this kernel varies almost daily, according to the LFS book and reality. Q5. What's the raw kernel headers? Q6. What's the other kernel sanitized headers? Q7. Is there a difference between sanitised and sanitized headers? (this is _just a joke_ - so bear with me, I've been in a silly mood once I saw 'udev-181' run so smoothly) With apologies for my limitations and many thanks in advance, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Headers in the system's include directory. Still Confused.
Hi Andy Bruce, Many thanks for your prompt, clear and helpful answers. Andy: You should leave the kernel headers in /usr/include as they were when you installed glibc. Bruce: The kernel varies, but you build glibc against one specific kernel. The programs that are built later need to be consistent with that glibc/kernel header combination. Americans and British are separated by a common language. The clarity and power of the subject Warning speaks volumes as to what can result from a close British-American co-operation. -- At the very least, your answers have helped me sharpen my big question which, after all, is based on this actual, immovable fact: 'udev-181' expects to find in '/usr/include/linux' a file, 'input.h', which contains the definition of a so called BTN_TRIGGER_HAPPY. Good, OK. I understand. Another secondary fact (which is most likely on me), my current '/usr/include/linux/input.h' does NOT contain it. Maybe because file too old, a mistake/omission in 6.7, etc., etc. Bad, Not-OK. -- Now I can crystallize my header question a lot more. We know an 'udev-xxx' (say, 'udev-173') did not need BTN_TRIGGER_HAPPY, while a later udev (say, 'udev-181') aware of a _newer_ 'input.h' file floating around, which does contain BTN_TRIGGER_HAPPY, expected the user (i.e., me) to have this file in '/usr/include/...'. Based on that, here's (finally) the finalized question: IF I'm up to date with the LFS book, and am at the latest Glibc, v2.14.1 (issued 07-Oct-2011, FWIW) no matter what kernel version was at the time (say, 3.0.9) - assuming I compiled Glibc-2.14.1 in Nov. 2011 - the sanitized headers installed as per Book 6.7 provide a guaranty for me that they contain the correct 'input.h' for as long as I stay with Glibc-2.14.1, no matter what the udev version du jour (181++) might be. Or put another way around, udev-173++ developers rely on and expect me to have the Nov. 2011 headers (sanitised:) and as for me, I'll be fine for any future udev release, as long as the Glibc stays at 2.14.1. Is that so? BTW, I didn't know that developers (udev and otherwise) are continuously careful to stay within the latest Glibc-thenKernel confines. Thanks, -- Alex PS - I don't have any idea when BTN_TRIGGER_HAPPY made its way into 'input.h'. Too bad. It'd've been interesting. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Still fighting with Network Madness...
Hi Jason,
I'm detecting a slight note of desperation in your voice, so before you do
anything
drastic, maybe you would like to spend a few minutes with my trouble-shooting
procedure.
In a similar (NOT exact) situation it worked for me simply, quickly, reliably
and
100% (that's one-hundred, NOT ninety-nine).
The procedure is based on the (well known) fact that some Broadcom drivers
are very finicky about the order of their loading.
If there are certain no-no drivers (modules) loaded BEFORE these sensitive
fellas they just load but QUIETLY refuse to work.
Hope your driver, tg3, is among them (like my particular driver was in my
case) and, with that knowledge, manipulating the loading order can get you
out of your predicament.
PRELIMS
P1. Boot the system always directly to command line (runlevel 3), NOT graphics
(level 5) in a, say, xterm window. So as not to complicate (or even gum up)
things unnecessarily.
You may have to hit '/etc/inittab' to make this happen, id:3:initdefault, etc.
P2. For this procedure 'lsmod' (and its friends) and 'ifconfig' are your
friends and only friends.
P3. The object of the game is to see eth0 (or something similar) in the
output of 'ifconfig'. IF that happens, you'll be on easy street (and on your
own) from there.
PROCEDURE
1. Boot up the system and immediately do
lsmod
2. Look at the modules (drivers) loaded BEFORE yours. They will show up BELOW
yours (tg3) in the listing.
If you see one that looks suspicious (that's an art/intuition. Look for
Broadcam modules, especially),
3. Unload the varmint ('rmmod', 'modprobe -r', things like that).
4. Unload and REload tg3 (check out results with another 'lsmod')
5. If you see eth0 on 'ifconfig' now you're done.
Go out, buy yourself a lemonade, come back and fill out the papers for your
well deserved cigar.
6. If you don't, go back to step 2 above.
7. If you have exhausted all humanly possible attempts, you're left with two
alternatives:
7.1. Give up on this procedure.
7.2. Take a good look at your kernel:
make menuconfig
Look for drivers (again, Broadcom especially) built into the kernel *
instead of as modules M. Make as many as you can as modules
(at least for this test if not forever, like I do. That's the school of thought
I
belong to; at the very least you can manipulate them better on loading and
Udev will load only the strictly necessary.
Make sure you don't change any one vital for a sane boot-up, like sd :)
Recompile and go to step 1.
Keeping my fingers crossed,
-- Alex
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] Bug in latest kernel releases (3.1.0 ... 3.1.4)
Nov 29, 2011 02:09:37 AM, Simon wrote: A little dramatic, don't you think? The world isn't going to end, just because you've found a bug in a video driver... In the KERNEL Simon, in the KERNEL, NOT the driver. Also, come to think of it, I didn't find the BUG, it found me! :) Speaking of drama, don't you think that for a KERNEL to mess up the return from graphics, so badly and inexcusably as of 3.x and end of 2011, that's pretty dramatic (and sad)? Thank you for your comments. Keep the faith. Only 14 more years. (BTW, if the world is to end at all, that would be in a little over a year or so - according to the Mayans). -- Alex -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Booting up - mountvirtfs, mountfs, /run/var/bootlog problems
Hi Bruce,
On Tue Nov 15 2011 at 15:12:33 MST
... we've made some improvements and fixed some bugs in the bootscripts. ...
Thank you for the excellent lfs-bootscripts-2014 release.
At the risk of sounding picayunish (just striving for an even higher
perfection), I do have some (exceedingly trivial - and not necessarily
meaningful) comments on the 'console' module.
1. There's no exit 0 at the end (after esac).
For consistency (might apply to a few other modules).
2. For Native English speakers, the 'Usage: ...' branch is never reached
(for them, the script dies at 'if [ -z ${KEYMAP} ... exit 0'.
Some clever dummy construct right at the top might satisfy everyone.
3. For the fortunate multitude who don't speak English natively, I believe
a simple echo Usage: ${0} {start}, instead of
echo $Usage: ${0} {start}, might work as well.
4. If you ever (future, future) find the above comments worth a second of
your busy time, you might want to insert the start paren on 'cleanfs' module,
Description: ... optionally) /tmp.
Thanks again for your terrific work,
-- Alex
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Booting up - mountvirtfs, mountfs, /run/var/bootlog problems
On Thu Nov 17 2011 at 14:41:17 MST, Bruce Dubbs schrieb
I don't really use this script [console], so can you test it for me?
Just try the attached file [console.txt].
Hi Bruce,
On a Native English speaker console (i.e., missing the
'/etc/sysconfig/console'):
[]$ ./console
Usage: ./console {start}
So it has passed my stringent test with flying colors.
FWIW, I had to remove the CR's from the file you attached.
No problem in these Perl days.
-- Alex
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: 2.6.39 - mount /dev/fd0 no longer works
On 06/03/2011 09:28 PM, Alex wrote: Thank you very much for the total silence you met this thread with. It warms the cockles of my heart to see there are still people of character around in this wild and crazy world of ours. Jun 4, 2011 01:43:13 AM, DJ Lucas wrote: On a related note, it is actually nice to see that someone still cares enough to take the time to write a sarcastic message with some flavor in this day and age! :-) It sure beats the old Thanks for nothing, grumble and leave routine. Due to your choice of writing style, I was unable to tell whether your sarcasm in the above quoted text was directed *at* lfs-support, or simply posted for the enjoyment of the readers. If not, you should understand that this is a volunteer community and that the reasons for silence are many, the most likely being that very few people use floppy drives any longer, making this community, at least, *unable* to assist. Fortunately, there are people upstream working on the kernel that do still use floppies and it was fixed. If your message was not directed *at* this list, only posted for entertainment, please ignore my comment above and know that I did enjoy reading your response right up until I read that last paragraph. --- Hi DJ, First off. At (B)LFS, to which I've belonged for many years now, I met only nice people and whether volunteer or not, many high quality professionals. You, in particular, are at the top of my list. Period. What has gotten to me is the amateurism, mis-coordination and the ensuing constant and disgusting cover-up that has reached the highest levels of open source production (witness this incident, the settle in udev-168, Firefox-4.0 and -3.6.14, etc.). It's possible that, what with the recent and projected technological directions the world has taken, more people have started to see Linux as really irrelevant now and jumped ship (in the water or to other vistas and endeavors du jour). It's maybe a seemingly insignificant development - ironically, some poetic justice after years of constantly trashing the enemy - to find the Home button at the right on the new Firefox. Is that a white flag or what? If there is an AT, and there is one, it is clearly pointed at the _indifference_ shown by (B)LFS denizens at recent open source issues I alluded to (or had in mind). To see it more clearly, simply imagine one of Window$ iterations just dropping the floppy enumeration at one point. All Seattle area would've been gutted by fire in an instant. But then again, as I said, all may be excused and ascribed to the new attractions in town (and there are many and _valid_) luring people away from demanding the best (or at least a reasonable level of excellence) in Linux. Best wishes, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: 2.6.39 - mount /dev/fd0 no longer works
Hello All, IMPORTANT UPDATE (very good news!!) As of 06/03/2011 12:34:00 AM (German time), my issue was removed by the new 2.6.39.1 release. As soon as I reached line 3502 (of 4164 overall) in reading the ChangeLog-2.6.39.1: block: always allocate genhd-ev if check_events is implemented, I knew my dear floppies would start whirring again like in the old times. I thank and acknowledge all the tireless and dedicated people who kept my problem (oops, issue) under wraps until working unfailingly again (as it did for the past 25 years or so). It comforts one beyond words to see the code of omerta still respected in certain circles, in these hectic and uncertain times. Hopefully, this attitude to extract the foot from our mouth as delicately and as quietly as it was inserted therein should always remain the basic principle in our lives. The enemy must NEVER find out about our little, _private_ indiscretions. Use (if you have to) only our secret code-words like genhd-ev above when dealing with them. Thank you very much for the total silence you met this thread with. It warms the cockles of my heart to see there are still people of character around in this wild and crazy world of ours. Thanks again, -- Alex PS 1. I attached the full ChangeLog-2.6.39.1 section covering this. 2. I've been wondering who the enemy is after all. Micro$oft? We're really in trouble then. 3. I was much afraid my OP would trigger yet another side show about who still uses floppies at this day and age. Luckily for me, like I said, omerta is still omerta. -- commit 9206053d7efb79adb564ccf7055342318b22475c Author: Tejun Heo t...@kernel.org Date: Thu May 26 21:06:50 2011 +0200 block: always allocate genhd-ev if check_events is implemented commit 75e3f3ee3c64968d42f4843ec49e579f84b5aa0c upstream. 9fd097b149 (block: unexport DISK_EVENT_MEDIA_CHANGE for legacy/fringe drivers) removed DISK_EVENT_MEDIA_CHANGE from legacy/fringe block drivers which have inadequate -check_events(). Combined with earlier change 7c88a168da (block: don't propagate unlisted DISK_EVENTs to userland), this enables using -check_events() for internal processing while avoiding enabling in-kernel block event polling which can lead to infinite event loop. Unfortunately, this made many drivers including floppy without any bit set in disk-events and -async_events in which case disk_add_events() simply skipped allocation of disk-ev, which disables whole event handling. As -check_events() is still used during open processing for revalidation, this can lead to open failure. This patch always allocates disk-ev if -check_events is implemented. In the long term, it would make sense to simply include the event structure inline into genhd as it's now used by virtually all block devices. Signed-off-by: Tejun Heo t...@kernel.org Reported-by: Ondrej Zary li...@rainbow-software.org Reported-by: Alex Villacis Lasso avill...@ceibo.fiec.espol.edu.ec Signed-off-by: Jens Axboe jax...@fusionio.com Signed-off-by: Greg Kroah-Hartman gre...@suse.de -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: setclock Question (lfs-bootscripts-20110424)
May 1, 2011 12:12:01 AM, neal.p.murphy wrote. Hi Neil, Thank you very much for your comments. I'm trying to comment on your comments now. Alex said: '/lib/udev/rules.d/50-udev-default.rules': SUBSYSTEM==rtc, DRIVERS==rtc_cmos, SYMLINK+=rtc FWIW, I don't see the relevance of rule 50-udev Neil said: The rule in 50-udev creates the symlink '/dev/rtc' to the actual node '/dev/rtc0'. It isn't relevant to the clock being set or not being set. Alex is saying: 1. On all my queries, there's NO 'SUBSYSTEM==rtc'. To reinforce to the readers (in case they missed it), I had asked, What is a possible configuration that would trigger the _SUBSYSTEM_ action in 55-lfs (2) ? Neil answered: *As written*, the subsystem rule is triggered *if* the RTC is in subsystem rtc; if there is no such subsystem, the rule will never be triggered. The kernel rule will never be triggered because it is looking for a device with kernel name 'rtc'; this device doesn't exist. If this rule is changed to look for a device with correct kernel name of 'rtc0', it will be triggered. Alex is saying: What rtc0 are we talking about? As a reminder to the readers (in case they missed it), I had written, ls -l /dev/rtc* crw-r--r-- 1 root root 10, 135 2011-04-30 20:32 /dev/rtc [please note the star above] Alex said: I'm still puzzled about not being able to find any traces on the console about 'setclock' being run by udev (55-lfs above). Is it possible that inside udevd the standard message Setting system clock... goes somewhere else? The log-fog? Neil answered: The log level may be set to, or default to, 'err'. If you change it via udevadm control --log-priority=info or udevadm control --log-priority=debug you should see all the info you're looking for--'debug' will show a *ton* of info. Alex is saying: 1. I'm not so sure. You're suggestion works only during a live system to change log levels dynamically (as they say). Would work like when you through another clock (like a grandfather's) at the machine and you want to see how udevd reacts in detail :) Our case (whether setclock script is run by Udev on start-up or not) is obviously a booting situation par excellence. You prepare for it _before_ reboot by statically setting the _following_ udevd log-level in '/etc/udev/udev.conf' (from say, default err to debug). 2. That said, there's NO trace (so to speak) of a setclock run what so ever (as they type now a days) in the debug-log. OTOH, I have now positive proof that udev _does_ run setclock on start-up. That's a 360 (as they say) reversal of what I said in my previous post. Rest assured, the crow has already been boiled, enjoyed and the green remains ecologically disposed of. Alex, on departing, is raising some new questions: Based on already (twice) mentioned ls -l /dev/rtc* crw-r--r-- 1 root root 10, 135 2011-04-30 20:32 /dev/rtc, I'm speculating that the difference between me and the rest of users (see also Simon's previous post of May 2, 2011 04:19:34 AM) who can proudly display a /dev/rtc0 (with a /dev/rtc symlink) or some such, is that I have CONFIG_RTC set to M as opposed to [Y] :( Questions: 1. Can this be true (a well known fact to everybody else)? (I know, I know, recompile the kernel with [Y] and see what happens :) As a matter of principle, I've always favored kernel/Udev to decide for me what module(s) is needed and when. 2. Normally, the kernel configuration has been careful to make a distinction between [Y/N] and [Y/M/N] depending on the situation. Is this a mis-coordination between Kernel and Udev, and the RTC _must_ be either Y or N (i.e., no M)? All I can certify is that my machines, always with M, have worked very smoothly (RTC-wise) all these years. I've never ever missed a /dev/rtc17 or the symlink. Thanks, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: setclock Question (lfs-bootscripts-20110424)
May 2, 2011 05:24:23 PM, Bruce wrote: Alex wrote: That's a 360 (as they say) reversal of what I said in my previous post. Not sure if I got the attribution right.LOL. I think you mean 180. :) Hi Bruce, This is a relatively known joke (expression) in relative wide use. It is attributed to Sammy Davis Jr. Etymology: during a conversation/interview he said something like He did a full 360 meaning a complete change of opinion/attitude etc. IMHO, he, as a top notch performer, can be forgiven for not being too versed in geometry, when we all, technical people, know full well that a complete reversal in direction actually involves making a turn of 270 degrees (Celsius :) -- Alex PS I expect the story to be found on YouTube somewhere. I definitely remember hearing it on a sound bite at the time. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev168 not work with mountfs of bootscript on x86_64 system ?
Apr 30, 2011 09:50:09 PM, Bruce wrote: perhaps a sleep( 2 ) before or after after '/sbin/udevadm settle' in the udev script would isolate the problem.You're right. On a slower machine, where I played with 168a "sleep 3" (for good measure - worked with 2 secs. as well)just before the end (::) of the start case completely quieted downthe things for me.-- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev168 not work with mountfs of bootscript on x86_64 system ?
Apr 30, 2011 09:50:09 PM, Bruce Dubbs wrote: perhaps a sleep( 2 ) before or after after '/sbin/udevadm settle' in the udev script would isolate the problem. You're right. On a slower machine, where I played with 168 a sleep 3 (for good measure - worked with 2 secs. as well) just before the end (::) of the start case completely quieted down the things for me. -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
setclock Question (lfs-bootscripts-20110424)
htmlhead link media=all type=text/css href=/netmail/static/deg/css/wysiwyg-3933289048.css rel=stylesheet /headbody Hello,brbrI'm confused about 'setclock' script activation in the boot sequence.brMaybe I'm missing something:brnbsp;seems to have disappeared from '/etc/rc.d/rcsysinit.d/'.brbrThanks,br-- Alexbr /body/html -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
setclock Question (lfs-bootscripts-20110424)
Hello, I'm confused about 'setclock' script activation in the boot sequence. Maybe I'm missing something: seems to have disappeared from '/etc/rc.d/rcsysinit.d/' Thanks, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: setclock Question (lfs-bootscripts-20110424)
Apr 28, 2011 03:32:59 PM, Andrew Benton wrote: According to 55-lfs.rules udev should run the setclock script when /dev/rtc becomes available. Does /dev/rtc exist? Maybe you configured your kernel without real time clock support? It seems we're in the fortunate situation here where people can choose their individual way of skinning the cat. In the hwclock manual section, How hwclock Accesses the Hardware Clock: hwclock uses many different ways to get and set Hardware Clock values. The most normal way is to do I/O to the device special file /dev/rtc, which is presumed to be driven by the rtc device driver. However, this method is not always available. For one thing, the rtc driver is a relatively recent addition to Linux. Older systems don't have it. ... I do have /dev/rtc (set up by udev now). I always had it in the kernel and set up one way or another. However I always did setclock _before_ starting udev, for various reasons, like seeing some reasonable times of device creation. Anyway, this was LFS bootscript style in the past, thus my confusion not seeing setclock' script as part of a 'rcsysinit.d' sequence. Actually, to be exact, rtc was set in modules. Even today, in 'rcsysinit.d', I have ... modules setclock udev ... with modules empty :(. In my case, setclock does something like hwclock --hctosys --localtime and I've always relied on the CMOS battery holding up solid. Notes: 1. Even if I delete the rtc device: [/dev]$ ls -l rtc crw-r--r-- 1 root root 10, 135 2011-04-28 16:04 rtc [/dev]$ rm -f rtc the command 'hwclock --hctosys --localtime' still works OK (so the manual is relatively good, after all :). As I implied, no complaints on the boot-up where /dev/rtc hasn't been born yet.. 2. As a life style, I frequently connect into cyberspace from the command line and in doing so I update my time from the satellites ntpd -q 3. Maybe I should put rtc back in modules so hwclock is forced to use '/dev/rtc' (?) Thanks, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Firefox-4.0
Mar 27, 2011 12:47:52 PM, Andrew Benton wrote: Alex: I tried my damnedest; each time I use --with-system-png the compile fails Can we see the actual error message (and some lines of context before the crash happens). Maybe we can find a fix for you? Hi Andy, Thank you very much. Please bear with me about (hopefully) an hour or so after this post. I'm submitting a Bug report as we speak. I'll let you know the Bug # You'll be cordially invited to attend:) Thanks, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
As promised, I ran a number of tests to clarify Udev interaction with '/lib/udev/devices/' and the creation of some essential nodes during a boot-up. PRELIMINARIES A. [/sbin]$ strings udevd | grep devices /lib/udev/devices /devices/ So, 'udevd' is aware of '/lib/udev/devices/' directory and, as we will see later, has a keen interest in its contents. B. Excerpt of '/etc/rc.d/init.d/udev' script used during the tests. I inserted six Sample lines in the original script (their position in the udev script code is shown preceded by a +++ string, so as to stand out. start) +++ /dev content Sample No 1. boot_mesg Populating /dev with device nodes... ... if ! mountpoint /dev /dev/null; then mount -n -t tmpfs tmpfs /dev -o mode=755 ... +++ /dev content Sample No 2. ... echo /proc/sys/kernel/hotplug +++ /dev content Sample No 3. ... cp -a /lib/udev/devices/null /dev ... /sbin/udevd --daemon +++ /dev content Sample No 4. ... /sbin/udevadm trigger --action=add +++ /dev content Sample No 5. ... /sbin/udevadm settle evaluate_retval +++ /dev content Sample No 6. ;; C. The cp -a ...null /dev line above was commented out at all times. Actually, nothing ever changed in B. D. In Sample No 1. (i.e., the metal /dev) the 'null' node is always the same. Example (shown here in full), crw-rw-rw- 1 root root 1, 3 2011-02-23 06:28:02.0 null crw--w--w- 1 root root 5, 1 2011-03-04 13:14:57.0 console Consequently, Sample No 1. will not be covered further. Note: As already mentioned, I think 'console' is handled by the kernel itself (somehow). BTW, unlike 'null', the 'console' time and date always change. E. The Samples have been edited for conciseness, so only the node time is shown in what follows (i.e., no type, permissions, ownership, or major/minor numbers). F. System (B)LFS i686-pc-linux-gnu, 2.6.37.1, Udev-166 LFS book: Version SVN-20110218 Script activation order in '... rcsysinit.d/': mountkernfs consolelog modules (no modules to install, in my case) udev ... FWIW, an excerpt of my 'fstab': devpts /dev/pts devpts gid=4,mode=620 0 0 shm /dev/shm tmpfs defaults0 0 Obviously, other people's mileage may vary. TEST RESULTS Test No 1. Missing (no) '/lib/udev/devices/' directory ~ Excerpt from console log: Remounting root file system in read-write mode... [ OK ] Recording existing mounts in /etc/mtab...[ OK ] Mounting remaining file systems... mount: mount point /dev/pts does not exist mount: mount point /dev/shm does not exist [ FAIL ] -- 'null' and 'console' presence: 'null': Sample No 5.: 2011-03-04 13:14:57.413999850 Sample No 6.: 2011-03-04 13:14:57.413999850 'console': Sample No 5.: 2011-03-04 13:14:57.416999850 Sample No 6.: 2011-03-04 13:14:57.416999850 Test No 2. '/lib/udev/devices/' with 'pts', 'shm' and 'null (no console) ~~~ NO console log problems. --- 'null' and 'console' presence: 'null': Sample No 4.: 2011-03-04 13:45:14.343999850 Sample No 5.: 2011-03-04 13:45:14.417999850 Sample No 6.: 2011-03-04 13:45:14.417999850 'console': Sample No 6.: 2011-03-04 13:45:14.431999850 Note: In '/lib/udev/devices/', 'pts' and 'shm' directories are empty. Test No 3. '/lib/udev/devices/' with 'pts', 'shm' and 'console' (no null) ~~ Excerpt from console log: Populating /dev with device nodes... cannot open /dev/null udevd[513]: cannot open /dev/null udevd-work[518]: open /dev/null failed: No such file or directory ... same for udevd-work[537], [538],[539],[540],[542],[545],[550],[575],[578],[588] and [605] ... FATAL: Module acpi:LNXSYSTM: not found. FATAL: Module pci:v8086d2983sv... not found. FATAL: Module pci:v8086d2930sv... not found. FATAL: Module pci:v8086d2940sv... not found. FATAL: Module pci:v8086d244Esv... not found. insmod /lib/modules/2.6.37.1/kernel/drivers/char/agp/agpgart.ko Linux agpgart interface v0.103 insmod /lib/modules/2.6.37.1/kernel/drivers/char/agp/intel-gtt.ko insmod /lib/modules/2.6.37.1/kernel/drivers/char/agp/intel-agp.ko agpgart-intel :00:00.0: Intel G35 Chipset agpgart-intel :00:00.0: detected gtt size: 524288K total, ... Notes: our mutual friend, LNXSYSTM, is being sorely missed here :). lines like insmod ... driver.ko, out in the open, look a little unusual to me, but what do I know ... -- 'null' and 'console' presence: Sample No 4: 2011-03-05 06:51:01.344999850 console Sample No 5: 2011-03-05 06:51:01.405999850 console Sample No 6: 2011-03-05 06:51:01.417999850 null 2011-03-05 06:51:01.420999850 console Note: 'null' makes its re-entrance after all (a little tardy, though). --
Re: Ruminations on Udev, null and console
Bruce Dubbs wrote: When I rebooted, I got the following messages: cannot open /dev/null ... FATAL: Module LNXSYTEM: not found ... When I added null back to /lib/udev/devices/ and reenabled the copy in the bootscripts, I got none of these messages. ... I don't have any modules to load. No console to update either. I agree that the /dev/null entries in mountkernfs could be removed by using the -q option for mountpoint. I suspect that option was added after the bootscript was written. Actually, on my system, those errors appeared to come up before any bootscripts were started. They came about 4 seconds into the boot. It takes about 8 or 9 seconds to get to the boot prompt. I think those 'module' errors are being generated by drivers built into the kernel. Note that LNXSYTEM is an ACPI device. Since the instruction to copy null to /dev occurs after the error message, I have no idea why they are coming up. Hi Bruce, 1. One thing at a time. To RE-recap the conclusions about null/console situation from my OP and the time-line post: 1.1. The null and console nodes MUST exist in the metal /dev directory before start-up. 1.2 If one follows the LFS script order, the null/console coverage is practically perfect. No gaps. 1.2.1. The metal null disappears after the line if ! mountpoint /dev while heroically taking the last direct hit: /dev/null 1.2.2. null reappears (practically reborn), through some mysterious machinations (more about that later) while still in udev (time-line, sections 5-7), which makes it impossible to be missed by anybody else: The udev script, what with 'udevadm settle' and all, makes sure that unless and until it is done, no other script, program, bash construct, etc. can start and potentially miss null. A corollary of this whole 1.2. is that no scripts ahead of udev can fail, be it the much maligned (by me) rc, or the others, even in their original form (without the -q, _with_ /dev/null). In other words, null (here, in the metal avatar) will always be there, for example to gracefully absorb any blows of the form ... /dev/null. 2. I wish I could help/explain your problem(s) including your suspicion that the udev null copy (or rather the lack of it) has something to do with the errors. I've been wrong before (so many times!). In the beginning of my tests/ruminations, as I mentioned, I made sure I use copies of the latest scripts in their exact sequence: LFS book: Version SVN-20110218 Script activation order in '... rcsysinit.d/': mountkernfs consolelog modules (no modules to install, in my case) udev ... Note: I always boot to INIT level 3. (id:3:initdefault:) That may matter. If you find any similarities, I'd be more than willing to compare notes on this subject. It's definitely an intriguing project. 3. As a general comment, we are all aware that Udev has been a moving target, ever since its inception. No problem with that. It's just that you have to aim more carefully, but there's the risk of being hit right in the face when you become complacent and not continuously on the ball. My parents always told me to be careful with people who say 'if SoAndSo==?* then ...' instead of 'if SoAndSo!= then ...', which _is_ the the same thing, true, but shows those people might not talk straight. 3.1. I have NO idea how all those devices (null, etc.) appear in my main-line section 5, as if out of thin air. Does udevd take a peak in my forgotten directory '/lib/udev/devices' (we _know_ Udev _knows_ about '/lib/udev/', for the rules)? Does it have its own internal rules? On a personal level, this is to me the last missing piece of my otherwise pretty airtight (I think) coverage of Udev activities on _my_ system and _my_ hardware. I'll be away from the test machine for a couple of days. As soon as I'm back, you can be sure I'll start looking hard into this quandary and the copy implications. By way of an example, if you do 'strings udevd | egrep console|null' you get only /dev/null cannot open /dev/null open /dev/null failed: %m and no console, although the console node is there (in Sec. 5). Nor if you grep for console among the rules. Best regards, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
SYSTEM ~~ ASUS P5E-VM HDMI with Intel G35/ICH9R. Intel Core2 Duo CPU E8400 @ 3.00GHz, 4GB (B)LFS i686-pc-linux-gnu, 2.6.37.1, Udev-166 PROBLEM ~~~ No problems. I'm just trying to recap and maybe bring this thread to a merciful end. In the following, I'm trying to present a time-line on my system showing the console and null activities. (i.e., back to the OP, but hopefully in a cleaner, logical fashion.:) So I ran a boot-up test with a few strategically placed time stamps in setclock, moutkernfs and udev scripts, a summary of the results shown below. The text can also serve as preparatory course for beginning students in 101 Udev :). Prerequisites: /sys and tmpfs. NOTES ~ No 'cp -a /lib/udev/devices/ ...' _whatsoever_ in udev script. The dates/times are shown in sequence (when applicable). The times are node/file _modification_ time. The creation and/or access times would just clutter up the text without bringing anything interesting to the table (IMHO). TIME STAMPS ~~~ 1. metal /dev: 2011-02-22 13:26:28.0 + console 2011-02-23 11:28:02.0 + null 2. Machine booting up. At start of mountkernfs (before the /proc and /sys mounts): 2011-02-28 14:43:58.0 -0500 console 2011-02-23 06:28:02.0 -0500 null 3. udev script (before 'mount ... tmpfs /dev ...'): 2011-02-28 14:43:58.0 -0500 console 2011-02-23 06:28:02.0 -0500 null 4. udev (after 'mount ... tmpfs /dev ...'): Nothing. The two metal /dev nodes are hidden now. 5. udev (after '/sbin/udevd --daemon'). All existing /dev nodes: 2011-02-28 14:43:58.285999850 -0500 stdout - /proc/self/fd/1 2011-02-28 14:43:58.285999850 -0500 stdin - /proc/self/fd/0 2011-02-28 14:43:58.285999850 -0500 stderr - /proc/self/fd/2 2011-02-28 14:43:58.295999850 -0500 shm 2011-02-28 14:43:58.295999850 -0500 pts 2011-02-28 14:43:58.295999850 -0500 null 2011-02-28 14:43:58.331999850 -0500 kmsg 2011-02-28 14:43:58.285999850 -0500 fd - /proc/self/fd 2011-02-28 14:43:58.285999850 -0500 core - /proc/kcore 2011-02-28 14:43:58.295999850 -0500 console 6. udev (after '/sbin/udevadm trigger --action=add') Same as 5. above (i.e., no time changes, no new devices) 7. udev (after '/sbin/udevadm settle') Note: Practically most /dev nodes are now in place. Only our important friends, console and null, are shown: 2011-02-28 14:43:58.374999850 -0500 console 2011-02-28 14:43:58.375999850 -0500 null 8. For reference only: 8.1. After INIT: version 2.86 booting Before mountkernfs:2011-02-28 14:43:58.039068843 8.2. setclock, after Setting system clock... 2011-02-28 19:44:01.000687543 8.3. Just before the prompt (last line in rc.local): 2011-02-28 19:44:03.472291634 8.4. Last reboot: Mon Feb 28 19:44:01 FINAL WORDS ~~~ A. Please notice that the date of console changes between (1) and (2) above to boot date and time. My only explanation (a little weak) is that happens when the kernel creates the console. - Excerpt from console log: ... NR_IRQS:320 Console: colour VGA+ 80x25 console [tty0] enabled Fast TSC calibration using PIT Detected 3005.093 MHz processor. ... - This seems to be confirmed by 'sys.log' and 'kernel.log' Feb 28 19:44:01 localhost kernel: NR_IRQS:320 Feb 28 19:44:01 localhost kernel: CPU 0 irqstacks, ... Feb 28 19:44:01 localhost kernel: Console: colour VGA+ 80x25 Feb 28 19:44:01 localhost kernel: console [tty0] enabled Feb 28 19:44:01 localhost kernel: hpet clockevent registered Feb 28 19:44:01 localhost kernel: Fast TSC calibration using PIT Feb 28 19:44:01 localhost kernel: Detected 3005.251 MHz processor. B. According to my tests, the metal console is needed. Without it, for reasons unknown, there's no LFS console display (NO boot_mesg() output, OK, etc) at boot. After that, the display mysteriously becomes active. Say, /etc/rc.d/init.d/gpm restart Stopping gpm... [ OK ] Starting gpm... [ OK ] This one I cannot explain, even weakly. C. As nit-pickings (no urgency, we know how long it takes to change will with must in the next (almost) daily revision of the book:) C.1. 6.2.21 should say must instead of will C.2. The whole Create some devices and directories ... in udev-1xx should go. Misleading, outdated and nonsensical. C.3. Instead, users should be urged to boot their /dev partition for somewhere else (another partition, LiveCD) and make sure they have these two, and preferably only these two nodes set up. Thanks you all for your contributions, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
Bruce Dubbs wrote,
It's in section 6.2.1, not 6.2.21
Hi Bruce,
Typo. Sorry.
C.2. The whole Create some devices and directories ... in
udev-1xx should go. Misleading, outdated and nonsensical.
No, it really can't go. I went into my sandbox, deleted
/lib/udev/devices/null, and commented out the copy to /dev in the udev
bootscript.
When I rebooted, I got the following messages:
cannot open /dev/null
FATAL: Module platform: regulatory not set
FATAL: Module LNXSYSTEM: not found
FATAL: Module doc not found
FATAL: pci:v... not found
This last was repeated about 20 times for various pci values.
When I added null back to /lib/udev/devices/ and reenabled the copy in
the bootscripts, I got none of these messages.
Awful. A few thoughts.
As I said in my OP:
LFS book: Version SVN-20110218
Script activation order in '... rcsysinit.d/':
mountkernfs
consolelog
modules (no modules to install, in my case)
udev
...
iN MY PREvious post, sections 5-7, null (and console) is already fully
represented. Unfortunately, modules comes before udev:
In modules,
modprobe ${module} ${args} /dev/null
# Print the module name if successful,
# otherwise take note.
if [ $? -eq 0 ]; then
boot_mesg -n ${module} ${NORMAL}
else
...
the construct /dev/null could be avoided, I think.
'modprobe' offers -q (like 'mountpoint', previously) without
any apparent loss of functionality (if [ $? -eq 0 ] ...).
If you use -q in mountkernfs and udev, the only null's left
are in rc, in the two 'for' loops:
for i ... 2 /dev/null
I just removed the 2 /dev/null and I haven't encountered
any problems as yet (nor extra messages on the console log).
I'm definitely uneasy for situations like,
ls -v /etc/rc.d/rc4.d/K*
ls: cannot access /etc/rc.d/rc4.d/K*: No such file or directory
for level 4 and also for 5.
Obviously, there are a gazillion of systems out there
and this is just one of the myriad ways to skin a cat.
(I do with compassion:)
Thank you for your comments,
-- Alex
For reference, an extract from my OP:
[udev]
The irony here is that 'mountpoint' offers a -q option.
2. mountkernfs script coming before udev in the boot
sequence (_has_ to mount 'sys') has two offending lines
with /dev/null. Can be corrected with a -q.
A bigger problem is presented by rc.
rc is the first in line, so to speak, so it can get ugly.
Has two for lines with 2 /dev/null.
My system hangs, with two error lines around INIT:
... init.d/rc: ... /dev/null: Read-only file system
I deleted the two 2 /dev/null's, and damn the torpedoes.
So far, I've lived to tell this story here.
Please note that (2) rc above was happening when
I was experimenting with NO metal null.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
Feb 25, 2011 04:26:29 AM, Simon Geard wrote: On Wed, 2011-02-23 at 12:24 -0600, al...@verizon.net wrote: BTW, there is a [rant][/rant] I'm skipping, although the idea is not the first time to come up, where people grow from LFS to BLFS and become confused and/or _misunderstood_ about falling behind on the latest and greatest developments in LFS (my LFS system was built early 2005). I'm guessing you don't run a 'modern' desktop then? It's pretty much impossible to build and run a modern Gnome desktop without using udev - mostly because udev these days isn't just about populating /dev nodes, it's also how you identify what hardware is present. Hi Simon, There's a very unfortunate misunderstanding here. Maybe in debating with Neil and Bruce lately on my thread you forgot who started the thread, _why_ and how. However, it may be mostly my fault here, what with my rambling and incoherent style of mine; whatever, I'll try my level best to restate the situation as clearly as I can, and to avoid redundancy, to use mostly cut-and-paste sections from my original statements (made in my only _two_ posts). Enclosed in double angle brackets. 1. The _very first_ paragraph of my OP: SYSTEM (B)LFS i686-pc-linux-gnu, 2.6.37.1, Udev-166 LFS book: Version SVN-20110218 Does it look like I don't run a 'modern' desktop? It's for you to decide. :) without using udev?: Script activation order in '... rcsysinit.d/': mountkernfs consolelog modules (no modules to install, in my case) udev ... INTRODUCTION While my system has worked well for a long time, a few lines (actually, two commands) in the 'udev' script like ... started to puzzle me more and more as time passed ... It's for you to decide :) 2. _Strictly_ for the record and completeness: I do no use Gnome. Never have. I use KDE (3.5.10) and Fluxbox (1.1.1). However, IMHO this is absolutely irrelevant as far as the thread subject is concerned. Unfortunately, the above admission might trigger another unrelated debate :( I'm resigned to it, though; you win a few lose a few. 3. Now, for my main subject, restated and summarized differently, in desperate hopes of making it clearer. 3.1. Don't remember exactly what Udev I started with and when. I came across some e-mails to Kay Sievers (of April, 2007): ... 686-pc-linux-gnu (B)LFS 2.6.20 UDEV upgrade from 105 (OK) to 108. ... I also don't remember if 6.2.21 was in the exact, clear form you cited to me (excerpt here), When the kernel boots the system, it requires the presence of a few device nodes, in particular the console and null devices. The device nodes will be created on the hard disk so that they are available before udevd has been started, and additionally when Linux is started with init=/bin/bash. Create the devices by running the following commands: ... (while we're talking about clarity here, a little nitpick: will be created should be replaced with must be created) It wouldn't matter anyway, because as I said I had had those two nodes [on the metal /dev] all along (instinctively) I set up my metal /dev with ... crw--- ... 5, 1 ... /dev/console and also ... crw-rw-rw- ... 1, 3 ... /dev/null 3.2. The PROBLEM (the actual object of the OP) has been my worries started recently when _finally_ a [light] bulb went [off] in my head on reading # Create some devices and directories that Udev cannot handle # due to them being required very early in the boot process, # or by Udev itself: ... mknod -m0666 /lib/udev/devices/null c 1 3 in the LFS udev-166 procedure AND # Copy the only static device node that Udev = 155 doesn't # handle to /dev cp -a /lib/udev/devices/null /dev in the latest udev script. In other words, the above two commands are in contradiction to 6.2.21 (as cited by you), and redundant (and _misleading_) . I.e., in yet some other words, the author(s) of the udev script and udev installation procedure (this fallacy goes back quite a few iterations from 166) should re-read 6.2.21 even harder than me. In delicate terms, there should be a co-ordination somewhere. So I ... started testing (and ruminating) hard. 3.3. Speaking of co-ordination, and my [rant][/rant] ... skipping in a few words, it appears that for some reason, in some quarters it can be incomprehensible the fact that one can simply graduate from LFS to BLFS (_on the same system_, no less!) while being forced to keep up with Udev, Kernel versions and latest scripts, and/or electing to partake of some other goodies that LFS offers. The post I'm responding to seems to be an example of that. Thanks, -- Alex PS Could it be I write (B)LFS and there's another shortcut more accepted and better conveying the fact that I'm talking about a system that started as LFS (in 2005, as I said) and grew to BLFS ? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ:
Re: Ruminations on Udev, null and console
Feb 25, 2011 03:11:51 PM, Bruce Dobbs wrote: I haven't looked at this code in quite a while, but I don't see these instructions as contradictory. Hi Bruce, I commented out 'cp -a /lib/udev/devices/null /dev' in udev script. and did a reboot. _I_ didn't notice any changes (messages, etc.) in the console log on boot. Nor in dmesg. However, it's possible that my basic system differs somehow, somewhere on LFS boot. Newer versions of udev or the kernel may make some of these procedures unnecessary, but they don't hurt anything. A device node takes up 1 directory entry and no additional space. Agreed. BTW, I didn't say they are contradictory. Just redundant (and _misleading_). Misleading (IMHO) because either use both copies (i.e., _and_ console) or none at all. Let's not forget, though, I started with ruminations, not complaints (or some such). I don't understand what appears to be a sense of urgency in your post. No urgency (or sense of it) at all: _finally_ ... this fallacy goes back quite a few iterations from 166. However, I apologize for the word fallacy. Way too strong and misleading:). What are the drawbacks of the procedure as is? None. It works. I did express my gratitude to all involved for their hard work to make our life easier. --- I do have a confusion underlying this thread. I have claimed (possibly wrongly), the Udev philosophy assumes a /dev absolutely empty. Are the initial (metal) null and console nodes an LFS specific requirement (based on its particular boot/log sequence I tested and confirmed by 2.6.21), is it sanctioned by Udev developers, and/or a pure Udev is supposed to start with /dev really empty? Thank you very much, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
Feb 23, 2011 04:58:10 AM, Simon Geard wrote: ... those nodes [null and console] are supposed to be there in /dev on the root partition. If you don't have them, you've missed a step in the build. Hi Simon, We're totally in sync here (if you take a look at the grand finale of my OP :) I had had those two nodes all along (instinctively) and everything had been fine. To clarify: my worries started recently when _finally_ a bulb went on in my head on reading Create some devices and directories that Udev cannot handle due to them being required very early in the boot process, or by Udev itself: ... mknod -m0666 /lib/udev/devices/null c 1 3 in the LFS udev-166 procedure AND followed by # Copy the only static device node that Udev = 155 doesn't # handle to /dev cp -a /lib/udev/devices/null /dev in the latest udev script. So I said (to myself), something must be different now i.e., there's no way somebody would've added (or retained) the redundant (and _misleading_) null copy above unless something changed (from 6.2.1 - or, come to think of it, from common sense). It is not unknown, even in the heavily computerized world of ours, for things to be changed (updated, as they say) in only _some_ of the related places. So I went back to the LFS scripts, made sure I was using the most recent ones and started testing (and ruminating) hard. BTW, there is a [rant][/rant] I'm skipping, although the idea is not the first time to come up, where people grow from LFS to BLFS and become confused and/or _misunderstood_ about falling behind on the latest and greatest developments in LFS (my LFS system was built early 2005). Thank you for your (as always) insightful comments, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Ruminations on Udev, null and console
Hello, SYSTEM (B)LFS i686-pc-linux-gnu, 2.6.37.1, Udev-166 LFS book: Version SVN-20110218 Script activation order in '... rcsysinit.d/': mountkernfs consolelog modules (no modules to install, in my case) udev ... INTRODUCTION While my system has worked well for a long time, a few lines (actually, two commands) in the 'udev' script like # Mount a temporary file system over /dev, so that any devices # made or removed during this boot don't affect the next one. if ! mountpoint /dev /dev/null; then mount -n -t tmpfs tmpfs /dev -o mode=755 and later on # Copy the only static device node that Udev = 155 doesn't # handle to /dev cp -a /lib/udev/devices/null /dev started to puzzle me more and more as time passed. The results of my reflections and relatively extensive testing are presented in the following SUBJECT. Of course, I can be totally or partially wrong in my conclusions (no surprise here:). However, maybe there's something for some of us to learn if a gentle, knowledgeable soul (or two) will take the time to look at my words and make some useful comments and/or straighten me out if need be. SUBJECT 1. Based on the basic UDEV philosophy (and reiterated in the 'udev' script comments (above, the # lines)), /dev should be populated with only nodes for devices existing on or strictly needed by the particular system when active. While not specifically stated, one can assume that before booting, the machine's metal /dev should be totally empty. By metal /dev, I mean the main '/dev' directory as it sits passively on the pure metal, as seen from, say, a booted LiveCD. As an example, for my Linux system on /dev/sda3: mount ... /dev/sda3 /mnt ls -l /mnt/dev The output should show an empty '/mnt/dev' (again, if one reads the main Udev concept correctly). In this case the construct /dev/null in the mount is wrong, especially as the second command confirms we do need a '/dev/null' node, not present as yet. (the smoking gun is a console message complaining that ... rcsysinit.d/S10udev: ... /dev/null: Read-only file system More about console later) The irony here is that 'mountpoint' offers a -q option. 2. mountkernfs script coming before udev in the boot sequence (_has_ to mount 'sys') has two offending lines with /dev/null. Can be corrected with a -q. A bigger problem is presented by rc. rc is the first in line, so to speak, so it can get ugly. Has two for lines with 2 /dev/null. My system hangs, with two error lines around INIT: ... init.d/rc: ... /dev/null: Read-only file system I deleted the two 2 /dev/null's, and damn the torpedoes. So far, I've lived to tell this story here. 3. However, two questions I agonized the most over: 3.1. How come, despite all these problems I found on my machine people reboot their systems day in and day out without any reported complaints? If they had any grievances on this subject, they'd be out in the streets like anybody else these days. Am I the only confused fella here ?! 3.2. How come people are not missing the beautiful (and useful) console boot displays [boot_mesg() in functions] which, on my system would not appear unless my metal /dev contained the console node. A partial explanation, I said (to myself) would be the introduction of KMS on all modern Linux releases. We've already seen some of the benefits of this invention; the first section of the boot console log vanishes forever (with all the juicy stuff) at the point the KLM module is loaded (late), so if the machine comes up good, who cares!? (based on the old adage, what you don't see can't hurt you) Note: dmesg and other logs do not show these pesky Read-only file... lines, and who in his right mind checks the dmesg on a good start-up anyway?. But how about the rc hangs, the console logs and the like? Here I think I finally came to the big, all-encompassing answer:) Unaware, many people still carry a lot of old stuff (including console and null) on their metal /dev. So they don't see (even if they'd want to) those nasty messages. All the dev/null errors are gone, the console log messages look as pretty as ever (in color too), etc. As I implied in the beginning, I also feel good and the reason for that is I set up my metal /dev with the good, old crw--- ... 5, 1 ... /dev/console and also swallowed my pride and added a nice crw-rw-rw- ... 1, 3 ... /dev/null for good measure. Notes: 1. cp ... console /dev in 'udev' script doesn't work. (apparently, too late in the boot sequence.) 2. For reasons unknown, even if I start with the metal /dev empty, I end up with both null and console nodes in /dev at the end of boot. Go figure. The Udev police may get me one day but in the meantime I can have my full, CLEAN console log _and_ still use the excellent scripts Mr. Beekmans and all the other collaborators worked
Re: Udev - USB Keyboard questions
Feb 3, 2011 01:19:42 PM, Stuart Stegall wrote: [the keyboard] It's still being detected as a keyboard right? Hi Stuart, Yes. As I alluded in my OP a few times, I never had any problems with the keyboard and mice (they do act as one would expect a keyboard and a mouse to at all times) Send your complete X log and dmesg log. (Minus anything you need to scrape.) Only the dmesg this time (fully unscraped though :). As I alluded in my OP a few times, the problem I see occurs on boot-up and seems to stem from something funny happening between the kernel and Udev. Let's pretend I don't even have (or use) graphics (i.e. X of some form and version). I sit (and I have the right to) in command mode (prompt, text mode) all day long. I'd highly appreciate if in conjunction with my OP, you would help me with something untoward you detected in the boot-up dmesg attached. If we find something that solves the problem we'll _then_ worry about graphics behavior if need be. It's not uncommon for Mice to be detected as Keyboards, Mice, and Joysticks depending on the mouse's advertisements. I would imagine your keyboard is the same way. If several mice/keyboards detected and improperly assigned drivers to is a relatively common phenomenon, we'll have to wait (don't we?) for the day where the Linux kernel/Udev developers manage to detect only one device per each device, and _correctly_ to boot (like they already do with USB printers, keys and other USB/non-USB devices.) As an aside, seems like M$ overcame the advertisement hurdle quite a while ago. As a help/reminder, I'm restating the questions in the title of the OP, Udev - USB Keyboard questions: QUESTIONS 1. Why does the _kernel_ appears to see the USB keyboard (and the mouse, FTM - not shown here) twice? 2. Why does the _kernel_ forces js on my poor keyboard? 'Documentation/devices.txt' states 13 charInput core 0 = /dev/input/js0First joystick Thanks, -- Alex Linux version 2.6.37 (root@AlexLFS) (gcc version 4.1.2) #1 SMP Tue Jan 25 12:25:37 EST 2011 BIOS-provided physical RAM map: BIOS-e820: - 0009ec00 (usable) BIOS-e820: 0009ec00 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - cf78 (usable) BIOS-e820: cf78 - cf78e000 (ACPI data) BIOS-e820: cf78e000 - cf7e (ACPI NVS) BIOS-e820: cf7e - cf80 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: fff0 - 0001 (reserved) BIOS-e820: 0001 - 00013000 (usable) Notice: NX (Execute Disable) protection cannot be enabled: non-PAE kernel! DMI 2.4 present. DMI: P5E-VM HDMI/P5E-VM HDMI, BIOS 060407/16/2008 e820 update range: - 0001 (usable) == (reserved) e820 remove range: 000a - 0010 (usable) last_pfn = 0xcf780 max_arch_pfn = 0x10 MTRR default type: uncachable MTRR fixed ranges enabled: 0-9 write-back A-B uncachable C-D write-protect E-E write-through F-F write-protect MTRR variable ranges enabled: 0 base 0D000 mask FF000 uncachable 1 base 0E000 mask FE000 uncachable 2 base 0 mask F write-back 3 base 1 mask FE000 write-back 4 base 12000 mask FF000 write-back 5 base 0CF80 mask FFF80 uncachable 6 disabled 7 disabled x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 original variable MTRRs reg 0, base: 3328MB, range: 256MB, type UC reg 1, base: 3584MB, range: 512MB, type UC reg 2, base: 0GB, range: 4GB, type WB reg 3, base: 4GB, range: 512MB, type WB reg 4, base: 4608MB, range: 256MB, type WB reg 5, base: 3320MB, range: 8MB, type UC total RAM covered: 4088M Found optimal setting for mtrr clean up gran_size: 64K chunk_size: 16M num_reg: 6 lose cover RAM: 0G New variable MTRRs reg 0, base: 0GB, range: 2GB, type WB reg 1, base: 2GB, range: 1GB, type WB reg 2, base: 3GB, range: 256MB, type WB reg 3, base: 3320MB, range: 8MB, type UC reg 4, base: 4GB, range: 512MB, type WB reg 5, base: 4608MB, range: 256MB, type WB e820 update range: cf80 - 0001 (usable) == (reserved) found SMP MP-table at [c00ff780] ff780 initial memory mapped : 0 - 0080 init_memory_mapping: -377fe000 00 - 40 page 4k 40 - 003740 page 2M 003740 - 00377fe000 page 4k kernel direct mapping tables up to 377fe000 @ 7fb000-80 ACPI: RSDP 000fbc70 00014 (v00 ACPIAM) ACPI: RSDT cf78 00040 (v01 A_M_I_ OEMRSDT 07000816 MSFT 0097) ACPI: FACP cf780200 00084 (v02 A_M_I_ OEMFACP 07000816 MSFT 0097) ACPI: DSDT cf7805c0 08D10 (v01 A0867 A0867001 0001 INTL 20060113) ACPI: FACS cf78e000 00040 ACPI: APIC cf780390 0006C (v01 A_M_I_ OEMAPIC 07000816
Udev - USB Keyboard questions
(B)LFS i686-pc-linux-gnu, 2.6.37, Udev-165. Keyboard: Microsoft ANB-1 Black 104 Normal Keys USB Wired Slim Keyboard 600 Hello, INTRO I got into some slight and strange (for me) problems in tuning up my Xorg-7.6 experience. Unimportant for the subject questions to follow. However, the connection between the above and what follows is the way Udev has been discovering and setting up my input devices, the mouse and the keyboard. I treated this issue a little cavalierly - after all everything basically works, at command line and later in X - but what with Xorg-7.6 logs and all, I started scratching my head harder and harder. SUBJECT 1. On boot-up, both the USB mouse and USB keyboard seem to be counted twice (to my layman's eye). (example below is a boot console extract for the subject keyboard): usb 5-2: new low speed USB device using uhci_hcd and address 2 input: Microsoft Wired Keyboard 600 as /devices/pci:00/:00:1a.2/usb5/5-2/5-2:1.0/input/input4 generic-usb 0003:045E:0750.0002: input: USB HID v1.11 Keyboard [Microsoft Wired Keyboard 600] on usb-:00:1a.2-2/input0 input: Microsoft Wired Keyboard 600 as /devices/pci:00/:00:1a.2/usb5/5-2/5-2:1.1/input/input5 generic-usb 0003:045E:0750.0003: input: USB HID v1.11 Device [Microsoft Wired Keyboard 600] on usb-:00:1a.2-2/input1 Please note the 5-2:1.0 and 5-2:1.1 and about four different inputX's. 2. Recently, as I said, I got curioser and curioser, so this is an excerpt from the output of 'udevadm monitor' on replugging the keyboard: ... KERNEL add /devices/pci:00/:00:1a.2/usb5/5-2/5-2:1.0/input/input8/event4 (input) ... KERNEL add /devices/pci:00/:00:1a.2/usb5/5-2/5-2:1.1/input/input9/js0 (input) Udev dutifully reacts to the kernel events and does, respectively: UDEV add /devices/pci:00/:00:1a.2/usb5/5-2/5-2:1.0/input/input8 (input) UDEV add /devices/pci:00/:00:1a.2/usb5/5-2/5-2:1.1/input/input9 (input) ... UDEV add /devices/pci:00/:00:1a.2/usb5/5-2/5-2:1.1/input/input9/js0 (input) UDEV add /devices/pci:00/:00:1a.2/usb5/5-2/5-2:1.0/input/input8/event4 (input) ... Please note a related typical output: ls -l /dev/input drwxr-xr-x 2 root root 120 2011-02-02 14:56 by-id drwxr-xr-x 2 root root 160 2011-02-02 14:56 by-path crw-r- 1 root root 13, 64 2011-02-02 14:56 event0 crw-r- 1 root root 13, 65 2011-02-02 14:56 event1 crw-r- 1 root root 13, 66 2011-02-02 14:56 event2 crw-r- 1 root root 13, 67 2011-02-02 14:56 event3 crw-r- 1 root root 13, 68 2011-02-02 14:56 event4 crw-r- 1 root root 13, 69 2011-02-02 14:56 event5 crw-r--r-- 1 root root 13, 0 2011-02-02 14:56 js0 crw-r- 1 root root 13, 63 2011-02-02 14:56 mice crw-r- 1 root root 13, 32 2011-02-02 14:56 mouse0 Another note: For the above machinations, Udev uses mostly the rules in file '/lib/udev/rules.d/60-persistent-input.rules' QUESTIONS 1. Why does the _kernel_ appears to see the USB keyboard (and the mouse, FTM - not shown here) twice? 2. Why does the _kernel_ forces js on my poor keyboard? 'Documentation/devices.txt' states 13 charInput core 0 = /dev/input/js0First joystick Note: as an aside, this gets me in real trouble later, on X start-up: (EE) Microsoft Wired Keyboard 600: failed to initialize for relative axes. (WW) Microsoft Wired Keyboard 600: found 37 axes, limiting to 36. (II) Microsoft Wired Keyboard 600: initialized for absolute axes. (II) config/udev: Adding input device Microsoft Wired Keyboard 600 (/dev/input/js0) It appears the keyboard (as js0) is seen by people as a joystick with a lot of axes; looks like only two axes (H and V) to me. Thanks, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Luit questions (Xorg-7.6)
Jan 30, 2011 11:20:29 PM, lfs-support@linuxfromscratch.org wrote: Sorry for the late reply. I don't frequent LFS-Support (This belongs on BLFS-Support or even BLFS-Dev). Hi DJ, The fault is mine; should've used BLFS-Support. Apologies. Anyway, thanks for the clear reply and Xorg-7.6 procedure, in general.. Best Wishes, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Luit questions (Xorg-7.6)
BLFS Development svn-20110124 * January 23rd, 2011 + [dj] - Removed luit from the book as it is now installed as part of Xorg Applications. Hello, luit-1.1.0 is in the Xorg-7.6 wget list (no surprize here). 1. luit is not in the applications Installed Programs list 2. For applications, the standard compile command is given as ./configure $XORG_CONFIG In the old days (say, Xorg-7.5) luit would be compiled with ./configure $XORG_CONFIG \ --with-localealiasfile=$XORG_PREFIX/share/X11/locale/locale.alias What gives? PS - while here, I've noticed Util's are built before Proto's. Any reason? Thanks, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
2.6.37 Crashes on Xorg7.5/intel
Hello, ASUS P5E-VM HDMI with Intel G35/ICH9R. Intel Core2 Duo CPU E8400 @ 3.00GHz, 4GB (B)LFS i686-pc-linux-gnu 2.6.37 I upgraded to 2.6.37 (from 2.6.36.2) and, for the first time in recent memory, the system freezes solid on trying to go to graphics. My long standing intel driver seems to disagree with 2.6.37: X.Org X Server 1.7.3 Release Date: 2009-12-3 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32 i686 Current Operating System: Linux AlexLFS 2.6.37 #1 SMP Mon Jan 10 20:36:16 EST 2011 i686 Kernel command line: root=/dev/sda3 Build Date: 21 December 2009 12:52:13AM ... (II) LoadModule: intel (II) Loading /usr/lib/X11/modules/drivers/intel_drv.so (II) Module intel: vendor=X.Org Foundation compiled for 1.7.3, module version = 2.9.1 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 6.0 ... (II) intel(0): Comparing regs from server start up to After PreInit (==) Depth 24 pixmap format is 32 bpp (II) intel(0): Kernel reported 803584 total, 0 used (II) intel(0): I830CheckAvailableMemory: 3214336 kB available (II) intel(0): [DRI2] Setup complete (**) intel(0): Framebuffer compression disabled (**) intel(0): Tiling enabled (**) intel(0): SwapBuffers wait enabled (==) intel(0): VideoRam: 262144 KB (II) intel(0): Attempting memory allocation with tiled buffers. (II) intel(0): Tiled allocation successful. (II) intel(0): vgaHWGetIOBase: hwp-IOBase is 0x03d0, hwp-PIOOffset is 0x (II) UXA(0): Driver registered support for the following operations: (II) solid (II) copy (II) composite (RENDER acceleration) (==) intel(0): Backing store disabled (==) intel(0): Silken mouse enabled (II) intel(0): Initializing HW Cursor (II) intel(0): Current clock rate multiplier: 8 (END - i.e., that's all folks: Blank Screen of Death) --- Interestingly (coincidentally?), Linus (himself) makes the following comment in the 2.6.37 release: We did have another revert to fix hopefully the last blank screen regression on intel graphics. https://lkml.org/lkml/2011/1/4/266 I noticed Xorg has been at 7.6 for quite a while. Before BLFS releases the official instructions, maybe I should try to install it on my own in order to test. Good idea? Is it possible Linus tested with (and fixed) the intel driver for 7.6? --- My system references: 'xorg.conf' Section Device ... Identifier Card0 Driver intel VendorName Intel Corporation BoardName ASUS P5E-VM HDMI, Integrated Graphics Chipset: Intel G35 BusID PCI:0:2:0 '/usr/lib/X11/modules/drivers/' 2744358 2009-12-21 01:23 intel_drv.so Thanks, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Udev-165 (apparently) System Crash
On Thu Jan 6 2011 09:24 PM, William Immendorf wrote: Intriguing. This is something that you should report to both LKML and linux-hotplug (the Udev list). Also, be sure to provide the kdump of that kernel, the log, and the hardware that you think is causing the Udev issue. Hi William, First, apologies for getting back to you so late. I deduce you are familiar with Kdump _and_ (B)LFS so maybe you can help me further, beyond sending me to LKML and Udev list (anybody can obviously chime in here with their thoughts): In a nutshell, the basic functionality of a Kdump is, as we all know, for the second,dump-capture kernel to boot as soon as the first, system kernel, crashes and then to capture the preserved memory of the first (crashed) system and write it somewhere for later analysis. So far so good. On an (B)LFS system I see two problems (issues, as they say): 1. On boot, the dump-capture kernel goes through the same steps as the original (system) kernel (mountkernfs, modules, UDEV, swap ...), finds a corrupt file system, fsck's it and then re-reboots into the first, bad, system, and all is lost. 2. In a particular situation like mine (as described in the intro to this thread), the crash happens early in the boot (at UDEV activation) which makes the possible interaction between the crashing system and dump-capture one even more intriguing. As an aside, I suspect these two complications may have something to do with the (B)LFS procedures seemingly not covering the system crashes. Thanks, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: 2.6.37 Crashes on Xorg7.5/intel
Jan 11, 2011 08:39:03 PM, Ken Moffat wrote: Perhaps, you could try a newer xorg intel driver, but it's probably a kernel regression. Hi Ken, Thank you for your interesting and detailed comments. I don't have much choice, so maybe just upgrading the Xorg-7.6's xserver and the intel driver (plus some necessary glue) only for testing the compatibility new-intel-driver vs. 2.6.37 while the dust settles on this issue (I cannot imagine i'm the only victim in this whole, krazy world - that would be too much of eine Tragödie). Thanks again, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Udev-165 (apparently) System Crash
On Thu, 2011-01-06 at 02:08 AM, Simon Geard wrote: ... udevd supports a couple of options that might help, --debug and --debug-trace. 1. FWIW, udevd-165 does not (no-longer?) have a --debug-trace option. Maybe it's undocumented now (shades of Undocumented DOS of yore :) Please see 'man udevd'. 2. For argument sake, udevd writes to sys.log and daemon.log (identically). There are a few things that intrigue me (which might help in my non-kdump troubleshooting, if answered positively): 2.1. Udevd is active way before the main partition becomes read-WRITE (stemming from a chicken and egg situation, I suppose). Be that as it may, where's the mechanism that writes the accumulated udevd log from memory(?) to disk (/var/log/) ultimately (i.e. delayed)? 2.2. Can udevd (syslogd?) output be originally redirected to a different partition where it can go instantaneously, so I can find it postmortem and deduce the hardware element that bothers Udev? syslogd started early for this test, etc. 2.3. More simplistically, can I temporarily mount the main partition writable as soon as Udev discovers it and somehow start syslogd? As I mentioned, the crash occurs a few lines before the end of Udev run, i.e. long after Udev sees the partitions. Would syslogd start writing udevd output to disk immediately? That would involve creating an appropriate rule with some action in it, etc. Maybe splitting the udevd logic in two phases..., etc. I'd appreciate your thoughts. If 2.1-3 above too crazy, please disregard with my apologies. Thanks, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Udev-165 (apparently) System Crash
On Saturday 08 January 2011 02:48 PM Neal Murphy wrote: While I was integrating udev into my test/dev version of Smoothwall ... Hi Neal, This is only to acknowledge and thank you for your detailed comments. I haven't had time to go into any depth at all, what with the NFL playoffs and all, but judging strictly by the size of your comments, I may be on the brink of going kdump after all. I am a bit traumatized by kdump, I remember finding little support for the heavy procedure, + the actual submission which is another put off. If desperate, I'll go the whole 9 yards (maybe even longer). My only hope is if I stall long enough I won't need to do anything any more: online.wsj.com/article/SB10001424052970204527804576043803826627110.html?mod=WSJ_hp_mostpop_read I'll try to absorb and follow your friendly and valuable advice soon. Thanks again, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Udev-165 (apparently) System Crash
On Thu, 2011-01-06 at 02:08:45 AM, Simon Geard wrote ... if the system is completely frozen, it may be hardware related ...Hi Simon,Very good points, overall.When it crashes it's frozen all right (i.e. a crash crash).No hardware changes as of late.Seems some old hardware the latest Udev iteration started disagreeing with.I have a software-"mirror" system, more modern, SATA based, which still boots verysmoothly.If I correctly read the frozen screen, and taking into account the Udev stepwhere the crash occurs, seems an IRQ conflict of some sort.I'll dig into it.The important thing for me is you appear to support me, even if indirectly,in my attempt to avoid kdump in my troubleshoot, if at all possible :)Thank you very much,Best Wishes,-- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Udev-165 (apparently) System Crash
Hello, Hardware: ASUS P4S533-MX, Intel Pentium 4, 3.06 GHz, 1 GB, PATA Software: i686-pc-linux-gnu, (B)LFS, 2.6.36.2, ext2, udev-165 PROBLEM System started crashing on boot-up recently, about 50% of the time. Softly, i.e. after reboot, fsck returns 1 (errors found and corrected). In the Udev discovery section (i.e. toward the end of the boot up sequence). It appears, the whole thing began happening after I installed udev-165. QUESTION Is there a simple way of analyzing the crash, maybe with help of the specialists here, as opposed to formally reporting it? I dread kexec (FWIW, I have kexec-tools-2.0.1 installed and the kernel CONFIGs are set up accordingly) and the KDump procedure (detailed in kdump.txt) is scary. Thank you, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Problem installing the nouveau driver
Simon, Trent, Mike: Thank you very much for the rich, detailed, interesting theories and explanations about video drivers, booting, X, fonts, pixels, my boot-up component steps, etc. All this knowledge and experience is obviously worth a thread of its own, something I'd be following keenly. BUT here, as I said very clearly (hopefully) in my last post, ALL I'm interested in - for the moment - is someone who HAS nouveau active on the machine and has a boot-up experience different than mine (or even identical - the point is to compare notes and for me to steal a few ideas :): Alex (on Jun 29 at 11:26:13 AM) With nouveau, my boot-up goes through these basic steps: 1. The original/regular console sequence (80x25) 2. Nouveau is loaded by UDEV 3. At this point, the console goes blank for a sec or so. The preceding messages are wiped out. 4. The remainder of the boot-up sequence proceeds and stays in 240x67 all the way to the prompt (and beyond). 5. I can never change the 240x67 resolution of the console text mode. QUESTION Does anybody have/see a different behavior? I also appended a Note, not for people to start a dissertation on X (educational as it may be), etc., but maybe to deconfuse some nouveau people who might feel they differ with me on 4 and 5 above, just because they by-pass the text console on their way to graphics bliss. --- THAT'S ALL -- As a reminder, to me the overriding element in this debate is the last two-line E-mail from Stephane (Alex on Jun 28 02:39:05 PM): Alex: Is it possible at all? Stephane: No. --- If you exit X (i.e. graphics mode) to console, you're back to where you'd have started in the first place, still trapped in nouveau text mode, in my case 240x67. Note: I'm obviously not privy to the inner working of nouveau, but I can suspect some people may be trapped in a different text resolution, probably depending on their monitor. However, one of my basic principle in life has always been to adhere, like many others, to the well known dictum, Do not believe in miracles -- rely on them. I tend to believe Stephane, for no other reason than the fact that _he_ wrote nouveau. Thus IMHO (and experience), his No also implies that you can run (into X and use any resolution you want) but when you exit you can't hide (you're still mine, in 240x67). So this is why, hope against hope, maybe, somehow, someday I'd come across somebody who managed to escape Stephane's seemingly impenetrable enclosure in the _real_, nouveau life! Again, NOT in theory. And I understend, say, 80x25 can be (surprize, surprize) in monitor _pixels_. Thanks --- In what follows, just a few loose ends I'd like to tie, Jun 30, 2010 05:28:36 AM Simon wrote Alex said: BTW, the _exact_ steps of how to set a font in kernel which would take effect after nouveau is up, will be highly appreciated. Simon: I've not tried it myself, but take a look in menuconfig under Device Drivers - Graphics Support - Console display driver support - Select compiled-in fonts. I think that if you pick something like VGA 8x16, you'll get something like what you want. But like I said, I've not tried it. Alex: Thank you but if you take another look at one of my configs, # Console display driver support CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y CONFIG_FONT_7x14=y CONFIG_FONT_10x18=y Another guiding principle of mine (to have them there - the day might come where you need them). However, I don't see it having any effect on this case (what with ... kernel vga= ..., or not) once nouveau takes over. --- Something I forgot. I did have the presence of mind once to postpone the inevitable and blacklist the nouveau. I enjoyed the 80x25 for hours on end. Disappointingly, once I went to X and back, I was dropped in 240x67 forever. (on its way to graphics, nouveau loads itseld up.) Just to repeat(?). I'm NOT against 240x67 (or even 241x66). It's just that: 1. I like 80x25, especially for (B)LFS work and in decades of use. 2. I don't like the government to tell me what's good for me. I like freedom and choice. Change scares me, no matter how obviously good it is for me (and my family). So I elect 80x25, idiotic as it might be at this day and age. 3. I used the word trap. I understand for some people it can be a tender trap. People are different. So be it. Note: This is to avoid silly comments like what's wrong with 240x67? and NOT (I emphasize NOT) for us to get sidetracked from answering MY main question above. Flames and explanations are for another thread. Just stick to my original question, to the letter, here. Thanks again, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Problem installing the nouveau driver
On Jun 29, 07:40:18 AM, Simon wrote: What exactly is your problem with running in the high-res mode? If it's just that the font size is too small, I'd have to repeat Stephane's suggestion of selecting a different console font (somewhere in the kernel config, I think). I'm confused. So before we go to the _exact_ steps of how to set a font in kernel which would take effect after nouveau is up, I want to establish a common ground. With nouveau, my boot-up goes through these basic steps: 1. The original/regular console sequence (80x25) 2. Nouveau is loaded by UDEV 3. At this point, the console goes blank for a sec or so. The preceding messages are wiped out. 4. The remainder of the boot-up sequence proceeds and stays in 240x67 all the way to the prompt (and beyond). 5. I can never change the 240x67 resolution of the console text mode. QUESTION Does anybody have/see a different behavior? NOTE I can imagine people going directly to X (graphics mode). In that case, to stay with me on step 4 above, just come down in console text mode for a moment or so (Ctrl-Alt-Backspace or whatever) and check the ensuing text resolution. BTW, I'm interesting in the answer to my question above more than in comments to this note :) BTW, the _exact_ steps of how to set a font in kernel which would take effect after nouveau is up, will be highly appreciated. Thanks, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Problem installing the nouveau driver
Hi Aleksandar, Andy, Neil, Simon and all the other great participants in this thread: Jun 22, 11:54:28 AM, Alex wrote: At that point (nouveau Udev load? ), the screen goes blank for a split second then continues OK all the way to the console prompt. Note: The screen resolution switches from 80x25 (i.e. VGA Text, as they say), to something like 240x67 (1920x1080? ) - full widescreen - after the momentary blank. I'm not worried too much though (I prefer 80x25 in text mode). I think I can fix that somehow with local means. Maybe even the quick blank in the process. then on Jun 23, 09:42:48 AM, Alex added: I have until the autumnal equinox to try to fix the annoyance of nouveau's boot-up switching to HiDef on me. --- Boy, was I wrong! (or, as they say concisely, I misspoke). I wrote to Stephane Marchesin, the author of the nouveau driver, directly (his profile: icps.u-strasbg.fr/~marchesin/). Stephane is a very nice guy; he responded promptly to my two E-mails. In short, the exchange consisted of four E-mails: 1. Alex --- Stephane 2. Stephane --- Alex 3. Alex --- Stephane 4. Stephane --- Alex In the following, the gory details. I separated the four contents by a N. ==...== line. For accuracy, I left everything intact; only the salutations are gone. 1. == Jun 25, 01:02:46 PM, Alex wrote: I have a problem, maybe you can help me. My boot-up proceeds in the regular VESA (VGA) text, 80x25 to the point where nouveau is loaded by Udev. At that point the screen goes blank for a split second and then continues OK all the way to the console prompt. Unfortunately for me, the resolution switches to a HiDef 240x67, full wide-screen. I'd rather have stayed in 80x25; I don't know of a way to switch my text console back to it. DETAILS Screen display after the blank, all the way to the prompt: [drm] nouveau :01:00.0: 0xB30A: parsing output script 1 [drm] nouveau :01:00.0: 0x849D: parsing clock script 0 Console: switching to colour frame buffer device 240x67 fb0: nouveaufb frame buffer device registered panic notifier [drm] Initialized nouveau 0.0.16 20090420 for :01:00.0 on minor 0 SYSTEM i686-pc-linux-gnu, 2.6.34, udev-156, (B)LFS NVIDIA GeForce 8300GS, 128MB, GDDR2, PCIe-2.0x16 Samsung SyncMaster 2494 LCD, 60Hz, DVI-DVI connection. ASUS P5E-VM HDMI, intel Core2Duo e8...@3.0ghz. G.SKILL 4GB (2 x 2GB) DDR2 1000 (PC2 8000). 2. == Jun 25, 04:38:24 PM, Stephane wrote: On Jun 25, 10:02, Alex wrote: I have a problem, maybe you can help me. My boot-up proceeds in the regular VESA (VGA) text, 80x25 to the point where nouveau is loaded by Udev. At that point the screen goes blank for a split second and then continues OK all the way to the console prompt. Unfortunately for me, the resolution switches to a HiDef 240x67, full wide-screen. I'd rather have stayed in 80x25; I don't know of a way to switch my text console back to it. It's not possible with nouveau (or any other KMS driver for that matter). Settting the VGA text mode would stomp over the card state in a way that we don't handle. Depending on what your goal is, you may want to use a different resolution for your vgacon, or a different fbcon font. 3. == Jun 26, 01:45:41 PM, Alex wrote: On Jun 25, 04:38:24 PM, Stephane wrote: Depending on what your goal is, you may want to use a different resolution for your vgacon, or a different fbcon font. As I said in my original E-mail (On Fri, Jun 25, 2010 at 10:02): Unfortunately for me, the resolution switches to a HiDef 240x67, full wide-screen [on nouveau load]. I'd rather have stayed in 80x25; I don't know of a way to switch my text console back to it. So, to repeat, my goal is to go back to 80x25 full wide-screen once nouveau is active (loaded). Is it possible at all? Whether I have fbcon in the kernel or as a module (with its convenient font, 80x25 full wide-screen) I cannot (or I don't know how to) change the 240x67 resolution back to what I have always used and preferred, 80x25 full wide-screen. The original NVIDIA driver does not touch my text screen so this switch to 240x67 has caught me by surprise. I don't know what vgacon could do for me in this respect. I've always used it to read the whole boot-up screen text. Now the boot-up text is wiped out at the point nouveau loads and switches the console screen to a different resolution (i.e., from 80x25 to 240x67). 4. == Jun 26, 04:38:03 PM, Stephane wrote: On Jun 26, 10:45, Alex wrote: Jun 25, 04:38:24 PM, Stephane wrote: Depending on what your goal is, you may want to use a different resolution for your vgacon, or a different fbcon font. As I said in my original E-mail (On Fri, Jun 25, 2010 at
Re: Problem installing the nouveau driver
Hi
I played some more with the parameters you suggested be
changed in order to finally reach a config that would work with
nouveau and GeForce 8300GS on my system.
In the final analysis it seems that only two (2) are CRITICAL:
DD Graphics support Console display driver support
{*} Framebuffer Console support (was {M} originally)
NEEDS TO STAY SET ({*})
DD Graphics support
[*] Laptop Hybrid Grapics (sic) - GPU switching support (was [ ] originally)
NEEDS TO STAY SET ([*])
Many thanks Aleksandar.
I always felt that my midtower with its USB keyboard mouse
and the 24in display had a laptop flavor to it.
Like I said, we're in Staging. And 2.6.34.1 has by far the
relatively longest gestation time in recent memory.
All the other crazy parameters that have accumulated on my
machine over the years can be anything in this context.
As proof, I'm attaching the latest working config for perusal.
It was created by starting with the most recent, non-nouveau,
non-8300GS config and changing only the two params above
(and, of course, the setting of nouveau in Staging).
I'm at peace with myself now. I have until the autumnal equinox
to try to fix the annoyance of nouveau's boot-up switching to HiDef on me.
I'll probably be back with details then.
Thanks and Best wishes,
-- Alex
BTW, Simon, thanks for your thoughts on my existential question.
config.bz2
Description: Binary data
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Problem installing the nouveau driver
Jun 21, 2010 06:11:14 PM, Andrew Benton wrote.
Jun 21, 2010 08:54:20 PM, Aleksandar Kuktin wrote.
Jun 22, 2010 04:25:40 AM, Simon Geard wrote.
Hi guys,
The nouveau now works !! Boot-up, KDE, Fluxbox.
THANK YOU VERY MUCH!
Details:
The boot-up proceeds to the point it would go blank permanently before.
At that point (nouveau Udev load? ), the screen goes
blank for a split second then continues OK all the way to the console prompt.
Note: The screen resolution switches from 80x25
(i.e. VGA Text, as they say), to something like
240x67 (1920x1080? ) - full widescreen - after the momentary blank.
I'm not worried too much though (I prefer 80x25 in text mode).
I think I can fix that somehow with local means.
Maybe even the quick blank in the process.
Thoughts:
It'll take a while for me to sort this all out.
I want to see which parameter(s) was the clincher (for
the advancement of science).
I'm doubly glad it worked finally. Another set or two
of new parameters to disable, I'd've been left with
an empty 'config' file! :).
I'll come back in a day or two with my final conclusions.
In the meantime, IF _you_ guys are still thinking about this
episode at all, maybe you could reserve a minute or so
to the existential question:
How come the original NVIDIA driver, after all these ugly
and hostile parameter settings I threw at it, it was left still
standing at the end of the day?
--
For the record, a summary of the three posts.
Note: the new setting of the respective parameter is shown
in square brackets
Aleksandar Kuktin
I went over the settings, and I have a few suspicious things.
First off, do you load the framebuffer console module? The one in
drivers=Graphics support=Console display driver support, AKA
FRAMEBUFFER_CONSOLE ?? This is an absolutely necessary module.
[ {*} Framebuffer Console support (was M) ]
The other module I am interested in is VIDEO_OUTPUT_CONTROL ?
[ {*} Lowlevel video output switch controls (was M) ]
Third you might want to try with FB_TILEBLITTING, in
drivers=Graphics support=Support for frame buffer devices
[ [*] Enable Tile Blitting Support (was [ ]) ]
Also, you might want to explore VGA_SWITCHEROO (not too much logic in
that, I just have it compiled in, it's a shot).
[ [*] Laptop Hybrid Grapics - GPU switching support (was [ ]) ]
Turns out VESA really isn't the problem - I just discovered I had it
compiled right in all this time. :)
--
Andrew Benton
I can't see anything obviously wrong. I don't like the look of these
options:
CONFIG_AGP_INTEL=m
[ Intel 440LX/BX/GX, I8xx and E7x05 chipset support (was M) ]
CONFIG_AGP_SIS=m
[ SiS chipset support (was M) ]
CONFIG_DRM_I915=m
[ i915 driver (was M) ]
---
Simon Geard
I notice CONFIG_DRM_I915 is set, as a module. Shouldn't matter in theory
since you presumably don't have Intel graphics hardware as well as
NVidia, but probably worth disabling it anyway.
[ see Andrew above]
Also, you have CONFIG_FIRMWARE_EDID=y, which isn't set on my system.
Might be relevant, since while the docs say it should be safe to enable,
they note:
If you experience extremely long delays while booting before you get
something on your display, try setting this to N.
So, probably worth turning it off, see if that makes a difference. From
the docs, it sounds like it's an option you enable to work around
problem hardware, isn't needed by the majority, and might potentially be
causing problems.
[ [ ] Enable firmware EDID (was [*]) ]
---
Again, thanks a lot!
-- Alex
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Problem installing the nouveau driver
Jun 20, 2010 06:21:59 AM, Andrew Benton wrote Jun 20, 2010 08:51:09 AM, Aleksandar Kuktin wrote Can we see your 'config' file? Sure. I'll try to attach it. If you do not get it point me to some other way to pass it along. ... Unfortunately (could my nouveau driver be jinxed? :): Jun 20, 2010 05:36:11 PM, lfs-support-boun...@linuxfromscratch.org wrote: Your mail to 'lfs-support' with the subject Re: Problem installing the nouveau driver Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 54361 bytes with a limit of 50 KB Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Problem installing the nouveau driver
Jun 20, 2010 06:21:59 AM, Andrew Benton wrote Jun 20, 2010 08:51:09 AM, Aleksandar Kuktin wrote Can we see your 'config' file? Sure. I'll try to attach it. If you do not get it point me to some other way to pass it along. Back at the ranch ... Jun 20, 2010 05:36:11 PM, lfs-support-boun...@linuxfromscratch.org wrote: Message body is too big: 54361 bytes with a limit of 50 KB I bzip2'ed the file, so let's see if 11702 bytes can now sneak below the 50 KB limit :). BTW, 'config' is for a system of this nature: ASUS P5E-VM HDMI, intel Core2Duo E8400 @ 3.00GHz. G.SKILL 4GB (2 x 2GB) DDR2 1000 (PC2 8000). NVIDIA GeForce 8300GS 512MB 256-bit GDDR2 PCIe-2.0x16 BIOS 60.86.45.00.26, Samsung SyncMaster 2494 60Hz, DVI connection. Note: the RivaTuner program shows the card with only 128MB DDR2 and 64-bit G86. Thank you for your interest, -- Alex config.bz2 Description: Binary data -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Problem installing the nouveau driver
Jun 18, 2010 12:41:04 PM, Andrew Benton wrote
me his comments on the subject.
Hi Andy,
Thanks for your message. As I told Neil below,
I'm hard at work at going over some log datails, etc. now.
(I was hoping against hope Neil's interesting workaround
will bring me afloat, but no cigar).
I'll get back with details and comments on your very
interesting words as soon as I have something more substantial,
Thanks again.
Jun 17, 2010 11:13:09 PM, neal.p.mur...@alum.wpi.edu wrote:
(EXCERPTS)
[We tried to] resolve this problem on a 'similar' system
[experiencing] the console screen blanking and not returning.
It wasn't the driver {1}, wasn't parameters, wasn't anything
[we] could figure out.
He was new to the system and Linux, but had probably been around
computers for 40-50 years {2}.
He found the solution himself:
setterm -powersave off -blank 0
Figure out a way to have the system run it during boot.
It solved his inexplicable problem and may well solve yours.
Hi Neal,
Thank you very much for your comments and willingness to help.
Unfortunately, the _workaround_ has not worked on _my_ system.
I even tried the formula after the system was fully up at the
command prompt (the system does come up all the way; you can
work blindly - login, setterm, etc.)
A few humble comments keyed to your words above.
{1}. It _must_ be the driver in the final analysis.
- Once the driver (and only the driver) is no longer
enabled in the kernel set-up, things return to normal.
So, 'setterm', if anything, sounds like a workaround here.
Anyway, thanks and congratulations for your modesty and
generosity in trying to help your friend and me.
- As an aside, I've been working on analyzing some logs to
find out where and maybe why this nouveau, staging driver is
handling my system (video card, monitor, etc.) so clumsily.
My (B)LFS (and Windows) machine (including the wide-screen
monitor) is pretty standard and relatively modern.
{2}. I assume your expert friend was into Unix in his
computer-rich life. 'setterm' with its parameters looks like
a typical Unix-like (and -originated) command.
Many thanks,
-- Alex
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Problem installing the nouveau driver
Hello,i686-pc-linux-gnu, 2.6.34, udev-156, (B)LFSNVidia GeForce 8300GSI've been trying to install/run the nouveau "nouveau"kernel driver, to avoid installing the NVIDIA driverafter each kernel upgrade.PROBLEM:So far, if on the "nouveau" kernel, I lose the video (the screen goes blank) on boot-up to command mode.A few (hopefully) relevant DETAILS:1. In '.config' I haveDevice Drivers Staging drivers M Nouveau (nVidia) cardsNote: It can only be M, * is not possible.2. On the only cyberpage I found helpful,at en.gentoo-wiki.com/wiki/Nouveau,they talk aboutDevice Drivers Graphics support * Direct Rendering Manager (XFree86 4.1.0 and higher DRI support),while my system accepts this parameter only as M.3. If I load "nouveau" manually (from a kernel without it - i.e.that doesn't experience the blank screen! ), I get[]$ modprobe -v nouveauinsmod /lib/modules/2.6.34/kernel/drivers/i2c/algos/i2c-algo-bit.koinsmod /lib/modules/2.6.34/kernel/drivers/gpu/drm/drm.ko[drm] Initialized drm 1.1.0 20060810insmod /lib/modules/2.6.34/kernel/drivers/gpu/drm/drm_kms_helper.koinsmod /lib/modules/2.6.34/kernel/drivers/gpu/drm/ttm/ttm.koinsmod /lib/modules/2.6.34/kernel/drivers/gpu/drm/nouveau/nouveau.ko[]$ lsmodModule Size Used bynouveau 391883 0ttm 30761 1 nouveaudrm_kms_helper 17119 1 nouveaudrm 106969 3 nouveau,ttm,drm_kms_helperi2c_algo_bit 3514 1 nouveau4. I played with forcing "nouveau" load early in the gamein '/etc/sysconfig/modules', to no avail.---I know I'll have the work cut up for me, once I start thinking about Xorg,what with creating a "nouveau_drv.so", but for the time being all I wantis to eliminate the blank screen on boot-up to command mode soI can have a fighting chance.I'd appreciate any helpful comments.Thanks,-- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Text narrows on changing video module
Hi, System: Development (B)LFS i686-pc-linux-gnu, 2.6.33.1, GRUB: 0.97 Motherboard: ASUS P5E-VM HDMI Internal Graphics Display (IGD): Intel G35, HDMI output External Video Card (PEG): ASUS GeForce 9500GT, PCIe x16, HDMI output Monitor: Samsung SM2494, Wide (16:9), DVI input (through HDMI-DVI cable) General: I always boot in text mode (to console prompt) first. 1. So far, with the IGD no problems: the kernel boot-up text, console prompt work, vi editing, etc., the text is displayed in HD, i.e., for the whole length of the screen (as 80x24) 2. I installed the new PEG (9500). Problem: The text is displayed in narrow (SD), 4:3 fashion i.e., using only the 4 of the horizontal (instead of the full 16). I haven't found anything (BIOS - PEG/PCI, etc.) to change the situation. One would expect that by just moving the cable from the IGD output to the PEG output, things wouldn't change text(VGA?)-wise. Notes: 1. To avoid any confusion, the card (PEG) works fine once in graphics mode (Xorg-7.5, NVidia nvidia 195.36.15 latest driver; nv doesn't work). 2. I didn't make any effort in the original configuration (i.e., the IGD) in order to make the text go wide, when I changed from a 4:3 monitor to this one. The widening of the text just happened. Any helpful comments will be highly appreciated. Thanks, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: UDEV - Not Leaving Well Enough Alone
Hello Simon Linux Fan, The thread started as a complaint about UDEV eliminating the only workaround, last_rule, I could use to avoid the pollution of the /dev with a relatively large number of nonsensical floppy nodes (from my standpoint), which was followed by a pleading for help. It's taken an off-topic turn now about the wisdom of still using floppy drives, but what the heck, in a global economic downturn any such subject is a good way to cheer you up while sitting idle at home. Now, a few comments around Simon's words: Is this a machine predating USB? Not exactly. In Linux terms, the subject machines are one rather modern, the other leading edge. In technical terms, one was built on an ASUS P4S533-MX, the other on an ASUS P5E-VM HDMI In technology terms they are about 5 generations and 2 generations, respectively, behind current. Unfortunately, both boards come with an internal (CMOS :) controller which as it turns out is nothing but trouble. no idea where I could buy a new floppy disk these days Same place you can buy an USB floppy drive :) BTW, I reuse old floppies (disks and drives). Sony's are notoriously reliable. In general, old floppies never die nor do they fade away. I can't imagine any other reason not to use flash drives for that purpose these days - dirt cheap, fit in a pocket ... As to why I use floppies in the first place (against all odds), my main principle in life has been if you paid for it use it, if you don't use it don't pay. Thus, always hook an internal floppy drive off the relatively expensive board. Please note, in my previous post I explained why I still find a floppy convenient in practice (as opposed to principle), like moving a typical Linux small file around. Beats a dirt cheap 32G USB Flash any day. I know there's no more exhilarating feeling then seeing the amazed and appreciative looks on the faces of neighbors and friends when I'm whipping out from my pocket and then plugging my shiny new USB flash in the front panel jack. But all this production for 'fstab'? :-) As to why floppies still exist and what their future is, I look at it this way: There MUST be a _sizable_ number of people somewhere (probably where the glaciers are melting), who are important enough for the UDEV and LFS developers to carefully issue and maintain CMOS rules like 50 and 55 for now and apparently foreseeable future. Rules that actually break the main UDEV philosophy: keep it small and dynamic. Note: For a good, solid rant against internal floppies I recommend AnandTech, the premier source for technical information. They cannot believe that the latest Pacific Rim boards STILL come with a floppy controller. Life's like that. have a 3.5 drive in my machine ... not connected, [just] to stop dust getting in through I stop dust with a connected drive. For as long as the majority of good cases still come with a floppy drive bay, even for a Micro ATX form factor (my favorite), I might as well. --- Speaking of USB, I do have my own slide off topic. I've been wondering why people still prefer/use _internal_ opticals when USB, modern, versatile, sophisticated (like Blu-Ray) drives are so convenient, easy to share (especially with expensive burners), and easy to replace when, the next day after you got one, there's a new cheaper and better model hitting the market. Let alone mitigating the power woes of the machine. True, some are not dirt cheap yet. Thank you fro your comments, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: UDEV - Not Leaving Well Enough Alone
Alex:
In the past, I was able to avoid creation
of unnecessary fd nodes.
Mike McCarty:
In what sense unnecessary?
Do your floppy drives not support those modes?
There are tools which use the name of the device
to select their mode of operation, and
if you don't have a /dev node for that then they
don't operate properly or even refuse to operate.
...
I have encountered some which don't respond to what
setfdprm does.
Hello Mike,
Thank you very much for your comments.
SHORT ANSWER
Unnecessarily from _my_ standpoint (obviously limited).
GORY DETAILS (in the order of increasing blood content)
1. I do happen to have 'setfdprm', a carry over from
my original 2005-LFS system (on two machines - mirrored)
I've never used it nor do I foresee a need in the future.
No mode tools have ever failed on me, to my recollection.
Not that I ever used them consciously.
2. For reference
01/20/2005 util-linux-2.12qMy setfdprm version
09/23/2005 util-linux-2.12rLast of the series
The new ng series no longer contain 'setfdprm'
(by accident??):
09/10/2008 util-linux-ng-2.14.1My version
09/07/2009 util-linux-ng-2.16 Latest non-rc
3. Each of my two machines has a garden-variety floppy.
In Linux, I use them regularly with various size floppies,
360, 720 but, by far, 1440. The numerous floppy drives
I've encountered just accepted/read the floppies.
Never a need to change the mode.
The last thing is to start a flame here; I still see a
need for floppies on Linux due to the relatively small
sizes of files in need to be quickly sneakered among
machines.
I also understand the people who rave and rant against
using floppies at this day and age (God Bless'em).
I would also understand someone who still uses/needs
cmos/setfdprm/modes if I ever hear a real case in the
developed world (Got Bless her too, in advance).
4. As I said, I'll personally be just fine with only
'/dev/fd0' for the rest of my Linux life.
HOWEVER, modes or no modes, my actual
POINT has been that the situation when last_rule
existed, while ugly, was manageable for me.
Once that OPTION was arbitrarily eliminated
(Its use breaks too many things ...) everything
becomes a nightmare (in relative terms :) for me,
with the ATTRS{cmos} rule imposed by the UDEV
developers (and reinforced by LFS) as a default.
That's why I hoped someone might know another
semi-permanent workaround in the 147+ world.
5. My bad luck (I suppose, like many others who use
a floppy as a floppy - like me) is that the mostly
intractable by mere mortals, the '/sys' file system,
has a file '/sys/devices/platform/floppy.0/cmos'
with a mysterious content, one byte of value ASCII 4.
This makes my system(s) eligible for the famous
cmos rule, whether I like it or not, or whether
99% of the population couldn't tell a CMOS floppy
drive from a hole in the ground.
Thanks again,
-- Alex
PS. If someone (a System Administrator?) could help
and delete my FIRST post (the one without the
Hello NOTE disclaimer.), that'd mean a lot to me.
It's obviously been a disgrace and a confusion.
I was testing if my Verizon (as opposed to GMail)
had acceptable plain text I could use.
Unfortunately, the self-test went awry and the draft
escaped into the world wide web.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Error in NCURSES-5.7 Procedure?
On Fri, May 1, 2009 at 10:50 PM, Chris Staub ch...@beaker67.com wrote. Hi Chris, I think the main problem here is that youse guys have not read my original post in any depth. Let me be very clear: You DON'T have to. Nor to give any reason for not going over it at all or in any meaningful fashion. Everybody is busy and has at least global problems nowadays. If anyone looks at the archives for the last two months or so, I have posts where nobody bothered to reply at all. Not even in this fashion, where so far the reply/comments are completely off the subject (as wrong as I might actually be on _my_ subject). Life goes on, NO problem. Many thanks for your work, in general. Back to the subject :) [I'll quote from my original posts in ... ] My letter was a sincere attempt to help others if it turns out I was right: If true, this should go to the attention of LFS Developers. If specific to my type configuration, maybe in a Wiki, to whom it may concern. If wrong, please disregard. ... ... and I sincerely apologize. I can be wrong both - Technically (obviously) and/or - Procedurally Here, I see how we've talked as if from different planets: One might say I'm at _B_LSF level, with certain holes plugged in with the help of _L_FS procedures. Moving from my original, _2005_ LFS ncurses 5.4 to the latest, 5.7, is a case in point (i.e. keeping up with the Joneses). All these years, I've been under the impression that, once in BLFS, nothing can (or should) stop me from using the LFS procedures when missing in BLFS for needed upgrades, such as Udev, Kernel, M4, NCURSES (to name a few) or true holes. They work perfectly (chroot or no :) AFAIAC. Just that for the very good, complete and detailed NCURSES05.7 procedure I found a possible problem, at least for my 5.4 configuration (which I figure in good conscience stems from my original LFS build four years ago). I'm referring to the chain of symlinks, which, as I said, ugly, but workable. I gather that you either - do not assume that the fine procedures in Ch. 6 cannot be used in isolation (i.e., by a BLFS guy), and/or - you have procedures for those BLFS upgrades stashed away somewhere that I'm not aware of. If so, again, apologies and please direct me to, for example, the place I can find the real procedure for the upgrade to nurses-5.7. As a general statement, with this exception, the Ch. 6 procedures (Devl. Book) work just find in a non-chroot environment (otherwise I wouldn't be here to talk about it :) you will need to specify what it is that you are actually doing. For example, explain *how* exactly Ncurses symlinks cause problems with Vi or Less [or Bash], when neither of those should already be installed before Ncurses. I do hope, the above has become moot by now. Thank you for your interest, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Error in NCURSES-5.7 Procedure?
Hi,
If true, this should go to the attention of LFS Developers.
If specific to my type configuration, maybe in a Wiki,
to whom it may concern.
If wrong, please disregard.
Before installing the 5.7, on my ncurses-5.4 system
(circa Oct. 2005), I had this chain of five links:
/usr/lib/libncurses.so.5 - /usr/lib/libcurses.so -
/usr/lib/libncurses.so - /lib/libncurses.so.5 -
/lib/libncurses.so.5.4
Crazy, but I suppose it was left like that after the
ncurses-5.4 procedure (and it worked for me).
Unfortunately, some important applications rely on
'/usr/lib/libncurses.so.5' (ldd ...) such as
'vi' (7.2), 'less' (382) and BASH (3.2.15).
In the 5.7 procedure, at the 'for' loop:
for lib in curses ncurses form panel menu ; do \
rm -vf /usr/lib/lib${lib}.so ; \
echo INPUT(-l${lib}w) /usr/lib/lib${lib}.so ; \
... ,
the nice chain above is broken by the removal of
'/usr/lib/libcurses.so', thus leaving
'/usr/lib/libncurses.so.5' dangling hopelessly.
For anybody with my type of configuration the system
becomes unusable at this point, both as unable to
run 'vi' or 'less' (for example, to follow the procedure)
and because it crashes on 'bash's untimely death.
A solution I humbly offer is to run something like
ln -sfv /lib/libncurses.so.5 /usr/lib/libncurses.so.5
just before the 'for' loop
(in '/lib', libncurses.so.5 - libncurses.so.5.4
which is still serviceable.)
Fortunately, this temporary work-around will be fixed
properly and painlessly just before the end of the
procedure, on the non-wide copy:
cp -av lib/lib*.so.5* /usr/lib
While at it, I also suggest replacing the above copy with
mv -fv ..
which saves some grief for those who use
alias cp='cp -i'
and, more importantly, preserves the original (compile)
time of the 'libncurses.so.5' symlink.
Thank you for your consideration,
-- Alex
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Error in NCURSES-5.7 Procedure?
Hi Bruce, On Fri, May 1, 2009 at 3:53 PM, Bruce Dubbs bruce.du...@gmail.com wrote: are there any exceptions you may have to the prereqs that are specified in section iv. Host System Requirements? 1. None that I know of. The steps ran successfully (as far as they went). Nothing seems to have been missing or awry. Obviously, I'd be looking forward to an example of what something missing (or wrong) could have led to my _specific_ problem. There are quite a few things that you have not mentioned. The instructions for the entire book have been checked with an automated procedure ... 2. As I mentioned in my post, the problem (if any) is corrected automatically (automagically, as they say) at the very last step (the non-wide copy). So if the procedure is in a script (I assume this is what you call automated) I suppose the problem might not show up if the script runs uninterrupted. 2.1. What fraction of users use the automated procedure (as a guess)? 2.2. Where can one find the automated procedure? what is your host system? 3. Sorry, my fault. I thought the problem was independent of the particular host system. A few details (more can be provided, upon request): i686-pc-linux-gnu, (B)LFS. Kernel: 2.6.28.8, Udev: 141 One might say I'm at _B_LSF level, with certain holes plugged in with the help of _L_FS procedures. Moving from my original, _2005_ LFS ncurses 5.4 to the latest, 5.7, is a case in point (i.e. keeping up with the Joneses). Third, are you compiling ncurses from chapter 5 or chapter 6? 4. Chapter 6 (chapter 5 procedure, which I suppose is for installing ncurses for the first time, is very simple, not containing the more sophisticated steps of 6, as seen in my post.) In virtually every case, problems like yours are due to an accidental deviation from the book's earlier instructions or trying to do things in an unsupported manner. 5. No deviations (accidental or otherwise). I thought I provided enough details about how you hit the problem by running the steps _one at a time_ (not automatically). Of course, the 'for' loop (whose effects I'm suspicious of), is run all at once as a single step. Can be run as one line at a time but that would really be splitting hairs. Please note, other people with ncurses at 5.4 or later may have ended up with a different five-link chain than mine. As I pointed out, this krazy chain is at the root of a problem like this. This is why I mentioned Wiki as a source of help for the (few) unfortunate guys like me. If this is your first LFS system, follow the instructions exactly. After you learn more, then deviate as you see fit. 6. I followed the instructions (of Chapter 6) to the letter. I'm repeating myself, but based on the premise (configuration) I described, one can see the problem by just looking at the steps to be taken to the 'for' and including. I don't like to deviate. When I did was to fix the dangling link and thus the crashed sytem. Thank you for your comments. -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Error in NCURSES-5.7 Procedure?
On Fri, May 1, 2009 at 8:54 PM, Ken Moffat k...@linuxfromscratch.org wrote: I'm still having trouble understanding this : you're saying that you are in chroot building lfs-dev, and symlinks in your original install are breaking, causing problems in e.g. Vim. Note that at this point in a normal build we don't have vim, and whatever we do in chroot should not alter your host system. ... Hi Ken, Rarely have I seen two _totally_ disjointed conversations! I take just your first paragraph above as an example. Where did you see me using the words: - chroot - lfs-dev - Vim If you want me I'll write in German :) so we can get a modicum of understanding each other. The subject of my post cannot be farther from what you are talking about. Please read and try to understand what I was describing. Take my post as a whole, or by paragraph, ask questions where you don't understand or agree. I'm more than happy to respond and explain. Eine Tragoedie went directly into a Farce, I'm afraid. Thanks for your interest, anyway, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
ALSA-in-Kernel Version
Hello, How can one find out what ALSA-project release is used for the drivers in a specific Kernel version. As a practical example, currently ALSA-project: 1.0.19 BLFS-ALSA: 1.0.18 LFS-Kernel: 2.6.28.8 Which version ALSA drivers are actually used in, say, 2.6.28.8? Thanks, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Wrong FOP MD5?
On Mon Mar 16 00:43:54 MDT 2009 Simon Geard wrote Don't know about the BLFS checksums Normally, when they use the phrase Download MD5 sum: in the BLSF book, I assume it's the md5sum, and in 99% of the instances it is (with rare exceptions :-). that url has version 0.95, also with the md5sum 58593e6c86be17d7dc03c829630fd152. I missed 0.95 sources at that time. Could it be that they were playing with the files at that very moment so as to fix the checksum to come out as 58593e6c86be17d7dc03c829630fd152 :-) Anyway, in today's BLFS Dev. book the checksum has been changed to 58593e6c86be17d7dc03c829630fd152 Which is good. -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Wrong FOP MD5?
Hello, In the BLFS Development book the md5sum for 'fop-0.95-src.tar.gz' downloaded from ftp://anduin.linuxfromscratch.org/BLFS/svn/f/; is given as 184c578a6269a8287ed150e0fc12868d. It appears to me more like 58593e6c86be17d7dc03c829630fd152 Please note that the other source http://archive.apache.org/dist/xmlgraphics/fop/source/; has FOP only up to 0.94 (with obviously a different value). What gives? Thanks -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Boot - Cannot find map file
Hello, i686-pc-linux-gnu, (B)LFS 2.6.28.2 Absolutely by happenstance, I noticed these first lines in 'kern.log' file on any system boot: ... kernel: klogd 1.4.1, log source = /proc/kmsg started. ... kernel: Inspecting /boot/System.map ... kernel: Cannot find map file. ... kernel: No module symbols loaded - kernel modules not enabled. ... kernel: BIOS EBDA/lowmem at: 0009ec00/0009ec00 ... kernel: Linux version 2.6.28.2 (r...@alexlfs) (gcc version 4.1.2) #1 SMP PREEMPT Thu Jan 29 21:22:12 gst 2009 ... kernel: KERNEL supported cpus: ... In one form or another this unsettling message (lines 3,4) may have existed since the beginning of time (i.e. not only at 2.6.28.2) - who knows. I always peruse the console boot display pretty carefully and I don't remember ever seeing anything untoward in this respect. 'System.map' is always properly set in '/boot' as a symlink to the actual 'System.map-...' file (also in '/boot'; currently at 754232 bytes - mileage may vary, obviously). Correct permissions and ownership. System works A-OK. Has anybody seen such a thing before? Thanks, -- Alex - For reference, the corresponding snippet of the console display: Booting 'Linux LFS-2.6.28.2 (74G, SATA)' root (hd0,2) Filesystem type is ext2fs, partition type 0x83 kernel /boot/LFSkernel root=/dev/sda3 edd=off [Linux-bzImage, setup=0x2e00, size=0x181e70] Decompressing Linux... Parsing ELF... done. Booting the kernel. BIOS EBDA/lowmem at: 0009ec00/0009ec00 Linux version 2.6.28.2 (r...@alexlfs) (gcc version 4.1.2) #1 SMP PREEMPT Thu Jan 29 21:22:12 gst 2009 KERNEL supported cpus: ... -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Udev-137 Clarifications
Hello, i686-pc-linux-gnu, (B)LFS The installation of udev-137 went very smoothly and everything is humming along beautifully on my 2.6.28.2 SATA machine. Kudos and many thanks to the LFS developers. LFS had fallen somewhat behind Udev releases, so at some point, I decided to upgrade revision by revision on my own (Udev fascinates me). I was at 136 when I decided to try my hand at the brand-new LFS procedure in hopes of resynchronizing myself with the LFS people. As I said, everything worked just fine. To eliminate any doubts, I need a few answers which could help me get back in sync fully - if needed - with a correct LFS system: 1. I noticed two 64s and one 40 rule were installed in the default /lib/... directory. My understanding is that the default directory is generic, i.e. these rules can apply to any distribution (including LFS). Am I right? 2. OTOH, the 61-cdrom rule was shipped to the custom (i.e. LFS) directory, /etc/... Why is 61-cdrom LFS-specific? Just because of the group number? 3. I'd very much appreciate if somebody were to (re)publish a list (ls) of which rule-files should be in the default and custom directory respectively, for an up-to-date LFS system. Thanks, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: hdx to sdx change in 2.6.28
Hi Simon, On Sat, Jan 24, 2009 at 6:07 AM, Simon Geard wrote: On Wed, 2009-01-14 at 21:15 -0500, alupu wrote: - QUESTION Does anybody know anything about the transition to 2.6.28 changing the view of the system to a Universal, Uniform, Consistent, SATA centric, etc.? Disclaimer - I'm speaking only as someone who uses this stuff, not as any kind of kernel expert. I don't know about that, but your comments are _very_ informative. Many thanks. Shortly after SATA drives started coming out, the kernel developers started work on a new framework for hard-drive access, called libATA - it's not SATA centric as such, but it was created to make supporting SATA easier, and to remedy deficiencies in the old system. Because of that, almost all SATA drivers use this framework, but they've also been working on replacing old PATA drivers with new ones for the new framework. As with the usb-storage framework for dealing with flash drives and stuff, this new framework uses a lot of infrastructure that came originally from SCSI, hence the change in device names to sdX. As to why things have suddenly broken for you, I'm only guessing, but I'd say 2.6.28 must have removed the old driver you were using - maybe the Changelog has some mention of it? 1. First a correction with accompanying apology: Alex originally wrote: System works as expected (i.e., just fine) on 2.6.27 (actually up to 2.6.27.4; haven't tested .5 - .10; assume similar) As mentioned, I jumped directly to 2.6.28 from 2.6.27.4. Silly me. As fate would have it, in retrospect, things would have broken for me in the very next release, 2.6.27.5! Maybe this is why (B)LFS people (who are as of this writing at 2.6.27.8) ignored my thread hdx to sdx change in 2.6.28 for all this time as just one of them suspicious header messages. :) And, BTW, there's even a 2.6.27.12! Another BTW: From .5 to .12 the entry SiS PATA support is labeled (experimental). Starting with 2.6.28 (we're at 2.6.28.1), it's just that. 2. As for the ChangeLog, there's no mention of the change in 2.6.27.5. Luckily, 2.6.27.5 has only 59 commits. Imagine what I went through with 2.6.28 which contains 9784! Granted, it's possible there was some talk about the new framework in pre-2.6.27.5, since in 2.6.27.4 there were already several ... PATA support entries such as VIA PATA support. For the record, I searched on SiS, support, experimental, etc. 3. [they] must have removed the old driver you were using ... Unfortunately, I'm not at the subject PATA machine now, but I'm 99.9% sure that selecting the fateful SiS PATA support was an absolute must before all the machinations with GRUB and fstab fields in order to penetrate the Kernel panic wall. However. that leaves a nagging .1% grain of salt, meaning if I had futzed a little bit more with just GRUB and fstab, I'd've managed to fix things without needing SiS PATA support enabled. That is, to know conclusively whether the reason for the break was their pulling the old driver right from under me, or something else. 4. Sure, everybody would die to know exactly the details of libATA and all but what bothers me more is somehow spelled in the original question, why the quiet ... transition to 2.6.28 changing the 'view' True, my problems of having to change from hdx to sdx don't amount to a hill of beans in this crazy world but in our little universe of Linux where according to folklore the average user is still at 386SX and 256kB (P)ATA drives, this transition certainly appears considerably a bigger event than some commits - while perfectly honorable - like sata_nv: fix generic, nf2/3 detection regression. 4.1. As noted, some LFS folks should be at 2.6.27.8. A sub-question would then be, how come nobody got hit with this transition. Could they perchance be all pure-SATA? Or diskless? Have I missed another relevant support thread? Thanks again for your helpful comments. -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
hdx to sdx change in 2.6.28
Hello, - SYSTEM (relevant points) i686-pc-linux-gnu, (B)LFS. ASUS P4S533-MX, Intel Pentium 4. Two ATA (PATA native) drives, hdb (Linux) and hda (Windows) Two ATAPI (PATA native) opticals, hdc and hdd. SiS651 chipset connected with SiS652 for the integrated IDE Master/Slave controllers featuring Dual Independent IDE channels. Note: a PATA system par excellence. At the time I built it, SATA was still just a glimmer in a visionary's eye. Udev: 136 (latest - not necessarily relevant here.) - PROBLEM - basics System works as expected (i.e., just fine) on 2.6.27 (actually up to 2.6.27.4; haven't tested .5 - .10; assume similar) Compiled and switched to 2.6.28: on boot it hangs with the infamous message, VFS: Cannot open root device ... Kernel panic - not syncing: VFS: Unable to mount root fs or unknown-block(x,y) Switched back to 2.6.27: A-OK (no surprise here. Just for the record) Recompiled 2.6.28 with Sis PATA support (PATA_SIS) to Yes. Changed 'fstab' from hd... to sd... Changed GRUB root line from hdb4 to sdb4 Switched to 2.6.28: A-OK - QUESTION Does anybody know anything about the transition to 2.6.28 changing the view of the system to a Universal, Uniform, Consistent, SATA centric, etc.? Any words, details, etc. which can shed some light on this strange phenomenon will be much appreciated. Thanks, -- Alex - - PROBLEM - an additional little detail: The CONFIG setting PATA_SIS is new in 2.6.28 - PROBLEM - some gory details (for the interested reader) The Boot-up Log excerpts (unexpurgated ) of corresponding relevant sections: * 2.6.27.4 Uniform Multi-Platform E-IDE driver ide_generic: please use probe_mask=0x3f module parameter for probing all legacy ISA IDE ports hda: ST340016A, ATA DISK drive hdb: Maxtor 4G100J5, ATA DISK drive hdc: TOSHIBA DVD-ROM SD-M1612, ATAPI CD/DVD-ROM drive hdd: SONY CD-RW CRX175E, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: max request size: 128KiB hda: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63 hda: cache flushes not supported hda: hda1 hda2 hda3 hdb: max request size: 512KiB hdb: 200108160 sectors (102455 MB) w/2048KiB Cache, CHS=16383/255/63 hdb: cache flushes not supported hdb: hdb1 hdb2 hdb3 hdb5 hdb6 hdb4 Driver 'sd' needs updating - please use bus_type methods * 2.6.28 Uniform Multi-Platform E-IDE driver ide_generic: please use probe_mask=0x3f module parameter for probing all legacy ISA IDE ports ide-gd driver 1.18 Driver 'sd' needs updating - please use bus_type methods pata_sis :00:02.5: PCI INT A - GSI 16 (level, low) - IRQ 16 scsi0 : pata_sis scsi1 : pata_sis ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xb400 irq 14 ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xb408 irq 15 ata1.00: ATA-5: ST340016A, 3.05, max UDMA/100 ata1.00: 78165360 sectors, multi 16: LBA ata1.01: ATA-6: Maxtor 4G100J5, GAK819K0, max UDMA/133 ata1.01: 200108160 sectors, multi 16: LBA48 ata1.00: configured for UDMA/100 ata1.01: configured for UDMA/133 ata2.00: ATAPI: TOSHIBA DVD-ROM SD-M1612, 1S08, max UDMA/33 ata2.01: ATAPI: SONY CD-RW CRX175E, 1.1b, max MWDMA2 ata2.00: configured for UDMA/33 ata2.01: configured for PIO4 scsi 0:0:0:0: Direct-Access ATA ST340016A 3.05 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 78165360 512-byte hardware sectors: (40.0 GB/37.2 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 78165360 512-byte hardware sectors: (40.0 GB/37.2 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sd 0:0:0:0: [sda] Attached SCSI disk scsi 0:0:1:0: Direct-Access ATA Maxtor 4G100J5 GAK8 PQ: 0 ANSI: 5 sd 0:0:1:0: [sdb] 200108160 512-byte hardware sectors: (102 GB/95.4 GiB) sd 0:0:1:0: [sdb] Write Protect is off sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:1:0: [sdb] 200108160 512-byte hardware sectors: (102 GB/95.4 GiB) sd 0:0:1:0: [sdb] Write Protect is off sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sdb2 sdb3 sdb5 sdb6 sdb4 Switched to high resolution mode on CPU 1 sd 0:0:1:0: [sdb] Attached SCSI disk scsi 1:0:0:0: CD-ROM TOSHIBA DVD-ROM SD-M1612 1S08 PQ: 0 ANSI: 5 scsi 1:0:1:0: CD-ROM SONY CD-RW CRX175E 1.1b PQ: 0 ANSI: 5 NOTE: Even gorier details can be provided upon request. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: SATA PC Fails to Boot PATA Linux Drive
Update: I managed to SUCCESSFULLY boot up the IDE LFS Linux 2.6.25.4 drive on my new SATA machine. Many thanks to Phill Upson, cx8508 and Mr. Beekmans. Also thanks to the cast of thousands who rooted for me all along. There are of course a lot of things still left for me to work on (clean up, new sound,video etc.) but like I said, all I needed was a fighting chance (and not to hit the VFS wall each and every time). Case closed. I had made a ton of changes in preparation for this last attempt, so I don't know what exactly did the trick yet but, for interested parties, a very short and quick list of suspects and things of interest comes to mind: - SCSI disk support (BLK_DEV_SD) _in_ the kernel (cx8508 - again, thanks). Actually I moved all my modules (within reason) into the kernel with wild abandon; I'll sort out everything later when I get a chance. - Possibly the new kernel (2.6._25_._4_). Yes, at the point of VFS failure I got a listing of drive/partitions the kernel was seeing available for me at that point. I don't recall getting that on 2.6.24.4 nor on 2.6.9. 'sdb2' partition was beckoning from the new list temptingly (the drive had been set for 'hda2'! ) so I quickly fixed the 'fstab', 'rdev' and root=sdb2 (GRUB) which took me right past the VFS and on to the login: prompt. I sit another day or so on the lfs-support list for further comments (if any), then I'll fade off into the sunset. Not much more technical to say for the time being, I'm totally spent (but happy) right now and the light, sweet crude for July delivery hovering around US$133 a barrel is no help either. However, if anybody is interested in more details (at least half as interested as I am - I'm dying to know what exactly went on, first for the advancement of science then so I can next improve/streamline the process) I'll be more than ready and willing (don't know about able) to help. Best wishes, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: SATA PC Fails to Boot PATA Linux Drive
On 2008/05/19 Mon PM 09:27:30 EDT cx8508 wrote try to enable the SCSI disk support and Serial ATA (SATA) support option in the kernel configuration, and compile them directly into the kernel, not as modules. cx8508, Thank you very much. Please read on, if interested. UPDATE Since my last post I've been feverishly working on setting up a new master LFS IDE disk on the old machine based on Phill Upson's, cx8508's suggestions and whatever I could think of on my own. So, I apologize for the delay in updating the situation. I figured if I needed to make so many changes I might as well have them on the latest kernel, 2.6.25.4. Compiling took a while though as the configuration kept fighting me all the way until I tracked down the bug to a relatively obscure NEW parameter: SCSI device support SCSI low level drivers Marvell 88SE6440 SAS/SATA support. In my youthful impetuousness, knowing that Marvell is hot with the new SATA boards these days, I foolishly enabled (* - as opposed to M) this parameter (we agreed that for the tests we should have as many functions in the kernel proper as reasonably suspected to affect my IDE - SATA failure). The irony here is that my ICH9R might contain the Marvell 88SE6111 chipset(!) (and not JMicron as suspected) to which I didn't see any reference in this latest kernel. As an aside, this might be a real technical marvell to find any support for it in my floppy's 2.4.2 kernel (for reference, my board P5E-VM HDMI has been around since November last year)! Now I am at the point where I'm preparing a solid, brand new mirror test drive with all the desired flexibilities in order to attempt what should be my last major effort in solving the problem. This may take a while. All in all, if you don't hear from me with the results of a _successful_ operation within a few days it will be fair to assume I joined the Peace Corps and moved to an undisclosed location without television or Internet. On 2008/05/20 Tue PM 01:46:17 EDT Gerard Beekmans wrote [Commenting in general, and specifically to my words: Just a thought (while we're at it): how come a lousy 2.4.2 rescue floppy can get to my IDE drives (read/write) without my using any special HDD driver machinations?] Mr. Beekmans, First off, many thanks. Honored. Every kernel's default configuration enables a certain number of drivers to be built-in and a number to be modules. This set of enabled drivers is not always the same from kernel to kernel. It's therefore possible that your 2.4.2 kernel had different defaults than the one you are currently using. Meaning you need to reconfigure your current kernel to include the necessary IDE and SCSI drivers to match your hardware. And if they are already selected, make sure they are not modules. It happens I was aware of that. For details please see above. Here, I personally suspect a possible extra difficulty (actaully the crux of all my theories - moving an IDE disk from a natural IDE board to a board where the IDE port is controlled by some sort of a bridge, like JMicron or Marvell chipsets) While your kernel is booting up, pay close attention to its output. If your harddrive controller is recognized by a built-in driver, you'll see this on the output. When a physical disk is recognized, it will print out a line with the partitions it found (it'll print lines like hda1 hda2 hda3 or the sd variety). If you don't see anything matching your current harddrive configuration you can be fairly sure the kernel you compiled does not have the drivers necessary built-in. This is a tough one. The speed of the displays nowadays is such that maybe one of them high speed cameras might do the trick (like the one capturing the bullet hitting the Master lock in the commercial). I miss those 386SX-, 16M-, 256MB-Linux days! Just a reminder also - when you compiled a new kernel, don't forget to copy the actual kernel images to the /boot directory. Many people often reconfigure and recompile the kernel and then don't actually install it by copying the image. So you keep rebooting your *old* kernel expecting different results. I always _fully_ test a disk set up for this project by physically connecting it to the old (PATA) machine. At a minimum, 'uname -a' works wonders for me. Thanks again, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
SATA PC Fails to Boot PATA Linux Drive
Hello, I'm trying to move an IDE LFS drive from an older PATA computer to a new SATA computer. I've been unsuccessful so far. After literally hundreds of iterations/permutations of Master/Slave, various 'rdev' settings, BIOS settings, kernel ... root=/dev/... in GRUB, Linux versions (with/without 'udev'), ETC., all boot attempts typically fail with the infamous VFS three error lines: VFS: Cannot open root device hd.. or unknown-block (x,y) Please append a correct root= boot option Kernel panic - not syncing: VFS: Unable to mount root fs or unknown-block(x,y) In short, the boot sequence never gets to mount my file system and then to trigger 'init', at which point I would obviously have a fighting chance to bring the boot to a happy ending (I do expect some inconsistencies, names to be resolved, etc. on the new machine). The alternative, building from scratch a new Linux on a SATA drive is scary. COMMENTS and CLUES 1. I've tested with either of two IDE drives, one 2.6.9 (non-LFS, non-udev), the other 2.6.24.4 (with udev-120). Both work flawlessly on the old, PATA PC. Both have the expected boot points (/dev/hdax, etc.) manually included to eliminate possible 'udev' limitations and/or suspicions here. 2. GRUB (0.96) works A-OK (otherwise I wouldn't get to the VFS point in the uncompressed kernel, nor to my original, unaltered root=... kernel boot option, as shown on the VFS first error line). 3. The new SATA machine does boot either IDE drive OK. I can always confirm it with my first DOS partition which is chainloaded without any problem by GRUB (my first partition on any drive is always a little bootable DOS, for rainy days). 4. As far as I know, the IDE drive is seen by the new PC as hda (hdb if Slave). This I got when booted on a 2.4 Rescue Floppy. Funny, a Knoppix CD sees it as hde or hdf. Anyway, I tried all reasonable possibilities - including sdx's. Luckily, my new machine is a speed demon, so I'd hit the reset button and try a new combination. The SATA drive, when connected, is sda, of course. 5. So far, the only thing I haven't tried that I can think of is using initrd. I figure if boot (and GRUB) has been working fine on my old machine without this contraption, why adding this extra unknown/complication now. Obviously, if anybody can demonstrate its necessity under the new circumstances and configuration I'll hop on it. 6. GRUB (like I said, works admirably) uses a menu looking something like this title Linux LFS-2.6.24.4 root (hd0,3) kernel /boot/LFSkernel root=/dev/hda4 title DOS 6.21 rootnoverify (hd0,0) chainloader +1 NOTE: No other commands, but I do play with drive names/numbers during tests. REFERENCES 1. The old PATA board is an ASUS P4S533-MX. Two genuine IDE controllers/connectors. 2. The new SATA board is an ASUS P5E-VM HDMI. One ATA IDE port (off a JMicron JMB368 PATA controller) and six SATA ports (off intel's ICH9R). CLOSING WORDS Any helpful comments/suggestions/questions are invited and highly appreciated. It'd make me even happier if I could hear from someone who successfully pulled this stunt I've been miserably failing to. Thanks, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: SATA PC Fails to Boot PATA Linux Drive
On 2008/05/19 Mon PM 06:00:57 EDT, Phill Upson wrote: I think you are missing the driver for your hard disk controller in the kernel (or as a module to be loaded by initrd). Try booting from a livecd again and look at the output of lspci and lsmod, try to work out which module is your disk controller, then recompile your lfs kernel to include that driver, replace the kernel and reboot. After your extensive testing, I can't think of what else it could be! Regards Phill Upson [EMAIL PROTECTED] wrote: Hello, I'm trying to move an IDE LFS drive from an older PATA computer to a new SATA computer. I've been unsuccessful so far. After literally hundreds of iterations/permutations of Master/Slave, various 'rdev' settings, BIOS settings, kernel ... root=/dev/... in GRUB, Linux versions (with/without 'udev'), ETC., all boot attempts typically fail with the infamous VFS three error lines: VFS: Cannot open root device hd.. or unknown-block (x,y) Please append a correct root= boot option Kernel panic - not syncing: VFS: Unable to mount root fs or unknown-block(x,y) In short, the boot sequence never gets to mount my file system and then to trigger 'init', at which point I would obviously have a fighting chance to bring the boot to a happy ending (I do expect some inconsistencies, names to be resolved, etc. on the new machine). The alternative, building from scratch a new Linux on a SATA drive is scary. COMMENTS and CLUES 1. I've tested with either of two IDE drives, one 2.6.9 (non-LFS, non-udev), the other 2.6.24.4 (with udev-120). Both work flawlessly on the old, PATA PC. Both have the expected boot points (/dev/hdax, etc.) manually included to eliminate possible 'udev' limitations and/or suspicions here. 2. GRUB (0.96) works A-OK (otherwise I wouldn't get to the VFS point in the uncompressed kernel, nor to my original, unaltered root=... kernel boot option, as shown on the VFS first error line). 3. The new SATA machine does boot either IDE drive OK. I can always confirm it with my first DOS partition which is chainloaded without any problem by GRUB (my first partition on any drive is always a little bootable DOS, for rainy days). 4. As far as I know, the IDE drive is seen by the new PC as hda (hdb if Slave). This I got when booted on a 2.4 Rescue Floppy. Funny, a Knoppix CD sees it as hde or hdf. Anyway, I tried all reasonable possibilities - including sdx's. Luckily, my new machine is a speed demon, so I'd hit the reset button and try a new combination. The SATA drive, when connected, is sda, of course. 5. So far, the only thing I haven't tried that I can think of is using initrd. I figure if boot (and GRUB) has been working fine on my old machine without this contraption, why adding this extra unknown/complication now. Obviously, if anybody can demonstrate its necessity under the new circumstances and configuration I'll hop on it. 6. GRUB (like I said, works admirably) uses a menu looking something like this title Linux LFS-2.6.24.4 root (hd0,3) kernel /boot/LFSkernel root=/dev/hda4 title DOS 6.21 rootnoverify (hd0,0) chainloader +1 NOTE: No other commands, but I do play with drive names/numbers during tests. REFERENCES 1. The old PATA board is an ASUS P4S533-MX. Two genuine IDE controllers/connectors. 2. The new SATA board is an ASUS P5E-VM HDMI. One ATA IDE port (off a JMicron JMB368 PATA controller) and six SATA ports (off intel's ICH9R). CLOSING WORDS Any helpful comments/suggestions/questions are invited and highly appreciated. It'd make me even happier if I could hear from someone who successfully pulled this stunt I've been miserably failing to. Hi Phill, First, thank you very much for your comments and suggestions. I'll start on your intriguing recommendations right away. Just a thought (while we're at it): how come a lousy 2.4.2 rescue floppy can get to my IDE drives (read/write) without my using any special HDD driver machinations? Thanks again. Regards, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Udev and 26-Modprobe Mismatch?
Hello Everybody,
SYSTEM
~~
686-pc-linux-gnu (B)LFS, 2.6.21.3,
UDEV-113, 26-modprobe.rules v.20070304.
Machine hardware pretty standard and run-of-the-mill.
Nothing complicated or fancy (including peripherals).
I'm not aware of any problem, the system just works.
BTW, no USB standalone devices.
SUMMARY
~~~
I believe there might be a problem between our (LFS)
handling of aliases (in '26-modprobe.rules'),
the kernel set up, and Udev behavior.
DETAILS
~~~
This topic stems from a little conversation
Dan Nicholson and I had in a recent thread called
Udev Questions (end June - excerpts):
- Me (Alex):
In 'udev' I noticed that appending '--timeout=3'
to 'udevsettle' speeds up the boot considerably
while not missing any devices in doing that.
- Dan 2007/06/28 Thu AM 09:31:57 EDT:
I don't recall exactly how udevsettle works, but if
you specify a timeout, that's exactly the maximum
time udevsettle will run for. The default is 180.
Otherwise, udevsettle checks '/dev/.udev/uevent_seqnum'
and '/sys/kernel/uevent_seqnum' 20 times per second.
It runs until the value in /dev matches the value in /sys.
So, if it's much faster for you, then I don't think you've
waited until all the pending uevents have been processed.
If you're curious, you can set UDEV_LOG=info for udevsettle.
This would show if the timeout is reached or the queue is
empty in syslog. If you don't process all the events
immediately, then it's entirely unknown whether to proceed,
although probably OK at that point.
Dan got me to thinking, I decided to dig deeper and get
some answers to a few nagging questions. Among them:
Q1. How come I'm not missing any device despite the
artificially short timeout I set for 'udevsettle'?
Q2. Why every once in a while the system hangs for
a minute or so (looking like a deadlock among the
little threads Udev forks around to do some work)?
Q3. Why I always end up with the same 11-entry 'failed'
directory in '/dev/.udev'? Come to think of it, why
should I put up with any failures at all?
I know a lot more now (not enough, though); I don't
have all the answers nor the perfect solution, but
at any rate, what I discovered is quite confusing.
After CONCLUSIONS please find the supporting
documentation (in all the gory details).
CONCLUSIONS
~~~
C1: On boot, Udev populates '/dev' with all necessary devices
in less than a second (way shorter than a 3-sec timeout)
In other words, when 'udevsettle' starts, 'devtrigger'
has long finished its appointed duties.
C2: With the present logic, '26-modprobe.rules' forces Udevd
to fail certain suspect devices/drivers, thus creating
unnecessary noise, extra work and possibly deadlocks.
On my present system the suspect devices are always
the same 11 culprits, always ending up in the
'failed' subdirectory (EVENT_FAILED_DIR).
C3: I'm hesitant to ask, but why o' why does the kernel
create '/sys/.../modalias' files for kernel-built
(as opposed to module) drivers?
Am I totally out of line?
A typical example is our perennial favorite, floppy.
a) It is a kernel driver:
DD Block devices Normal floppy disk support = Y
b) No trace of floppy in
'/lib/modules/2.6.21.3/modules.alias'
c) but
[]$ cat /sys/devices/platform/floppy.0/modalias
floppy
From a '26-modprobe' standpoint, it seems that solely
relying on 'modalias' files gives you nothing but grief.
C4: Until something better comes along, I'm using a
temporary(?) solution consisting of 9 extra rules
inserted at the top of '26-modprobe.rules' (not 11;
I could combine a few, like serio:ty0*):
ACTION==add, ENV{MODALIAS}== \
pci:v1039d0001svsdbc06sc04i00, GOTO=modprobe_end
...
ACTION==add, ENV{MODALIAS}==floppy, GOTO=modprobe_end
...
DOCUMENTATION
~
D1:
[]$ ls /dev/.udev/failed
\x2fdevices\x2fide0\x2f0.0
\x2fdevices\x2fide0\x2f0.1
\x2fdevices\x2fpci:00\x2f:00:01.0
\x2fdevices\x2fpci:00\x2f:00:01.0\x2f:01:00.0
\x2fdevices\x2fpci:00\x2f:00:02.0
\x2fdevices\x2fpci:00\x2f:00:02.1
\x2fdevices\x2fpci:00\x2f:00:02.5
\x2fdevices\x2fplatform\x2ffloppy.0
\x2fdevices\x2fplatform\x2fi8042
\x2fdevices\x2fplatform\x2fi8042\x2fserio0
\x2fdevices\x2fplatform\x2fi8042\x2fserio1
D2:
Output of a little applet which prints the kernel name
and alias of any driver that '26-modprobe.rules' sees
with its first rule, ACTION==add, ENV{MODALIAS}==?*,\
RUN+=/sbin/modprobe $env{MODALIAS}
Name'/sys/.../modalias' file content
0.0 = ide:m-disk
0.1 = ide:m-disk
:00:01.0 = pci:v1039d0001svsdbc06sc04i00
:01:00.0 = pci:v10DEd0326svsdbc03sc00i00
:00:02.0 = pci:v1039d0962svsdbc06sc01i00
:00:02.1 = pci:v1039d0016svsdbc0Csc05i00
:00:02.5
Re: glibc-2.5 Test Problems
Hi Dan,
I apologize for my tardiness in thanking you for your interest in this.
In desperation, I had sent a cold e-mail to Roland McGrath (content at the end,
section 5).
He seemed to be one of the people most involved in glibc so I said what the
heck.
I left a period of time to account for possible delays; no reply (yet) so this
thread can be considered de facto dead and closed.
However, I'm taking the liberty to add a few extra words in hopes that some
other poor soul might find some useful references if in a similar situation.
1. In my research I found some similar thoughts in a thread at this address:
overlays.gentoo.org/dev/kevquinn/changeset/176.
If it is hard to reach, here's a few relevant snippets:
Things to work out: Why all those mutex/robust (barrier) checks fail on x86
with a hardened kernel (only!)
Didn't expect signal from child: got `Aborted'
This happens when the parent tries to lock the mutex; at this point the child
has finished - well, it has aborted, which it shouldn't have done.
This is consistent with the child process aborting, instead of going to an idle
state waiting to be cleaned up when the parent finishes.
Investigation ongoing...
As an aside, I don't know what x86 means nowadays. Does it include AMD
processors, for example? (BTW, mine is intel P4 3.06 MHz with Hyper Threading
and 1GB memory)
2. The unsettling aspect of current glibc tests is that if you somehow believe
you're clean and the failure might be a bug, its submission will be quietly
and unceremoniously dumped into the big round hole #333 (half of 666?) never to
be seen again.
If you then try to talk to someone, my first paragraph above shows what will
happen.
3. Even more annoying for my particular failure, the offending file,
'tst-cpuclock2.c', is dated 2005-04-27. Come to think of it, a lot of kernels
and architectures have come and gone since.
I'm wondering whether those pesky pthreads might be wiggling differently now
than they were expected to in 2005!
4. I'll bite the bullet and install v2.5 despite these two failures. If my
machine goes up in smoke one day at least I'll have only myself to blame for
deliberately enabled a killer pthread to lurk around ready to pounce on the
first favorable opportunity.
5. Here is the relevant text from my e-mail to Roland:
I've been trying to upgrade to glibc-2.5.
On tests ('make check') I get failures.
PROBLEM
'libc-2.5/nptl/tst-cancel1.c'
fails with glibc-2.5/test-skeleton's message,
Didn't expect signal from child: got `Aborted'.
Obviously, I can insert a line in tst-cancel1.c,
#define EXPECTED_SIGNAL SIGABORT
and everything will appear to be fine.
In my amateurish sleuthing all I could find is
that the child thread, started by the parent on
pthread_create, aborts at his last step,
pthread_mutex_lock (m1)
when something happens during parent's
pthread_join attempt.
QUESTIONS about this problem:
1. Should I ignore it?
2. Is it developers' or
3. Is it mine?
Any help will be highly appreciated.
Thanks again,
-- Alex
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Udev CUPS Problem
Hi Ken,
First, thanks again for your interest and words.
I'm quickly cutting to the chase now:
The printing is fixed!
All I did was to simply delete it ('lpadmin -x printer') and then run the
_exact_ command I once used to install it (I keep records :-). Absolutely no
any other action whatsoever, nor had I touched anything else (including
anything related to Udev, directly or indirectly)! Ich gebe mein Ehrenwort.
So, in a way, case closed. I guess you will rightfully observe that eine
Tragödie ended up as eine Farce here.
Before I say a few more words (to tie a few loose ends; NOT to have the last
word!), not as an excuse, but I had missed this simple test by apparently being
way too hung up on my original concern:
7. [I noticed] A strange difference between the original (056) and the new
(104) system:
in '/dev' there's no longer a '.udevdb' directory. Instead, there's a new
'.udev' with a 'db' subdirectory containing some wacky symlinks pointing to
non-existent targets (but close).
I'll be closing my subscription at the end of this, but I'll stop by from time
to time. Maybe somebody will come up with an explanation/warning/solution once
the new Udev authors take the time off from their IBM duties and decide to jot
down a simple documentation succinctly and logically covering at least the
major changes from the with-hotplug-and-udevstart to the
no-hotplug-and-udevstart latest udev incarnation.
I repeat: have a look at the queue
My eyes are still bleary. That was one of the crazy things. The queue looked
good, the printer expecting, so to speak.
I don't have anything explaining the options, which makes me think you got
your cupsd.conf from an older version.
That's another example of the sad state the documentation has reached. Yes,
I've used the old conf file and that's where a simple explanation should
reside. I'm pretty sure it is buried somewhere in the new package now but who
has the time and inclination to search every nook and cranny nowadays? FWIW,
1.2.7 is still responsive to those levels (judging by the content of the
'error.log' file (my chosen name).
1.2.7 was announced at cups.org on November 16th, so I think it's still
pretty recent.
You're right. According to my records I installed it on Dec. 29. I did bounce
it around pretty extensively and it felt solid. Anyway, I weaseled the issue a
little bit out by using uncounted months (instead of the fuzzy a coupla
months) which can be interpreted as not counted (true), but I admit actually
knowing it in my heart that someday, somehow, somebody will call my bluff :-)
I still don't think udev is the problem, but your mind seems to be
made up about that, so we'll just have to agree to differ.
I just don't agree with that at all :-). If you analyze closely we've actually
agreed on practically everything.
If my claim that my systems (the original and the test copy) are identical were
true - I grant it, pretty shaky argument because there's no way to even prove
it to myself rigorously - then there is some point in my suspicion that Udev
somehow had a hand in hanging up my print function.
At the very least somebody reading this thread might get a helpful heads-up
about looking around for a potential culprit. (I already see somebody else
having the feeling that udev installation might interfere with printing at
first)
OTOH, if nobody complains, we'll write the whole thing off to my carelessness
and inexperience after a while (months? :-).
Ken and the other contributors, many thanks to all of you, and for the moment
all I can say, we'll meet again (don't know when, though - maybe udev-204).
Best wishes.
Mit hochachtungsvoll,
-- Alex
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Udev CUPS Problem
Hi everybody,
LFS/BLFS system.
i686-pc-linux-gnu 2.6.19.2
CUPS 1.2.7. Parallel printer (garden variety).
Udev 056 (LFS circa Sept. 2005)
Works perfectly.
BTW, by perfect here I mean the basic functions work clean and fully:
- Graphics (Xfree86-4.6)
- Networking
- Sound
- Printing
(other functions are nice to have but not relevant here).
Created a replica of the above system on a different drive.
Obviously, worked identically, but then
I installed the latest (104) Udev
(same functionality as 103 except for some bug fixes) from sources. No other
changes/additions/removals.
To my amazement, I've somehow managed to put together a clean new Udev system
in spite of the atrocious documentation (especially the lack of coverage of the
concept change - elimination of the 'hotplug', etc.) and support.
That is, everything works fine and identically as hoped EXCEPT Printing which
has been lost completely.
A few details of the PROBLEM:
1. No printing whatsoever (No 'lp/lpr file', etc.).
2. 'cat file /dev/lp0' works OK!.
3. On any attempt to print (other than 'cat' above) the external symptom
looks like the file never physically reaches the printer.
4. The internals ('error.log', 'access.log', etc.) do not show any kind of
errors, even with 'cups.conf' on debug2 (it's as if the file never leaves the
queue - 'lpstat' shows the file sitting there forever; however, the printer
_is_ accepting).
5. In /dev, crw-rw 1 lp lp 6, 0 lp0 (identical with the original system).
6. Variations thereof: more permissions, change owner, group) - no cigar.
7. A strange difference between the original (056) and the new (104) system:
in '/dev' there's no longer a '.udevdb' directory. Instead, there's a new
'.udev' with a 'db' subdirectory containing some wacky symlinks pointing to
non-existent targets (but close).
There's a good chance the clue is here but I can't fathom it.
8. Same behavior whether I switch to 2.6.19.1 and/or build 'lp' as a module or
in the kernel.
Any ideas?
Thanks in advance,
-- Alex
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Udev CUPS Problem
Dan, Ken, Randy: Thank you very much for your interest in the subject. Unfortunately your comments while very interesting and meaningful haven't helped in moved me any closer to solving the problem. Except Dan's try running strace around the lp call. I will. Going over your comments I realized that my original description was more confusing than useful in many respects (blame space constraints and my rambling style). I'll remake a few points, to answer your concerns in a hopefully more explicit way. 1. The kind of system I performed the udev upgrade (056 - 104) An identical, perfect physical replica in _both_ the content and functionality of my good original system. Long and solidly put through its paces thereafter. If that's still confusing, think of it as my having installed udev-104 on my original system (while actually - and fortunately - I still have a perfect back-up to go to when I reach a brick wall in trying to troubleshoot this ude104/CUPS-1.2.7 mess). In particular that means that at the upgrade start, CUPS-1.2.7 and udev-056 _must_ have been set-up and configured properly in all respects as having provided me uncounted months of sheer bliss (Cups-1.2.7 is recent but not that recent; BTW, I don't remember running into any problem worth mentioning in upgrading from 1.1.23). Yes, CUPS (1.2.7) might be tricky and dodgy, but as I said, had worked without problems, and played no part whatsoever in my Udev upgrade. No CUPS files, directories, permissions, etc. were touched in any way, directly or indirectly. Even on the new system, it comes up (during boot) just fine and in the proper sequence (toward the end of the boot scripts, i.e., long after the udev-coldplugging had settled down). While at it, here's a snippet of 'cupsd.conf' file as pertains to one of your comments: # LogLevel: controls the number of messages logged to the ErrorLog # file and can be one of the following: # # debug2Log everything. # debug Log almost everything. # info Log all requests and state changes. # warn Log errors and warnings. # error Log only errors. # none Log nothing. # LogLevel info As I mentioned, in hopes of tracking down the problem, I revved up 'cupsd' at times from the default info all the way to debug2 at the risk of blowing up the machine :-). Unfortunately, not a hint of error or any difference in logging output from when it worked in udev-056, before the installation work on udev-104. 2. If CUPS doesn't work with the good old 'lp/lpr' at the command line, I fail to see how it would work (or can better be tested) from fancier dialogues like File|Print. For the record, I did try to print from graphics like OO-2.03 or AdobeReader-7.08, just for the heck of it. 3. 'cat file /dev/lp0' works OK!. That should be enough to tell you that udev is not part of the problem. Also, same behavior whether you switch to 2.6.19.1 and/or build 'lp' as a module or in the kernel. Again, it indicates that udev (and modprobe) are not implicated in the problem ;-) I suppose that asking about udev itself on lfs-support is fair enough, but printing problems really belong on blfs-support even if they are caused by udev (or, more realistically, the rules). I did use LFS's latest rules (udev-config-20061021) on the 104 system (as I was supposed to). As an aside, the explanatory text files of that package are the only bright spot in the new udev documentation and support. Thanks. _Everything other than printing works_ on the 104 system (identically to the original system) so the rules as applicable to my system _must_ be working (see, for example, the resulting crw-rw 1 lp lp 6, 0 lp0 - and variations tried). No matter how you cut it, the new Udev must be at the core of the problem. Think of it this way. I have a perfectly functional system with applications A to Z running on it just fine. I install/upgrade application U without conscientiously touching anything else (i.e. I did it by the U book), and all of a sudden the good application C no longer works while all the other still run fine. No common files/permissions that I know (or should know) of. Thanks again, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Boot failure of LFS-6.1
Andrew, Ken, Alex: there's a confusion on page 103: 'console' and 'null' are mounted twice and 'console' with different modes (622 seems to be the correct choice). Apologies for using ?mount? instead of ?mknod?. I guess it can happen to a fella when the embarrassment of having compiled his main ext2 file system as module exceeds a certain threshold. Many thanks for the clarifications on creating console and null nodes twice. In the _smaller_ scheme of things, still confused about the inconsistency of using first mode 600 and three commands later, mode 622. I suppose it was done on purpose to divert the reader's mind off the more troublesome things in life nowadays :-) Ken: das eine Mal als Trag#65533;die, das andere Mal als Farce or as Stanley Kramer once put it, It's a mad mad mad mad world out there. As a general note, To Mr. Beekmans and all of the hard workers, Thanks youse guys and congratulations for a great concept with a superb execution, an excellent book (guide) and great support. Best wishes, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Boot failure of LFS-6.1
PROBLEM: New, complete LFS-6.1 system doesn't boot (details below). - Book: LFS v6.1 All packages installed. No deviations. No errors. - Host: LiveCD (lfslivcd-x86-6.1-2.iso) - i686-pc-linux-gnu - ASUS P4S533, P4-3.066GHz, BIOS Award v6.0 v1006, HT enabled DETAILS: lfskernel-2.6.11.12 built using LiveCD '.config' (no menuconfig changes) LFS-6.1 installed on '/dev/hda5': Device BootStart EndBlocks Id System /dev/hda1 1 4092 2062336+ 5 Extended /dev/hda5 1 3964 1997793 83 Linux /dev/hda6 3965 4092 64480+ 82 Linux swap Booting on the grub-0.96 diskette (page 234): grub find /boot/lfskernel-2.6.11.12 (hd0,4) grub root (hd0,4) Filesystem type is ext2fs, partition type 0x83 grub kernel /boot/lfskernel-2.6.11.12 root=/dev/hda5 [Linux-bzImage, setup=0x1600, size=0x26f8e9] grub boot ... Uncompressing kernel ... ... [kernel coming up] ACPI (supports S0 S1 S3 S4 S5) [Last good line] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(3,5) -- NOTES 1. - In chroot: root:/# rdev /boot/lfskernel-2.6.11.12 Root device 0x0305 root:/# rdev /boot/lfskernel-2.6.11.12 /dev/hda5 /dev/hda5: No such file or directory - In LiveCD Host: # rdev $LFS/boot/lfskernel-2.6.11.12 Root device /dev/hda5 2. On my other drive I have a regular, full, Linux (kernel 2.6.10, grub 0.94): Filesystem 1K-blocks Used Available Use% Mounted on /dev/hdb5 7495052 5891124 1223192 83% / /dev/hdb22 4964 17165 23% /boot tmpfs 518396 0518396 0% /dev/shm Device BootStart EndBlocks Id System /dev/hdb1 1171365216 FAT16 /dev/hdb21820 24097+ 83 Linux /dev/hdb321 976 76790705 Extended /dev/hdb4 * 977 1932 7679070 83 Linux /dev/hdb521 968 7614778+ 83 Linux /dev/hdb6 969 976 64228+ 82 Linux swap NEVER any problems booting up Linux-2.6.10 or DOS-6.21 (/dev/hdb1). On /dev/hdb4 another by-the-book LFS-6.1, setup accordingly in '/boot/grub/menu.lst'. Attempts to boot from the hard drive GRUB-94 and/or diskette GRUB-96/94: SAME type FAILURE: VFS: Cannot open root device hdb4 or unknown-block(3,68) ... Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(3,68) 3. A previous attempt to set up hard-disk GRUB-96 (on /dev/hda), page 234: setup (hd0) ... Error 22: No such partition 4. To avoid any confusion, all the main, conclusive tests above were run using only one drive connected at a time. Thanks, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
