Re: my kernel won't recognize ide drives
William Immendorf schrieb: On Thu, Mar 18, 2010 at 2:24 PM, Scott Kopel sko...@fsu.edu wrote: So the question is what kernel configuration changes do I have to make to get the kernel to recognize my ide drives? I realize that new kernels name ide drives sdx and that's fine. I don't need them to be labeled hdx. I simply want them to be recognized by the kernel. Look in Device Drivers- Sereal ATA and Parallel ATA drivers, and you should see PATA and SATA drivers. Enable one that matches your hard disk controller, or just enable Generic ATA Support. What I usually do in those cases is matching the output of hwinfo against the help texts in the menuconfig. I had a special case here because I use a PCI PATA controller card with additional drives which needs a different driver than the onboard controllers, and these two drivers use different naming schemes, so I ended up having hda and sda/sdb, which spoiled grub's menu.lst entries a little. So just in case, when booting and unsure which drive has what number, use the tab expansion in the grub interactive shell. Cheers, Jan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [Fwd: Problems compiling Devicekit-power-012]
Thomas Sapp schrieb: [...] if someone would kindly instruct me how to redirect it to a file. I tried putting devkitpower.log on the end of the command but I only got the non-error output. Thanks in advance for any help that is provided. You can catch the stderr output using: cmd stdout.log 2stderr.log Cheers, Jan -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
write error with new version of tar
I started a new build of current dev LFS, and noticed some strange behavior from tar once inside chroot. Using tar 1.23, attempting to pipe its tf output through head results in a tar: write error. In other words... tar -tjf /home/sources/glibc-2.11.1.tar.bz2 | head -n1 glibc-2.11.1/ ./tar-1.23/src/tar: write error I do not get any kind of error message when just using tar -tf by itself, only when piping through head. Also, I tried piping through various other programs (grep, sed...) and got nothing. Initially I thought there was some problem with filesystems mounted or something like that in the chroot, but I get exactly the same result on my host system. In fact, if I unpack tar 1.22 and do ./configure make, then do the same with tar 1.23, and try using the tf option with both versions of tar (this is on my host system)... ch...@chris_laptop:~$ ./tar-1.22/src/tar -tjf /home/sources/glibc-2.11.1.tar.bz2 | head -n1 ./tar-1.22/src/tar: Record size = 8 blocks glibc-2.11.1/ ch...@chris_laptop:~$ ./tar-1.23/src/tar -tjf /home/sources/glibc-2.11.1.tar.bz2 | head -n1 glibc-2.11.1/ ./tar-1.23/src/tar: write error ch...@chris_laptop:~$ I also get the same result inside chroot. My host system is a few-months-old CLFS build with EGLIBC, and the chroot environment is a current LFS dev build, so there are different versions of both libc and Coreutils, but I get the same results. I don't know why it seems to come up only when piping through head, and it doesn't really seem to affect anything - my scripts (which use tar tf | head and are the reason I noticed this in the first place) still seem to work fine. I just want to verify if anyone else gets the same result - basically take Tar 1.23, do tar tf [filename] | head and see what happens. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
my kernel won't recognize ide drives - solved
You guys are generous and amazing. Thank you for the responses. I've been working on this issue for weeks, googling everywhere etc.. and the solution was so simple once I had help from the lfs community. I'm writing this so that maybe a future searcher might find it. here's my solution: I installed PCI Utilities-3.1.7 - http://www.linuxfromscratch.org/blfs/view/svn/general/pciutils.html the relevant part of the output of lspci was 00:11.0 SATA controller: ATI Technologies Inc SB700/SB800 SATA Controller [IDE mode] 00:14.1 IDE interface: ATI Technologies Inc SB700/SB800 IDE Controller so in make menuconfig I enabled ati pata support option (device drivers/serial ata and parallel ata drivers/ati pata support) and Voila!!! ... fdisk -l the ide drive is sdb here's my original question: I recently built a system following the lfs 6.5 book exactly. The only difference in my distro is that I used kernel 2.6.30.10 instead of the suggested 2.6.30.2 kernel. In compiling the kernel I used all the default settings except the following: --I disabled loadable kernel modules --I added the drivers for my nic --I added limit and recent match support in the netfiltering section --I changed the processor family to athlon/duron The system harddrive is a sata and it all works perfectly. My problem is that I have a several pata (ide) drives that I'd like to add to the system. The kernel doesn't recognize them. fdisk -l shows only sda and in /dev the only harddrive listed is sda. I ran dmesg | grep hd and found no references to hdx drives. I ran dmesg | grep sd and found only a reference to sda. I took the kernel from a Knoppix installation (2.6.32.6) and booted my lfs system with it and all the drives including the pata (ide) drives now appear. This leads me to believe that my problem is with my kernel configuration. So the question is what kernel configuration changes do I have to make to get the kernel to recognize my ide drives? I realize that new kernels name ide drives sdx and that's fine. I don't need them to be labeled hdx. I simply want them to be recognized by the kernel. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: write error with new version of tar
Chris Staub wrote: I started a new build of current dev LFS, and noticed some strange behavior from tar once inside chroot. Using tar 1.23, attempting to pipe its tf output through head results in a tar: write error. In other words... tar -tjf /home/sources/glibc-2.11.1.tar.bz2 | head -n1 glibc-2.11.1/ ./tar-1.23/src/tar: write error I do not get any kind of error message when just using tar -tf by itself, only when piping through head. Also, I tried piping through various other programs (grep, sed...) and got nothing. I get the same error message with head: ./configure make cd src ./tar -tf ../../tar-1.23.tar.bz2 |head Initially I thought there was some problem with filesystems mounted or something like that in the chroot, but I get exactly the same result on my host system. Me too. I'll report the bug. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: write error with new version of tar
Bruce Dubbs wrote:
Chris Staub wrote:
[...]
I do not get any kind of error message when just using tar -tf by
itself, only when piping through head. Also, I tried piping through
various other programs (grep, sed...) and got nothing.
I get the same error message with head:
./configure
make
cd src
./tar -tf ../../tar-1.23.tar.bz2 |head
Me too.
I'll report the bug.
I wonder if head is closing the input pipe when it has read
all it needs, and that's causing the error. I can't reproduce
that problem with my host system, however.
Mike
--
p=p=%c%s%c;main(){printf(p,34,p,34);};main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: write error with new version of tar
On 3/19/10, Mike McCarty mike.mcca...@sbcglobal.net wrote: I wonder if head is closing the input pipe when it has read all it needs, and that's causing the error. I can't reproduce that problem with my host system, however. It is tar-1.23 and not head head --version head (GNU coreutils) 8.4 tar -xf tar-1.23.tar.bz2 cd tar-1.23 ./configure --prefix=/usr --bindir=/bin --libexecdir=/usr/sbin make src/tar --version tar (GNU tar) 1.23 src/tar -tf ../tar-1.23.tar.bz2 | head -1 tar-1.23/ src/tar: write error tar --version tar (GNU tar) 1.22 tar -tf ../tar-1.23.tar.bz2 | head -1 tar: Record size = 8 blocks tar-1.23/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: write error with new version of tar
linux fan wrote: On 3/19/10, Mike McCarty mike.mcca...@sbcglobal.net wrote: I wonder if head is closing the input pipe when it has read all it needs, and that's causing the error. I can't reproduce that problem with my host system, however. It is tar-1.23 and not head head --version head (GNU coreutils) 8.4 tar -xf tar-1.23.tar.bz2 cd tar-1.23 ./configure --prefix=/usr --bindir=/bin --libexecdir=/usr/sbin make src/tar --version tar (GNU tar) 1.23 src/tar -tf ../tar-1.23.tar.bz2 | head -1 tar-1.23/ src/tar: write error tar --version tar (GNU tar) 1.22 tar -tf ../tar-1.23.tar.bz2 | head -1 tar: Record size = 8 blocks tar-1.23/ Right. They changed something with regard to the SIGPIPE signal. The default action is to terminate (man 7 signal), but they changed it to SIGIGN (ignore). It needs to be fixed. http://git.savannah.gnu.org/gitweb/?p=tar.git;a=commitdiff;h=release_1_22-41-g0c6c288 If I revert this change, the program works normally. I did not revert the change to the tests and test 91 failed. I did report the error, and it seems it was also reported earlier today by someone else. Right now it is only an irritation, but we may want to consider reverting to version 1.22. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: write error with new version of tar
On Fri, 19 Mar 2010 14:21:29 -0600 Mike McCarty mike.mcca...@sbcglobal.net wrote: Bruce Dubbs wrote: Chris Staub wrote: [...] I do not get any kind of error message when just using tar -tf by itself, only when piping through head. Also, I tried piping through various other programs (grep, sed...) and got nothing. I get the same error message with head: ./configure make cd src ./tar -tf ../../tar-1.23.tar.bz2 |head Me too. I'll report the bug. I wonder if head is closing the input pipe when it has read all it needs, and that's causing the error. I can't reproduce that problem with my host system, however. Mike I can also confirm problems with tar-1.23. What is your host system? I have Glibc-2.9, GNU Coreutils-7.6 and Bash-4.0.35, on top of Linux-2.6.23.2. Speculating: maybe the problem is not with the tar per se, but somewhere in the interface? If there is a system on which tar-1.23 behaves properly.. -AKuktin -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
