randhir phagura | 1 May 16:08 2006
Picon

Re: eth0 not detected

Hi,

Howard wrote on Sat, 29 Apr 2006 21:29:57 -0400:

>>Randhir Phagura wrote
>>I have a working lfs-6.1.1 (svn-20051019) on my P-III laptop.
>>
>>I have installed "merged branch" lfs-svn-20060423 on another partition. 
>>There was no problems during install of the new lfs. I have configured 
>>kernel-2.6.16.5 to include network card and all the other devices as in my 
>>earlier lfs-6.1.1.

>What was you older kernel?
>What "lsmod" show?
>How does that compare to new kernel?

>pcmcia card services are mostly compiled into the kernel from 2.6.13 up.  I 
>have not seen a system using it yet so I don't know what modules you need 
>loaded for it to work correctly.
>Do you have pcmcia card services running right?
>Are there any other cards working?
>If you suspect pcmcia is not correct try some research starting at:
>http://pcmcia-cs.sourceforge.net/
>And follow the howto progress up to 2.6.13.

The kernel in my old lfs6.1.1 is '2.6.14'. So that portion is OK.

There is no pcmcia involved, because the network card is a built-in one on 
intel chipset mother-board. The network card is:
'Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 08)'
(Continue reading)

Ken Moffat | 1 May 20:37 2006
Picon

Re: eth0 not detected

On Mon, May 01, 2006 at 02:08:54PM +0000, randhir phagura wrote:
> 
> And the driver for this card is compiled into the kernel (not as a module).
> 
> This is the only network card on the system and I am not using any pcmcia 
> card of any kind.
> 
> And the new kernel on the new lfs under fire is '2.6.16.5'. The fact is 
> that this kernel compiled on the new system does not detect the network 
> card over there, but when copied to the old system and the old system 
> booted with this kernel, it detects the card.
> 
 Just to be absolutely clear, when you say the kernel on the new
system  does not detect the network card, you mean that dmesg has no
references to eth0 ?

> I am, therefore, inclined to conclude that the problem may be related to 
> the new "udev-hotplug and merged branch" interplay.
> 
> Can anyone throw some light on this issue?
> 

 Your analysis sounds unlikely to me, although not impossible.  So
far, you seem to be the only person reporting this.  Merging the
udev branch should not affect a built in-nic because it is not
hotplugged, and udev does not allocate a device node for it.

 If it isn't a kernel problem as shown by dmesg, my guess is that
something is wrong in your bootscripts or /etc/sysconfig - I think
there has been some change there over the past months.
(Continue reading)

Angel Tsankov | 1 May 21:40 2006
Picon

LFS 6.1.1: chroot need to exited prior to running grub?

Section 8.4. "Making the LFS System Bootable" says to start the grub shell and issue a command like "root
(hd0,3)." The root 
command, however, cannot mount the partition since we have not yet exited the chroot environment and grub
cannot find any hard 
drives. Is this right, or am I missing smth? 

--

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

Chris Staub | 1 May 21:43 2006

Re: LFS 6.1.1: chroot need to exited prior to running grub?

Angel Tsankov wrote:
> Section 8.4. "Making the LFS System Bootable" says to start the grub 
> shell and issue a command like "root (hd0,3)." The root command, 
> however, cannot mount the partition since we have not yet exited the 
> chroot environment and grub cannot find any hard drives. Is this right, 
> or am I missing smth?

You probably didn't start udev. Run /sbin/udevstart and you should have 
your hard drive devices in /dev.
--

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

Angel Tsankov | 2 May 09:23 2006
Picon

Re: LFS 6.1.1: chroot need to exited prior to running grub?

>> Section 8.4. "Making the LFS System Bootable" says to start the grub shell and issue a command like "root
(hd0,3)." The root 
>> command, however, cannot mount the partition since we have not yet exited the chroot environment and
grub cannot find any hard 
>> drives. Is this right, or am I missing smth?
>
> You probably didn't start udev. Run /sbin/udevstart and you should have your hard drive devices in /dev.

Well, it appears that I have called /sbin/udevstart (as explained in section 6.58. Udev-056) but after
shutdown (shutdown -hP now) 
and restart I do not see any devices in /mnt/lfs/dev besides null and console. Any ideas why this happens? 

--

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

Angel Tsankov | 2 May 11:37 2006
Picon

Re: LFS 6.1.1: chroot need to exited prior to running grub?

>>> Section 8.4. "Making the LFS System Bootable" says to start the grub shell and issue a command like "root
(hd0,3)." The root 
>>> command, however, cannot mount the partition since we have not yet exited the chroot environment and
grub cannot find any hard 
>>> drives. Is this right, or am I missing smth?
>>
>> You probably didn't start udev. Run /sbin/udevstart and you should have your hard drive devices in /dev.
>
> Well, it appears that I have called /sbin/udevstart (as explained in section 6.58. Udev-056) but after
shutdown (shutdown -hP now) 
> and restart I do not see any devices in /mnt/lfs/dev besides null and console. Any ideas why this happens?

Hmm, I guess that udevstart creates devices on the temp filesystem, mounted in 6.2. Mounting Virtual
Kernel File Systems, and they 
get lost when the system is rebooted. Could this be the case? 

--

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

Jan Dvořák | 2 May 12:35 2006
Picon

Re: About packagemanagement: using extended attributes. + different idea

