Re: [lfs-support] udev problem
On 10/20/2013 05:13 PM, Bruce Dubbs wrote:
Casey Daniels wrote:
On 10/20/2013 11:25 AM, Bruce Dubbs wrote:
Are these lines split for email or are they that way in the file? I
think you need to escape some newlines. For example,
# net device e1000e
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, \
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0, \
ATTR{type}==1, KERNEL==eth*, NAME=eth0
You can also try:
udevadm test --action=ADD /sys/class/net/device
-- Bruce
Found out something interesting. As long as I don't try to assign
anything except the onboard NIC to eth0, it will let me do as I please.
I can even name the onboard NIC to something other than eth0, but
anytime I try to name something eth0 (besides the onboard nic) udev just
does what ever it wants to do.
Just a thought. I believe a system sets up to preset values and then
renames what's required when it processes the rule. If something is
already named to the value requested, then the rename fails.
What are the values in /sys/class/net/ with no rules? Then what if you
just try to change one of the problem interfaces to say, eth1, does that
work?
One thing to try is to skip the udev sections in the boot sequence
completely and then run udevd with --debug after boot. Another thing to
try is setting udev.log-priority=debug on the kernel command line.
-- Bruce
I finally got tired of fighting it, and just moved the cables.
Casey
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
[lfs-support] udev problem
My system was working fine, until I decided that I needed to add an additional Network interface card (turned on the previous deactivated onboard NIC). Now my network card names are all messed up. I've edited the 70-persistent-net.rules file, but udev seems to be ignoring it and naming devices as it pleases. I have 4 Ethernet Devices and 2 wlan Devices, is that too many for udev to rename properly? Thank You, Casey -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] udev problem
Casey Daniels wrote: My system was working fine, until I decided that I needed to add an additional Network interface card (turned on the previous deactivated onboard NIC). Now my network card names are all messed up. I've edited the 70-persistent-net.rules file, but udev seems to be ignoring it and naming devices as it pleases. I have 4 Ethernet Devices and 2 wlan Devices, is that too many for udev to rename properly? No. Can you post your 70-persistent-net.rules file? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] udev problem
Casey Daniels wrote:
On 10/20/2013 10:36 AM, Bruce Dubbs wrote:
Casey Daniels wrote:
My system was working fine, until I decided that I needed to add an
additional Network interface card (turned on the previous deactivated
onboard NIC). Now my network card names are all messed up. I've edited
the 70-persistent-net.rules file, but udev seems to be ignoring it and
naming devices as it pleases.
I have 4 Ethernet Devices and 2 wlan Devices, is that too many for udev
to rename properly?
No.
Can you post your 70-persistent-net.rules file?
-- Bruce
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# net device e1000e
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0,
ATTR{type}==1, KERNEL==eth*, NAME=eth3
# net device e1000e
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0,
ATTR{type}==1, KERNEL==eth*, NAME=eth0
# net device e1000e
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0,
ATTR{type}==1, KERNEL==eth*, NAME=eth1
# net device e1000e
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0,
ATTR{type}==1, KERNEL==eth*, NAME=eth2
# net device iwlwifi
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0,
ATTR{type}==1, KERNEL==wlan*, NAME=wlan0
# net device iwlwifi
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0,
ATTR{type}==1, KERNEL==wlan*, NAME=wlan1
MAC Address replaced with X's, if you need the actual address let me know.
Are these lines split for email or are they that way in the file? I
think you need to escape some newlines. For example,
# net device e1000e
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, \
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0, \
ATTR{type}==1, KERNEL==eth*, NAME=eth0
You can also try:
udevadm test --action=ADD /sys/class/net/device
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] udev problem
On 10/20/2013 11:25 AM, Bruce Dubbs wrote:
Casey Daniels wrote:
On 10/20/2013 10:36 AM, Bruce Dubbs wrote:
Casey Daniels wrote:
My system was working fine, until I decided that I needed to add an
additional Network interface card (turned on the previous deactivated
onboard NIC). Now my network card names are all messed up. I've edited
the 70-persistent-net.rules file, but udev seems to be ignoring it and
naming devices as it pleases.
I have 4 Ethernet Devices and 2 wlan Devices, is that too many for udev
to rename properly?
No.
Can you post your 70-persistent-net.rules file?
-- Bruce
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# net device e1000e
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0,
ATTR{type}==1, KERNEL==eth*, NAME=eth3
# net device e1000e
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0,
ATTR{type}==1, KERNEL==eth*, NAME=eth0
# net device e1000e
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0,
ATTR{type}==1, KERNEL==eth*, NAME=eth1
# net device e1000e
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0,
ATTR{type}==1, KERNEL==eth*, NAME=eth2
# net device iwlwifi
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0,
ATTR{type}==1, KERNEL==wlan*, NAME=wlan0
# net device iwlwifi
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0,
ATTR{type}==1, KERNEL==wlan*, NAME=wlan1
MAC Address replaced with X's, if you need the actual address let me know.
Are these lines split for email or are they that way in the file? I
think you need to escape some newlines. For example,
# net device e1000e
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, \
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0, \
ATTR{type}==1, KERNEL==eth*, NAME=eth0
You can also try:
udevadm test --action=ADD /sys/class/net/device
-- Bruce
They are 1 line in the file, its just what email did to them.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] udev problem
On 10/20/2013 11:25 AM, Bruce Dubbs wrote:
Casey Daniels wrote:
On 10/20/2013 10:36 AM, Bruce Dubbs wrote:
Casey Daniels wrote:
My system was working fine, until I decided that I needed to add an
additional Network interface card (turned on the previous deactivated
onboard NIC). Now my network card names are all messed up. I've edited
the 70-persistent-net.rules file, but udev seems to be ignoring it and
naming devices as it pleases.
I have 4 Ethernet Devices and 2 wlan Devices, is that too many for udev
to rename properly?
No.
Can you post your 70-persistent-net.rules file?
-- Bruce
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# net device e1000e
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0,
ATTR{type}==1, KERNEL==eth*, NAME=eth3
# net device e1000e
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0,
ATTR{type}==1, KERNEL==eth*, NAME=eth0
# net device e1000e
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0,
ATTR{type}==1, KERNEL==eth*, NAME=eth1
# net device e1000e
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0,
ATTR{type}==1, KERNEL==eth*, NAME=eth2
# net device iwlwifi
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0,
ATTR{type}==1, KERNEL==wlan*, NAME=wlan0
# net device iwlwifi
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0,
ATTR{type}==1, KERNEL==wlan*, NAME=wlan1
MAC Address replaced with X's, if you need the actual address let me know.
Are these lines split for email or are they that way in the file? I
think you need to escape some newlines. For example,
# net device e1000e
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, \
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0, \
ATTR{type}==1, KERNEL==eth*, NAME=eth0
You can also try:
udevadm test --action=ADD /sys/class/net/device
-- Bruce
Is there a way to see if Udev is even reading the
70-persistent-net.rules on boot?
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] udev problem
On 10/20/2013 11:25 AM, Bruce Dubbs wrote:
Are these lines split for email or are they that way in the file? I
think you need to escape some newlines. For example,
# net device e1000e
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, \
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0, \
ATTR{type}==1, KERNEL==eth*, NAME=eth0
You can also try:
udevadm test --action=ADD /sys/class/net/device
-- Bruce
Found out something interesting. As long as I don't try to assign
anything except the onboard NIC to eth0, it will let me do as I please.
I can even name the onboard NIC to something other than eth0, but
anytime I try to name something eth0 (besides the onboard nic) udev just
does what ever it wants to do.
Casey
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] udev problem
Casey Daniels wrote:
On 10/20/2013 11:25 AM, Bruce Dubbs wrote:
Are these lines split for email or are they that way in the file? I
think you need to escape some newlines. For example,
# net device e1000e
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, \
ATTR{address}==XX:XX:XX:XX:XX:XX, ATTR{dev_id}==0x0, \
ATTR{type}==1, KERNEL==eth*, NAME=eth0
You can also try:
udevadm test --action=ADD /sys/class/net/device
-- Bruce
Found out something interesting. As long as I don't try to assign
anything except the onboard NIC to eth0, it will let me do as I please.
I can even name the onboard NIC to something other than eth0, but
anytime I try to name something eth0 (besides the onboard nic) udev just
does what ever it wants to do.
Just a thought. I believe a system sets up to preset values and then
renames what's required when it processes the rule. If something is
already named to the value requested, then the rename fails.
What are the values in /sys/class/net/ with no rules? Then what if you
just try to change one of the problem interfaces to say, eth1, does that
work?
One thing to try is to skip the udev sections in the boot sequence
completely and then run udevd with --debug after boot. Another thing to
try is setting udev.log-priority=debug on the kernel command line.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: udev problem
On Wed, Dec 8, 2010 at 7:45 PM, Ken Moffat zarniwh...@ntlworld.com wrote: On Wed, Dec 08, 2010 at 06:31:31PM -0600, robert wrote: No, I got the me hopes part ... quite Shakespearean, in fact ... as in methinks ... It's the build itself part ... still don't understand what that means. Do you mean just write up a script and cut it loose to build the os? The idea (in the days of iterative comparison analysis, and before), was that a new LFS system should have everything it needed to build itself, and that the result ought to be identical (in practice, after stripping files, and removing the different compressed timestamps from gzipped files, and some other we don't quite know why this always differs files). So, some of us used to take a new development or pre-release version, and let it build itself (or rebuild itself in-place for Greg's version of ICA). With modern toolchains, I've given up doing that because there were too many unexplainable differences, perhaps caused by address randomization. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page The last sentance there hits the head on why ICA doesn't really work anymore. There's features in the kernel, glibc, binutils and gcc all of which will cause the build results to be slightly different each time. Heck, at work we're trying to figure out why our builds built over night run 2.3% faster than our builds during the day. And I'm not talking about the build itself, but the actual runtime. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
Stuart Stegall wrote: On Wed, Dec 8, 2010 at 7:45 PM, Ken Moffat zarniwh...@ntlworld.com wrote: On Wed, Dec 08, 2010 at 06:31:31PM -0600, robert wrote: No, I got the me hopes part ... quite Shakespearean, in fact ... as in methinks ... It's the build itself part ... still don't understand what that means. Do you mean just write up a script and cut it loose to build the os? The idea (in the days of iterative comparison analysis, and before), was that a new LFS system should have everything it needed to build itself, and that the result ought to be identical (in practice, after stripping files, and removing the different compressed timestamps from gzipped files, and some other we don't quite know why this always differs files). So, some of us used to take a new development or pre-release version, and let it build itself (or rebuild itself in-place for Greg's version of ICA). With modern toolchains, I've given up doing that because there were too many unexplainable differences, perhaps caused by address randomization. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page The last sentance there hits the head on why ICA doesn't really work anymore. There's features in the kernel, glibc, binutils and gcc all of which will cause the build results to be slightly different each time. Heck, at work we're trying to figure out why our builds built over night run 2.3% faster than our builds during the day. And I'm not talking about the build itself, but the actual runtime. More body heat in the room. Less efficient processor. Laboring processor. Less air current in the room, resulting in reduced electron jiggle. My Fiat Spyder runs a good deal better at night, but maybe that has to do with other factors -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
On Thu, Dec 9, 2010 at 11:59 AM, robert mullinrob...@gmail.com wrote: Stuart Stegall wrote: On Wed, Dec 8, 2010 at 7:45 PM, Ken Moffat zarniwh...@ntlworld.com wrote: On Wed, Dec 08, 2010 at 06:31:31PM -0600, robert wrote: No, I got the me hopes part ... quite Shakespearean, in fact ... as in methinks ... It's the build itself part ... still don't understand what that means. Do you mean just write up a script and cut it loose to build the os? The idea (in the days of iterative comparison analysis, and before), was that a new LFS system should have everything it needed to build itself, and that the result ought to be identical (in practice, after stripping files, and removing the different compressed timestamps from gzipped files, and some other we don't quite know why this always differs files). So, some of us used to take a new development or pre-release version, and let it build itself (or rebuild itself in-place for Greg's version of ICA). With modern toolchains, I've given up doing that because there were too many unexplainable differences, perhaps caused by address randomization. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page The last sentance there hits the head on why ICA doesn't really work anymore. There's features in the kernel, glibc, binutils and gcc all of which will cause the build results to be slightly different each time. Heck, at work we're trying to figure out why our builds built over night run 2.3% faster than our builds during the day. And I'm not talking about the build itself, but the actual runtime. More body heat in the room. Less efficient processor. Laboring processor. Less air current in the room, resulting in reduced electron jiggle. My Fiat Spyder runs a good deal better at night, but maybe that has to do with other factors -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page My M3 runs better in the cold, and that has everything to do with cold. In this case though, this is in a temperature controlled Data Center with no competition for cycles. The program actually runs during the day, but if the build was done during the day, it will take a little bit longer, if it's done at night, it takes a bit less. Strangest thing I have ever experienced. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
On Thursday 09 December 2010 16:22:34 Stuart Stegall wrote: My M3 runs better in the cold, and that has everything to do with cold. In this case though, this is in a temperature controlled Data Center with no competition for cycles. The program actually runs during the day, but if the build was done during the day, it will take a little bit longer, if it's done at night, it takes a bit less. Strangest thing I have ever experienced. *Something's* competing for cycles. First thing comes to mind is network traffic, like ARP or other broadcast traffic. Might be intersting to put an analyzer on the LAN segment and see what differs. If nothing else, you've discovered a true 'night and day' difference. :) -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
On Tue, Dec 07, 2010 at 08:18:17PM -0500, Mike Hollis wrote: On Tue, Dec 07, 2010 at 05:13:19PM -0600, robert wrote: In other matters, I'm setting up another machine to step thru the LFS build ... don't know what else to do. Since your at an impasse here , why not try installing udev and if it fails to install get a copy of the MAKDEV script , compile your kernel, set up boot from your host bootloader and see if it will boot. I don't see where you have anything to lose; The failure of the the udev test may indicate some fatal flaw , but after all your work getting this far it would be encouraging to see it boot. It would also give you a leg up on this part of the process if you start over. Actually, looking back at this thread, nobody knows which test fails - there are about 142 of them. Robert - try logging the output to a file, then use less or vim to search for 'FAIL' - if that doesn't find anything, you'll need to look at the results line by line to identify which test failed. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
On Wed, Dec 8, 2010 at 10:12 AM, robert mullinrob...@gmail.com wrote: Ken Moffat wrote: On Tue, Dec 07, 2010 at 08:18:17PM -0500, Mike Hollis wrote: On Tue, Dec 07, 2010 at 05:13:19PM -0600, robert wrote: In other matters, I'm setting up another machine to step thru the LFS build ... don't know what else to do. Since your at an impasse here , why not try installing udev and if it fails to install get a copy of the MAKDEV script , compile your kernel, set up boot from your host bootloader and see if it will boot. I don't see where you have anything to lose; The failure of the the udev test may indicate some fatal flaw , but after all your work getting this far it would be encouraging to see it boot. It would also give you a leg up on this part of the process if you start over. Actually, looking back at this thread, nobody knows which test fails - there are about 142 of them. Robert - try logging the output to a file, then use less or vim to search for 'FAIL' - if that doesn't find anything, you'll need to look at the results line by line to identify which test failed. ĸen Partial output of make check: make --no-print-directory check-recursive Making check in . make --no-print-directory libudev/test-libudev udev/test-udev make[3]: `libudev/test-libudev' is up to date. make[3]: `udev/test-udev' is up to date. make --no-print-directory check-TESTS udev-test will run 142 tests: TEST 1: no rules device '/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' expecting node/link 'sda' add: ok remove: error as expected TEST 2: label test of scsi disc device '/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' expecting node/link 'boot_disk' add: ok remove: ok AFTER THIS, ALL add/remove reports ok, UNTIL .. TEST 139: TEST MODE= device '/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' expecting node/link 'sda' permissions: ok add: ok remove: error as expected TEST 140: TEST PROGRAM feeds OWNER, GROUP, MODE device '/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' expecting node/link 'sda' permissions: ok add: ok remove: error as expected TEST 141: TEST PROGRAM feeds MODE with overflow device '/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' expecting node/link 'sda' permissions: ok add: ok remove: error as expected TEST 142: magic [subsys/sysname] attribute substitution device '/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' expecting node/link 'sda-8741C4G-end' permissions: ok add: ok remove: ok 1 errors occured FAIL: test/udev-test.pl == 1 of 1 test failed Please report to linux-hotp...@vger.kernel.org == My host system is on /dev/sda ... LFS is /dev/sdb ... source of problem? And to be expected? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page Expected failures come from when you know a test will fail on a particular architecture/OS. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
On Wed, Dec 08, 2010 at 10:12:52AM -0600, robert wrote: Partial output of make check: make --no-print-directory check-recursive Making check in . make --no-print-directory libudev/test-libudev udev/test-udev make[3]: `libudev/test-libudev' is up to date. make[3]: `udev/test-udev' is up to date. make --no-print-directory check-TESTS udev-test will run 142 tests: TEST 1: no rules device '/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' expecting node/link 'sda' add: ok remove: error as expected TEST 2: label test of scsi disc device '/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' expecting node/link 'boot_disk' add: ok remove: ok AFTER THIS, ALL add/remove reports ok, UNTIL .. TEST 139: TEST MODE= device '/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' expecting node/link 'sda' permissions: ok add: ok remove: error as expected TEST 140: TEST PROGRAM feeds OWNER, GROUP, MODE device '/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' expecting node/link 'sda' permissions: ok add: ok remove: error as expected TEST 141: TEST PROGRAM feeds MODE with overflow device '/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' expecting node/link 'sda' permissions: ok add: ok remove: error as expected TEST 142: magic [subsys/sysname] attribute substitution device '/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' expecting node/link 'sda-8741C4G-end' permissions: ok add: ok remove: ok 1 errors occured FAIL: test/udev-test.pl == 1 of 1 test failed Please report to linux-hotp...@vger.kernel.org == So, as with many test suites, bookkeeping might not be its strong point. As Stuart noted, we normally ignore error as expected. My own build on the machine I'm using today (LFS from a week or two before 6.7 was released) reported that 0 errors occurred and 1 test passed. However, my results differ from yours - I see everything you have quoted, but I had other 'error as expected' reports in tests 81 (remove) and 82 (add). Probably, the term to search for is 'error' not FAIL - maybe you could recheck your log ? If that doesn't show any other information, you need to consider whether the tests all *need* to pass. I'm not familiar with the udev testsuite, but many testsuites check corner-cases and have occasional failures from time to time, usually because something unrelated changed and the testsuite itself broke. Having all tests pass might provide some comfort, but it gives no information about whether the package will work in real life. I am inclined to suggest install it, continue, and see if it works when you have booted it. Maybe there is something unusual about your host distro, particularly the toolchain or kernel. What are the versions of gcc, glibc, and the kernel on the host system ? (/me hopes this isn't an example of using LFS-6.7 to see if it will build itself). Also, if you have access to the .config for the running kernel (/proc/config.gz if it has been enabled, or other distro-specific places), are any of the CONFIG_SYSFS_DEPRECATED option(s) set ? You definitely _don't_ want those set in a recent system, but might need it/them on an old host. As of 2.6.36 only ..._V2 exists, but I think 2.6.35 might have had both options. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
Stuart Stegall wrote: udev-test will run 142 tests: FAIL: test/udev-test.pl == 1 of 1 test failed My system has error as expected for tests 1, 48, 81, 82, 139, 140, and 141 for udev-161. 0 errors occured PASS: test/udev-test.pl = 1 test passed = There should be something in the results that is not either 'ok' or 'error as expected' Paste the entire log at http://pastebin.com/ and send us the url generated in the address bar. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
robert wrote: Bruce Dubbs wrote: Stuart Stegall wrote: udev-test will run 142 tests: FAIL: test/udev-test.pl == 1 of 1 test failed My system has error as expected for tests 1, 48, 81, 82, 139, 140, and 141 for udev-161. 0 errors occured PASS: test/udev-test.pl = 1 test passed = There should be something in the results that is not either 'ok' or 'error as expected' Paste the entire log at http://pastebin.com/ and send us the url generated in the address bar. -- Bruce pastebin URL: http://pastebin.com/6jaJfxeP Your error is in Test 31. Looking at the test code, it appears that it is looking for /dev/sda5. I'll bet you don't have that on your system. You can ignore this error if so. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
On Wed, Dec 08, 2010 at 03:13:58PM -0600, robert wrote: pastebin URL: http://pastebin.com/6jaJfxeP Test 31 (add) - test labelled Program with subshell plus the 'error as expected' messages for 81, 82. Possibly, your build of bash will turn out to be damaged, or else your host maybe has a strange /bin/sh. If the latter, I'm surprised you got through glibc. Beyond that, I repeat my comments from a few hours ago - continue, and see if it works adequately when you use it. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
Ken Moffat wrote: On Wed, Dec 08, 2010 at 10:12:52AM -0600, robert wrote: Partial output of make check: make --no-print-directory check-recursive Making check in . make --no-print-directory libudev/test-libudev udev/test-udev make[3]: `libudev/test-libudev' is up to date. make[3]: `udev/test-udev' is up to date. make --no-print-directory check-TESTS udev-test will run 142 tests: TEST 1: no rules device '/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' expecting node/link 'sda' add: ok remove: error as expected TEST 2: label test of scsi disc device '/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' expecting node/link 'boot_disk' add: ok remove: ok AFTER THIS, ALL add/remove reports ok, UNTIL .. TEST 139: TEST MODE= device '/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' expecting node/link 'sda' permissions: ok add: ok remove: error as expected TEST 140: TEST PROGRAM feeds OWNER, GROUP, MODE device '/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' expecting node/link 'sda' permissions: ok add: ok remove: error as expected TEST 141: TEST PROGRAM feeds MODE with overflow device '/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' expecting node/link 'sda' permissions: ok add: ok remove: error as expected TEST 142: magic [subsys/sysname] attribute substitution device '/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' expecting node/link 'sda-8741C4G-end' permissions: ok add: ok remove: ok 1 errors occured FAIL: test/udev-test.pl == 1 of 1 test failed Please report to linux-hotp...@vger.kernel.org == So, as with many test suites, bookkeeping might not be its strong point. As Stuart noted, we normally ignore error as expected. My own build on the machine I'm using today (LFS from a week or two before 6.7 was released) reported that 0 errors occurred and 1 test passed. However, my results differ from yours - I see everything you have quoted, but I had other 'error as expected' reports in tests 81 (remove) and 82 (add). Probably, the term to search for is 'error' not FAIL - maybe you could recheck your log ? If that doesn't show any other information, you need to consider whether the tests all *need* to pass. I'm not familiar with the udev testsuite, but many testsuites check corner-cases and have occasional failures from time to time, usually because something unrelated changed and the testsuite itself broke. Having all tests pass might provide some comfort, but it gives no information about whether the package will work in real life. I am inclined to suggest install it, continue, and see if it works when you have booted it. Maybe there is something unusual about your host distro, particularly the toolchain or kernel. What are the versions of gcc, glibc, and the kernel on the host system ? (/me hopes this isn't an example of using LFS-6.7 to see if it will build itself). Also, if you have access to the .config for the running kernel (/proc/config.gz if it has been enabled, or other distro-specific places), are any of the CONFIG_SYSFS_DEPRECATED option(s) set ? You definitely _don't_ want those set in a recent system, but might need it/them on an old host. As of 2.6.36 only ..._V2 exists, but I think 2.6.35 might have had both options. ĸen .config of host reveals: # CONFIG_SYSFS_DEPRECATED_V2 is not set gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 glibc: libc-2.11.1.so kernel: vmlinuz-2.6.32-26-generic what does this mean? me hopes this isn't an example of using LFS-6.7 to see if it will build itself?? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
On Wed, Dec 08, 2010 at 04:46:00PM -0600, robert wrote: .config of host reveals: # CONFIG_SYSFS_DEPRECATED_V2 is not set gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 glibc: libc-2.11.1.so kernel: vmlinuz-2.6.32-26-generic Those seem adequate what does this mean? me hopes this isn't an example of using LFS-6.7 to see if it will build itself?? '/me' is common on mailing lists. If that is what you are querying, read it as I hope If you are wondering why I hope you aren't using LFS-6.7 to build itself, the answer is that I know you had built 6.7 before, because you reported grub / kernel problems. I believe LFS-6.7 is a reliable build, and therefore I will be very disappointed and embarrassed if it turns out to have problems building itself. Historically, can it build itself was an old way of testing LFS development versions, and I've no worries about people doing it. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
On Wed, Dec 08, 2010 at 04:48:22PM -0600, robert wrote: Thanks everyone for the help. I do have /dev/sda5: /dev/sda5: UUID=a6ce6f3f-7bb5-4069-a32c-a8388472f15d TYPE=ext3 You write English well, but I wonder if you have misunderstood ? The question can be reworded as in chroot, does /dev/sda5 exist ?. You appear to have quoted something I don't recognize (perhaps it is 'parted') to show the UUID and a (filesystem ?) type. In chroot, ls -l /dev/sda* ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
Ken Moffat wrote: On Wed, Dec 08, 2010 at 04:48:22PM -0600, robert wrote: Thanks everyone for the help. I do have /dev/sda5: /dev/sda5: UUID=a6ce6f3f-7bb5-4069-a32c-a8388472f15d TYPE=ext3 You write English well, but I wonder if you have misunderstood ? The question can be reworded as in chroot, does /dev/sda5 exist ?. You appear to have quoted something I don't recognize (perhaps it is 'parted') to show the UUID and a (filesystem ?) type. In chroot, ls -l /dev/sda* ĸen first listing was blkid in host environment ... Once upon a time English professor finds in /mnt/lfs chroot environment: root:/# ls -l /dev/sda brw-rw 1 root daemon 8, 0 Dec 8 15:05 /dev/sda root:/# ls -l /dev/sda* brw-rw 1 root daemon 8, 0 Dec 8 15:05 /dev/sda brw-rw 1 root daemon 8, 1 Dec 8 15:05 /dev/sda1 brw-rw 1 root daemon 8, 2 Dec 8 15:05 /dev/sda2 brw-rw 1 root daemon 8, 3 Dec 8 15:05 /dev/sda3 brw-rw 1 root daemon 8, 4 Dec 8 15:05 /dev/sda4 brw-rw 1 root daemon 8, 5 Dec 8 15:05 /dev/sda5 -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
Ken Moffat wrote: On Wed, Dec 08, 2010 at 04:46:00PM -0600, robert wrote: .config of host reveals: # CONFIG_SYSFS_DEPRECATED_V2 is not set gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 glibc: libc-2.11.1.so kernel: vmlinuz-2.6.32-26-generic Those seem adequate what does this mean? me hopes this isn't an example of using LFS-6.7 to see if it will build itself?? '/me' is common on mailing lists. If that is what you are querying, read it as I hope If you are wondering why I hope you aren't using LFS-6.7 to build itself, the answer is that I know you had built 6.7 before, because you reported grub / kernel problems. I believe LFS-6.7 is a reliable build, and therefore I will be very disappointed and embarrassed if it turns out to have problems building itself. Historically, can it build itself was an old way of testing LFS development versions, and I've no worries about people doing it. ĸen No, I got the me hopes part ... quite Shakespearean, in fact ... as in methinks ... It's the build itself part ... still don't understand what that means. Do you mean just write up a script and cut it loose to build the os? r. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
On Wed, Dec 08, 2010 at 06:31:31PM -0600, robert wrote: No, I got the me hopes part ... quite Shakespearean, in fact ... as in methinks ... It's the build itself part ... still don't understand what that means. Do you mean just write up a script and cut it loose to build the os? The idea (in the days of iterative comparison analysis, and before), was that a new LFS system should have everything it needed to build itself, and that the result ought to be identical (in practice, after stripping files, and removing the different compressed timestamps from gzipped files, and some other we don't quite know why this always differs files). So, some of us used to take a new development or pre-release version, and let it build itself (or rebuild itself in-place for Greg's version of ICA). With modern toolchains, I've given up doing that because there were too many unexplainable differences, perhaps caused by address randomization. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
udev problem
just did the build at host level: works fine. any suggestions? [X] make check make --no-print-directory check-recursive Making check in . make --no-print-directory libudev/test-libudev udev/test-udev CC libudev/test-libudev.o CCLD libudev/test-libudev CC udev/test-udev.o CCLD udev/test-udev make --no-print-directory check-TESTS Must have root permissions to run properly. PASS: test/udev-test.pl = 1 test passed = Making check in libudev/docs make[2]: Nothing to be done for `check'. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
On Tuesday 07 December 2010 04:55:43 robert wrote: unpacked udev-161.tar.bz2 cd udev-161 then copy and paste ... (the two dearchive operations are xvf??? and not jxvf??? 'tar xvf' unpacks a noncompressed tar archvie (.tar). 'tar xvfj' unpacks a bz2-compressed archive (.tar.bz2). 'tar xvfz' unpacks a gzip-compressed archive (.tar.gz, .tgz). -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
Neal Murphy wrote: On Tuesday 07 December 2010 04:55:43 robert wrote: unpacked udev-161.tar.bz2 cd udev-161 then copy and paste ... (the two dearchive operations are xvf??? and not jxvf??? 'tar xvf' unpacks a noncompressed tar archvie (.tar). 'tar xvfj' unpacks a bz2-compressed archive (.tar.bz2). 'tar xvfz' unpacks a gzip-compressed archive (.tar.gz, .tgz). So, I don't follow then. Instructions at 6.59. Udev-161 say: tar -xvf ../udev-config-20100128.tar.bz2 ... why not *J*xvf? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
Mike Hollis wrote:
On Tue, Dec 07, 2010 at 03:55:43AM -0600, robert wrote:
Mike H.-
jumped back out to root user
asserted root:root for /tools (verified)
still at root:
copy and paste everything from 6.2 thru 6.6
now in chroot ...
move over to 6.59 and ...
unpacked udev-161.tar.bz2
cd udev-161
snip
FAIL: test/udev-test.pl
==
1 of 1 test failed
Please report to linux-hotp...@vger.kernel.org
==
make[3]: *** [check-TESTS] Error 1
make[2]: *** [check-am] Error 2
make[1]: *** [check-recursive] Error 1
make: *** [check] Error 2
I'm at a complete loss. Should I back up and take it from the very
beginning?
I wouldn't start over till I had exhausted all other possibilities .
Troubleshooting is often a process of elimination . An exit and
reboot now would give your host a chance to repair any possible fs
damage and e2fsck /dev/xxx of your lfs partion (prior to mounting ,of
course) would eliminate those items.
--- Mike H.---
$e2fsck /dev/sdb4
$mount /dev/sdb4 /mnt/lfs
$cd /mnt/lfs
$chown -R root:root *
then copy-paste my way through ...
#6.2. Preparing Virtual Kernel File Systems
mkdir -v $LFS/{dev,proc,sys}
mknod -m 600 $LFS/dev/console c 5 1 mknod -m 666 $LFS/dev/null c 1 3
mount -v --bind /dev $LFS/dev
mount -vt devpts devpts $LFS/dev/pts
mount -vt tmpfs shm $LFS/dev/shm
mount -vt proc proc $LFS/proc
mount -vt sysfs sysfs $LFS/sys
#6.4. Entering the Chroot Environment
chroot $LFS /tools/bin/env -i \
HOME=/root TERM=$TERM PS1='\u:\w\$ ' \
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \
/tools/bin/bash --login +h
#6.59. Udev-161
$cd /sources
tar jxf udev-161.tar.bz2
cd udev-161
tar -xvf ../udev-config-20100128.tar.bz2
tar -xvf ../udev-161-testfiles.tar.bz2 --strip-components=1
install -dv /lib/{firmware,udev/devices/{pts,shm}}
mknod -m0666 /lib/udev/devices/null c 1 3
./configure --prefix=/usr \
--sysconfdir=/etc --sbindir=/sbin \
--with-rootlibdir=/lib --libexecdir=/lib/udev \
--disable-extras --disable-introspection
make
make check
same error ...
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: udev problem
robert wrote: Neal Murphy wrote: On Tuesday 07 December 2010 04:55:43 robert wrote: unpacked udev-161.tar.bz2 cd udev-161 then copy and paste ... (the two dearchive operations are xvf??? and not jxvf??? 'tar xvf' unpacks a noncompressed tar archvie (.tar). 'tar xvfj' unpacks a bz2-compressed archive (.tar.bz2). 'tar xvfz' unpacks a gzip-compressed archive (.tar.gz, .tgz). So, I don't follow then. Instructions at 6.59. Udev-161 say: tar -xvf ../udev-config-20100128.tar.bz2 ... why not *J*xvf? When extracting, GNU tar is smart enough to recognize the compression type, if any, without being told. This capability has been in place for several years. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
Bruce Dubbs wrote: robert wrote: Neal Murphy wrote: On Tuesday 07 December 2010 04:55:43 robert wrote: unpacked udev-161.tar.bz2 cd udev-161 then copy and paste ... (the two dearchive operations are xvf??? and not jxvf??? 'tar xvf' unpacks a noncompressed tar archvie (.tar). 'tar xvfj' unpacks a bz2-compressed archive (.tar.bz2). 'tar xvfz' unpacks a gzip-compressed archive (.tar.gz, .tgz). So, I don't follow then. Instructions at 6.59. Udev-161 say: tar -xvf ../udev-config-20100128.tar.bz2 ... why not *J*xvf? When extracting, GNU tar is smart enough to recognize the compression type, if any, without being told. This capability has been in place for several years. -- Bruce Thanks. I'd examined the directories and all seemed nicely unpacked. Was just wondering if the absence of the bz2 filter was causing my udev problem. r. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
On Tuesday 07 December 2010 14:53:10 Bruce Dubbs wrote: When extracting, GNU tar is smart enough to recognize the compression type, if any, without being told. This capability has been in place for several years. Learn something new every day! I've been using the specific option for so long, it's second nature. Didn't mean to be misleading. Mayhap I encounter versions of tar that don't grok what they're reading -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
On Tue, Dec 7, 2010 at 2:07 PM, Neal Murphy neal.p.mur...@alum.wpi.edu wrote: On Tuesday 07 December 2010 14:53:10 Bruce Dubbs wrote: When extracting, GNU tar is smart enough to recognize the compression type, if any, without being told. This capability has been in place for several years. Learn something new every day! I've been using the specific option for so long, it's second nature. Didn't mean to be misleading. Mayhap I encounter versions of tar that don't grok what they're reading -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page Debian was behind the times on tar for quite some time after the other Distros had moved to the newer autodetection versions. More OT: Try extracting without the v, it's much easier to catch errors and with some packages with lots of really small files, the terminal can actually limit the speed of the extraction. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
On Tue, Dec 07, 2010 at 01:36:31PM -0600, robert wrote: So, I don't follow then. Instructions at 6.59. Udev-161 say: tar -xvf ../udev-config-20100128.tar.bz2 ... why not *J*xvf? Apart from the other responses, I can't help commenting that 'J' is not 'j'. I assume you wrote it as a capital for more emphasis, but with the last two or three releases of tar 'J' is used for xz compression (if you have xz-utils). ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
Ken Moffat wrote: On Tue, Dec 07, 2010 at 01:36:31PM -0600, robert wrote: So, I don't follow then. Instructions at 6.59. Udev-161 say: tar -xvf ../udev-config-20100128.tar.bz2 ... why not *J*xvf? Apart from the other responses, I can't help commenting that 'J' is not 'j'. I assume you wrote it as a capital for more emphasis, but with the last two or three releases of tar 'J' is used for xz compression (if you have xz-utils). ĸen yep, just emphasis. so tar Jf would de-archive bz2 and gz? That's convenient. r. In other matters, I'm setting up another machine to step thru the LFS build ... don't know what else to do. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
On Tue, Dec 07, 2010 at 05:13:19PM -0600, robert wrote:
Ken Moffat wrote:
Apart from the other responses, I can't help commenting that 'J' is
not 'j'. I assume you wrote it as a capital for more emphasis, but
with the last two or three releases of tar 'J' is used for xz
compression (if you have xz-utils).
ĸen
yep, just emphasis. so tar Jf would de-archive bz2 and gz?
That's convenient.
No, no, and thrice no!
With recent tar, 'tar -xf' and 'tar -xvf' will determine the format
of the archive, and when necessary it will use your installed bzip2,
gzip, or xz-utils to extract it.
But these recent versions use 'J' to enforce the use of xz
compression or decompression - you would normally specify this when
*creating* the archive. If the format of an existing archive doesn't
match a compression option you have *specified* ('j', 'z', or 'J')
then tar will fail to extract it.
ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: udev problem
robert wrote: Ken Moffat wrote: On Tue, Dec 07, 2010 at 01:36:31PM -0600, robert wrote: So, I don't follow then. Instructions at 6.59. Udev-161 say: tar -xvf ../udev-config-20100128.tar.bz2 ... why not *J*xvf? Apart from the other responses, I can't help commenting that 'J' is not 'j'. I assume you wrote it as a capital for more emphasis, but with the last two or three releases of tar 'J' is used for xz compression (if you have xz-utils). ĸen yep, just emphasis. so tar Jf would de-archive bz2 and gz? --xz and -J are equivalent. --bzip2 and -j are equivalent There are three types of options: long, short, and old. long: starts with two dashes short: starts with one dash old: no dashes and deprecated Some options _may_ take an argument. Such options may have at most long and short forms, they do not have old style equivalent. Old style options are also position dependent on the command line while the others are not. It doesn't make sense to mix short and old arguments. Use 'tar -xf filename' in lfs to prevent confusion. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
udev problem
6.59.1 says, in part:
Create some devices and directories that Udev cannot handle due to them
being required very early in the boot process, or by Udev itself:
$install -dv /lib/{firmware,udev/devices/{pts,shm}}
$mknod -m0666 /lib/udev/devices/null c 1 3
Does this mean, then, that I am supposed to receive the message:
FAIL: test/udev-test.pl
==
1 of 1 test failed
Please report to linux-hotp...@vger.kernel.org
==
make[3]: *** [check-TESTS] Error 1
make[2]: *** [check-am] Error 2
make[1]: *** [check-recursive] Error 1
make: *** [check] Error 2
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: udev problem
Bruce Dubbs wrote: robert wrote: Does this mean, then, that I am supposed to receive the message: FAIL: test/udev-test.pl Do you have the filesystems mounted in the chroot environment? (Section 6.2.3) -- Bruce yes, in chroot environment. when I de-archive the bz2 files, they unpack with ownership set to 2702:100 ... is this normal? just went back and stepped through 6.2.3 ... same result. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev problem
On Mon, Dec 06, 2010 at 08:39:13PM -0600, robert wrote: Bruce Dubbs wrote: robert wrote: Does this mean, then, that I am supposed to receive the message: FAIL: test/udev-test.pl Do you have the filesystems mounted in the chroot environment? (Section 6.2.3) -- Bruce yes, in chroot environment. when I de-archive the bz2 files, they unpack with ownership set to 2702:100 ... is this normal? just went back and stepped through 6.2.3 ... same result. -- The ownership is not important as root user; I just uppacked the files and I have 2702:users and users gid is 100. The only thing I can think of that might be helpful is to ensure that /dev is still populated from the bind mount and virtual fs from Chapter 6.2 are still present. Mike H.- -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: help with udev problem
2008/4/2, [EMAIL PROTECTED] [EMAIL PROTECTED]: Greetings,On Wednesday 02 April 2008 09:30:12 you wrote: You probably forgot to mount /dev/pts. Add to /etc/fstab: devpts /dev/pts devpts gid=4,mode=620 0 0 /dev/shm seems to be automatically created on my system. Maybe you missed a kernel option? thanks for your suggestion, but I already had the above line and the corresponding line for /dev/shm in /etc/fstab.Ax regards kernel support, I recompiled the kernel and now include automatic kernel loading which was missing but it made no difference. if anyone on this list knows of a specific kernel option required, please let me know.as before helpful suggestions will be appreciated.sincerelyblux I remember /dev/pts is for secure shells or something like that. There is a kernel option for that. But do you use the correct bootscripts? The default udev configuration should work. Have you installed the default rules? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: help with udev problem
On Thursday 03 April 2008 13:59:20 Wilco Beekhuizen wrote: I remember /dev/pts is for secure shells or something like that. There is a kernel option for that. But do you use the correct bootscripts? The default udev configuration should work. Have you installed the default rules?it was a problem with udev-1.1.3 installation. I fixed it and it now works correctly. Thanks for your help.blux __ Get up to 33% off Norton Security from Tiscali - http://www.tiscali.co.uk/securepc -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: help with udev problem
2008/4/2, [EMAIL PROTECTED] [EMAIL PROTECTED]: Greetings,I seem to have a problem with udev with an LFS build I did in January. I used kernel-2.6.23.12 (then development lfs).I get to boot prompt but the booting reports:mount: mount point /dev/pts does not existmount: mount point /dev/shm does not existhelp will be appreciatedblux You probably forgot to mount /dev/pts. Add to /etc/fstab: devpts /dev/pts devpts gid=4,mode=620 0 0 /dev/shm seems to be automatically created on my system. Maybe you missed a kernel option? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: help with udev problem
Greetings,On Wednesday 02 April 2008 09:30:12 you wrote: You probably forgot to mount /dev/pts. Add to /etc/fstab: devpts /dev/pts devpts gid=4,mode=620 0 0 /dev/shm seems to be automatically created on my system. Maybe you missed a kernel option? thanks for your suggestion, but I already had the above line and the corresponding line for /dev/shm in /etc/fstab.Ax regards kernel support, I recompiled the kernel and now include automatic kernel loading which was missing but it made no difference. if anyone on this list knows of a specific kernel option required, please let me know.as before helpful suggestions will be appreciated.sincerelyblux __ Get up to 33% off Norton Security from Tiscali - http://www.tiscali.co.uk/securepc -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
help with udev problem
Greetings,I seem to have a problem with udev with an LFS build I did in January. I used kernel-2.6.23.12 (then development lfs).I get to boot prompt but the booting reports:mount: mount point /dev/pts does not existmount: mount point /dev/shm does not existhelp will be appreciatedblux __ Protect children against online threats - http://www.tiscali.co.uk/protection -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
