The install manual recommends looking at /proc/pci or using lspci as a guide to what modules need to be configured into the kernel. /proc/pci does not exist, and lspci is not available until it is emerged using emerge pciutils <As a side note, lspci produces the warning: pcilib: cannot open /sys/bus/pci/devices where would I file a bug on that?> Reproducible: Always Steps to Reproduce: 1. Follow the installation guide in installing a system 2. try to cat /proc/pci when you get to the kernel config part of the manual (after chrooting) try using ls /proc/pci 3. try to use lspci 4. try emerge pciutils 5. then try lspci again Actual Results: /proc/pci does not exist lspci cannot be used until after emerging pciutils
if you do not have /proc/pci or /sys then i dont see how `lspci` can really be useful
/proc/pci is an obsolete system. (In the kernel makeconfig menu it is refered to as 'legacy'.) lspci now uses the more modern way of doing things, which looks like on the default gentoo system (2005.0) is: /proc/bus/pci/devices Which cannot be simply be cat'ed because the result is not formatted for human consumption. lspci does this.
that is ture but on a 2.6 kernel, /proc/bus is deprecated in favor of looking is /sys that is why lspci complained when it couldnt scan /sys
That seems to be the case. Since Gentoo (2005.0) defaults to the 2.6 kernel, the install documentation recommending using /proc/pci to discover what is on the pci bus is an error in the documentation. And the modern lspci does not work until emerged, which is not mentioned in the documentation. Therefore I filed this bug. And since Gentoo is using /proc/bus/pci/devices instead of /sys... etc, I wanted to know where to file a request that we use /sys instead of /proc/bus so that lspci doesn't generate a warning message and my Gentoo can be clean and shiny. Sorry I was not clear enough in the original posting. I recommend that the /proc/pci reference be deleted (or marked as for 2.4 kernels, if that is more appropriate), and that instead of recommending using lspci "if available", the documentation be changed to note that pciutils must be emerged to use lspci, and that lspci is, in fact, the default way to look at what is on the pci bus.
One more note: On the issue of /sys... it would probably be a good idea to have users mount sysfs at the same time as proc. mount -t proc proc /mnt/gentoo/proc mount -t sysfs sysfs /mnt/gentoo/proc That will avoid the wierd warning from lspci.
IMHO it's obvious that if `lspci` is not available, it has to be installed first...
Running diagnostic tools from chrooted environment is not a good idea. If the user lacks detailed knowledge of the target system, (s)he can always run tools like lspci (lsusb, inspect file /proc/pci, dig thru /sys/bus/...) from *installation* environment like InstallCD.
It is only obvious that pciutils must be emerged to use lspci if you happen to know that lspci is in the pciutils package. It may indeed be the case that it would be better to run utils like lspci from the install environment rather than the chrooted environment, but it is a much larger change to the docs than what I am proposing. You should probably expand on *why* it is a bad idea. The only reason I can think of is to avoid having to emerge pciutils. My suggestions are meant merely to update the current docs to remove inaccuracies caused by changes to the way things are done in the 2.6 kernel world. Possibly restructuring the docs to suggest running lspci in the install environment rather than the chroot environment is a separate issue, and a separate bug/enhancement should probably be filed for it as it is a bigger change.
Alan, I'm sorry, but I can't see your point. > Since Gentoo (2005.0) defaults to the 2.6 kernel, the > install documentation recommending using /proc/pci to > discover what is on the pci bus is an error in the > documentation. Nope, as long as this interface exists, I don't see any reason to suggest looking into directory structure under /sys, which is, IMHO, very confusing, at least for newbies (more advanced users don't need advice on how to get their HW info). > And since Gentoo is using /proc/bus/pci/devices instead > of /sys... etc, I wanted to know where to file a request > that we use /sys instead of /proc/bus so that lspci > doesn't generate a warning message and my Gentoo can be > clean and shiny. What does "we use" mean? `lspci`? Install docs? > I recommend that the /proc/pci reference be deleted > (or marked as for 2.4 kernels, if that is more appropriate), Reason? > and that instead of recommending using lspci "if available", > the documentation be changed to note that pciutils must be > emerged to use lspci, and that lspci is, in fact, the default > way to look at what is on the pci bus. My opinion is still the same as in comment 6. > On the issue of /sys... it would probably be a good idea > to have users mount sysfs at the same time as proc. Is this needed for anything else except *some* flavors of lspci? Adding another if-statement about 2.6 installation media would confuse users, IMHO.
> It may indeed be the case that it would be better to run utils > like lspci from the install environment rather than the chrooted > environment, but it is a much larger change to the docs than what > I am proposing. You should probably expand on *why* it is a bad > idea. The only reason I can think of is to avoid having to emerge > pciutils. For the same reasons as why was GRUB having problems with installation from chrooted environment. Another point is that the installation medium is usually equiped with some diagnostic tools, so you don't have to install them.
Jan, you are misundertanding me and needlessly confusing the whole issue. I am *not* suggesting the user look into /sys. lspci, not the user, looks into /sys. The /proc/pci interface is depricated and *DOES NOT EXIST* by default in 2.6 kernels, which is the reason I recommended deleting the reference to it or marking that it is for 2.4 only. lspci is the prefered way of finding out what is connected to the pci bus for 2.6 kernels. Since the docs now recommend using lspci 'if available', I recommended telling the user how to make it available, which is more useful for a newbie who doesn't know that lspci is in pciutils. Since lspci wants to access /sys, and will print a warning message that will needlessly confuse the user if /sys is not available, I recommend having the user mount the sysfs before they go into the chrooted environment. IMHO it is a good idea anyway (for the same reasons mounting proc is a good idea before chrooting), but the original motivation for suggesting it was to avoid the lspci warning message so that newbies don't have to stress about a warning message that is not real problem. As you mentioned, it is also reasonable to suggest that lspci be used BEFORE chrooting, which avoids having to emerge it, and avoids the silly warning message since the /sys interface is already available in the install environment. However, the docs, as they are currently written, recommend using /proc/pci and lspci AFTER the user has chrooted. I'm not sure what is going on with the GRUB installation docs, but I agree that if the current procedure of installing GRUB in the chrooted environment doesn't work, those docs should be updated. However, lspci *DOES* work in the chrooted environment, and if sysfs has been mounted it will not produce a warning message. So there is no trouble using lspci in the chrooted envirnment, as long as pciutils has been emerged and sysfs was mounted before chrooting. The bottom line is that a change should be made dealing SOMEHOW with the fact that /proc/pci has been deprecated and lspci is the prefered way of getting pci connection information from a 2.6 kernel. I don't really care if that change also includes recommending that lspci be used from the install environment. It is certainly simpler for the user that way. It is just a matter of where and how to put it in the docs. Right now the docs recommend using /proc/pci or lspci from the chrooted environment, and that DOES NOT WORK with the 2005.0 install cd without (the previously discussed) additional steps that newbies are going to have trouble with. I hope that clears things up for you Jan, and I appologize that this discussion was confusing to you.
Alan, now it seems that I see your point, thanks :-). Anyway, if I'm correct, the easiest way to fix the problem is to suggest users to use `lspci` from original environment, not from inside chroot, and to remove notice about /proc/pci. Would any issues last *if* we change that section of hb-install-x86-kernel to something like "Most information can be gathered by using lspci (preferably from installation environment; Gentoo sys-apps/pciutils package)."?
I like your wording for the most part. The only problem is that by the time the user gets to this section they are already in the chrooted environment. It might make more sense to add a varient of your suggestion to 6.a Chrooting. The change should, of course, be made to the handbooks for both networked and networkless installs (but you know better how to do that than I do :-). I would suggest the following insert before "Mounting the proc Filesystem" in 6.a: Obtaining PCI Device Information Before configuring the kernel, it may be useful to know what hardware is connected to the system. The command lspci can be used to get information about devices connected to the PCI bus. Save this information to use when configuring the kernel! Code listing 1: Using lspci # lspci I also recommend changing the "Mounting the proc Filesystem" to Mounting the proc and sysfs Filesystems Mount the proc and sysfs filesystems to allow the installation to use the kernel-provided information even within the chrooted environment. Code listing 3: Mounting the proc and sysfs Filesystems # mount -t proc proc /mnt/gentoo/proc # mount -t sysfs sysfs /mnt/gentoo/sys Finally, in 7.c Default: Manual Configuration, the sentences: However, one thing is true: you must know your system when you start configuring a kernel manually. Most information can be gathered by viewing the contents of /proc/pci (or by using lspci if available). could be changed to: However, one thing is true: you must know your system when you start configuring a kernel manually. Now is the time to use the information you got from lspci before you chrooted. If you didn't get the information before chrooting, you can use lspci within the chroot environment after emerging pciutils. Code listing x: Emerging pciutils # emerge pciutils Thanks for your help and patience, Jan!
Alan, The non-chrooted environment is available on the other terminals. Surely someone isn't going to chroot on all 6 terminals are they?
And that means they can terminal switch and use lspci off the non-chrooted environment and configure the kernel in the chrooted one. Not too difficult to do at all.
Alan, patches are always preferred :-). You should also remember that 2.4 installation media *are* still available and/or used and attempts to mount sysfs under such environments would raise errors, obviously.
I meant those with 2.4 kernels, of course :-)
Sorry Shyam, I'm not sure I understand where you are going with this. Are you saying "This would be a great place to teach newbies about switching the terminal and we should add that angle to the documentation also"? I'd say that's a great idea! I really like and approve of the educational spirit of Handbook. It is a great way for a newbie have a peek at some of the more nitty-gritty aspects of Linux installation and configuration. Or are you saying "Experts have a solution for this, and so the Handbook doesn't need a solution for newbies"? I can't say I appreciate that viewpoint. Personally I would hope the aim of the Handbook is to hold a newbie's hand as much as is reasonably possible. Or are you saying "Alan is an incompitant nincompoop who should not waste our time filing bug reports"? Sticks and stones may break my bones, but words will ever flail me! ;-) But maybe you are saying something else completely? I'm just providing a suggestion here... Let's not get too hung up on the fact that there are many ways to solve a problem. After all, you can also ssh into the installation environment and have *infinite* shells (with reasonable disclaimers about available system resources). And, in fact, that would be much more useful to me, since I was installing gentoo on VMware, which, for whatever reason, does not pass through the key presses to switch terminals. Really, it just depends on what you think will be the best way to provide a newbie with a relatively painless route to a working gentoo.
Alan, IMHO he's just pointing out simple fact. IIRC, handbook discuss VT switching at the beginning, but I might be wrong at this point. BTW, Alan, you can always join us on IRC on #gentoo-doc at freenode. BTW#2 - ssh is not much useful if you lack another box, but screen (app-misc/screen) is always helpful.
"Alan is an incompitant nincompoop who should not waste our time filing bug reports"? Heh, no. We really do appreciate the fact that you're reporting something and taking the effort to get it rectified. What I'm saying is, IMHO adding sections/information to the handbook isn't warranted in this case. When you can just use lspci off the chrooted environment (Which I'm assuming will work fine) I don't see the point making changes in code listing 3 and Section 7.c We will make it clear where info can be obtained from and how and yes, as you've mentioned...many ways to solve the problem..we'd take a nice and easy way out instead of adding steps that aren't *really* required. It's like I have milk in the fridge but I have to go buy it from the shop instead of just using what I have in the fridge? :) Easier, less confusing way out would be preferred. Of course, these are my views....I don't take a final call on this :)
Shyam, as I mentioned, I have no problem with telling a user that they can use a different terminal to get back to the install environment. Why don't you propose an alternate change?
Created attachment 59347 [details, diff] Remove references to /proc/pci IMHO, this patch is the best way to solve the issue. lscpi works fine from a non-chrooted environment. The user can just run the command from one of the free terminals, instead of having to emerge lspci and having to mount sysfs etc.
Created attachment 59375 [details, diff] Remove references to /proc/pci (take 2) Xavier felt it would be better if we had both the chroot + non-chroot options, so both have now been integrated. The pcilib warning can be safely ignored for now.
I have no serious problems with that patch. Thanks to all of you.
Several comments to the patch: a) `lsmod` might be usable also from chrooted environment if you have /proc mounted (you should have, according to the HB) b) "Alternatively, you can run <c>lscpi</c> from a <e>non-chrooted</e> environment." should include the "if available" statement as some installation media might not include `lspci` support. c) The "output truncated" should be inside <comment>
(In reply to comment #25) > b) "Alternatively, you can run <c>lscpi</c> from a <e>non-chrooted</e> > environment." should include the "if available" statement as some installation > media might not include `lspci` support. We need proof of this or this stays. Can we have someone verify across all archs? Have you had issues with lspci on an architecture?
(In reply to comment #26) > We need proof of this or this stays. Can we have someone verify across all > archs? Have you had issues with lspci on an architecture? Probably all recent Gentoo Install CDs have lspci available (I have no clue on how to verify without massive downloading & ISO extraction), but some other installation media (like third party boot floppies) maybe lack it. But those media are probably "unsupported" by Handbook and taken into account only in altinstall and similar guides. -> I don't think that this point has high importance :-).
(In reply to comment #27) > Probably all recent Gentoo Install CDs have lspci available (I have no clue on > how to verify without massive downloading & ISO extraction), but some other > installation media (like third party boot floppies) maybe lack it. But those > media are probably "unsupported" by Handbook and taken into account only in > altinstall and similar guides. Xavier & myself tested 2004.3 and 2005.0 respectively and found them both with lspci. It was after that we decided to go ahead with the patch :) As you rightly mentioned, we can't support third party stuff on our docs...
Using a code listing just to show the errors that can be ignored but aren't referenced in the text above it isn't good writing imo. Better integrate it directly in the paragraph. Is it sure that lsmod also works inside the chroot?
(In reply to comment #29) > Using a code listing just to show the errors that can be ignored but aren't > referenced in the text above it isn't good writing imo. Better integrate it > directly in the paragraph. LOL. Xavier, where are you? :) > Is it sure that lsmod also works inside the chroot? The patch says : You can also run lsmod from a non-chrooted environment to see what kernel modules the Installation CD uses (it might provide you with a nice hint on what to enable).
Created attachment 59855 [details, diff] Remove references to /proc/pci (take 3) Removed unwanted code listing.
I know about the patch; Jan said it might work inside the chroot, so that's why I asked if there's a 100% assurance. If not, the patch is (imo) commit-ready.
(In reply to comment #32) > I know about the patch; Jan said it might work inside the chroot, so that's why > I asked if there's a 100% assurance. > > If not, the patch is (imo) commit-ready. I did `strace lsmod` and it seems that it only opens /proc/modules. Relevant part: open("/proc/modules", O_RDONLY) = 3 fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 5), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fea000 write(1, "Module Size Us"..., 38) = 38 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fe9000 read(3, "pl2303 19012 0 - Live 0xe0a10000"..., 1024) = 1024 write(1, "pl2303 19012 0 "..., 33) = 33 write(1, "usbserial 26856 1 "..., 39) = 39 So the `lsmod` *should* work if you have procfs available.
(In reply to comment #32) > I asked if there's a 100% assurance. There is now. Talked to plasmaroo from releng to confirm that module-init-tools are installed during stage 2. lsmod is a part of the same. That means lsmod is available at the time of kernel config and since /proc is mounted as you mentioned, I guess we can safely say it works from within the chroot as well. I've not tested, as it is quite an effort to do so. Patch will follow, removing reference to non-chrooted environment for lsmod. Should be final.
Created attachment 60260 [details, diff] lsmod works from chroot
Confirmed, `lsmod` really works from chrooted environment, but only if it can read /proc/modules. :-)
Difficult birth, finally made it :)