Hello,

	I appologize for such a late response, I went on hollies. ;]

Stef Bon wrote:
> I do not known this method. I guess there is a hint or something about this
> I can read.
http://asic-linux.com.mx/~izto/checkinstall/installwatch.html

> But why not with wrappers? Installing software is a very important from the
> point of view of a system administrator. Why not modify the tools that
> really install/cp/mv/touch on your system when it comes to installing
> software. From a technical point of view this should not be a problem. 
	I've tried to write compatible `install` wrapper and it took me about
day to work correctly. I can't image rewriting (wrapping) all coreutils.
And additionally, what about `install-catalog` and `install-info`, they
should also be wrapped? There are much more...
	Trust me, it's much simpler to keep eye on apps not link glibc
statically (see link above).

> That's a good choice. I totally agree with you about the status of the DB:
> just a sort of cache. 
> But what do you mean with "installing under a package
> user"? First install everything under a different account then root, and
> after that change to root again?
	I do think it's much more secure to install under package user.
Changing ownership of e.g. glibc takes only a few seconds. If you want
to modify installed package, just create package user and chown back. I
like this because I don't want unnecessary users in my /etc/passwd and
it also offers additional security when using NFS. Package users are
(Continue reading)

randhir phagura | 2 May 16:11 2006
Picon

Re: eth0 not detected

Hi,

Ken Moffat wrote on Mon, 1 May 2006 19:37:09 +0100:

>On Mon, May 01, 2006 at 02:08:54PM +0000, randhir phagura wrote:
>>
>>And the driver for this card is compiled into the kernel (not as a 
>>module).
>>
>>This is the only network card on the system and I am not using any pcmcia 
>>card of any kind.
>>
>>And the new kernel on the new lfs under fire is '2.6.16.5'. The fact is 
>>that this kernel compiled on the new system does not detect the network 
>>card over there, but when copied to the old system and the old system 
>>booted with this kernel, it detects the card.
>>
>Just to be absolutely clear, when you say the kernel on the new
>system  does not detect the network card, you mean that dmesg has no
>references to eth0 ?

No the kernel does detect but does not bring-up eth0.

The dmesg gives the following, as related to eth0:

eth0: OEM i82557/i82558 10/100 Ethernet, 00:02:A5:A4:3F:BF, IRQ 11.
  Receiver lock-up bug exists -- enabling work-around.
  Board assembly 729857-001, Physical connectors present: RJ45
  Primary interface chip i82555 PHY #1.
  General self-test: passed.
(Continue reading)

Warren Wilder | 2 May 16:25 2006
Picon

Re: eth0 not detected

randhir phagura schreef:
>Hi,
>
>Ken Moffat wrote on Mon, 1 May 2006 19:37:09  0100:
>
>>On Mon, May 01, 2006 at 02:08:54PM  0000, randhir phagura wrote:
>>>
>>>And the driver for this card is compiled into the kernel (not as a 
>>>module).
>>>
>>>This is the only network card on the system and I am not using any pcmcia 
>>>card of any kind.
>>>
>>>And the new kernel on the new lfs under fire is '2.6.16.5'. The fact is 
>>>that this kernel compiled on the new system does not detect the network 
>>>card over there, but when copied to the old system and the old system 
>>>booted with this kernel, it detects the card.
>>>
>>Just to be absolutely clear, when you say the kernel on the new
>>system  does not detect the network card, you mean that dmesg has no
>>references to eth0 ?
>
>No the kernel does detect but does not bring-up eth0.
>
>The dmesg gives the following, as related to eth0:
>
>eth0: OEM i82557/i82558 10/100 Ethernet, 00:02:A5:A4:3F:BF, IRQ 11.
>  Receiver lock-up bug exists -- enabling work-around.
>  Board assembly 729857-001, Physical connectors present: RJ45
>  Primary interface chip i82555 PHY #1.
(Continue reading)

Ken Moffat | 2 May 16:52 2006
Picon

Re: eth0 not detected

On Tue, May 02, 2006 at 02:11:22PM +0000, randhir phagura wrote:
> 
> No the kernel does detect but does not bring-up eth0.
> 
> The dmesg gives the following, as related to eth0:
> 
> eth0: OEM i82557/i82558 10/100 Ethernet, 00:02:A5:A4:3F:BF, IRQ 11.
>  Receiver lock-up bug exists -- enabling work-around.
>  Board assembly 729857-001, Physical connectors present: RJ45
>  Primary interface chip i82555 PHY #1.
>  General self-test: passed.
>  Serial sub-system self-test: passed.
>  Internal registers self-test: passed.
>  ROM checksum self-test: passed (0x04f4518b).
>  Receiver lock-up workaround activated.
> e100: Intel(R) PRO/100 Network Driver, 3.4.14-k2-NAPI
> e100: Copyright(c) 1999-2005 Intel Corporation
> 
> The dmesg is similar to my older LFS booted with kernel-2.6.14.
> 
 In other words, the kernel appears to be working correctly -
bringing up network interfaces happens in userspace.  Both kernels
work on the old system, so the problem must be either in the
bootscripts, or in what they are executing.

> >If it isn't a kernel problem as shown by dmesg, my guess is that
> >something is wrong in your bootscripts or /etc/sysconfig - I think
> >there has been some change there over the past months.
> 
> I have installed lfs-bootscripts-20060415, as applicable to this particular 
(Continue reading)


Gmane