Re: diskless boot /usr/local/etc/rc.d/ scripts do not run, why?
On Thu, Feb 01, 2007 at 11:23:23AM +0900, Artem Kazakov wrote: Hello everyone, I'm using 6-stable on 4 amd64 machines. One of them has FreeBSD on its local hard drive and others are booted via network with PXE. But I encounter that /usr/local/etc/rc.d/* are not executed during the boot process? Is there some kind of option to change this? Or may be I misconfigured something ? If you boot diskless and /usr or /usr/local is a seperate NFS mount you must adjust the value of the rc.conf(5) variable early_late_divider for your scripts to be processed. See the rc.conf manpage for details. Also, I do not see any messages on console after kernel is loaded into memory. The next thing I see is login: prompt. How to turn on boot messages for network booted machines. I have to say that I use this loader.rc for network boot: load /boot/kernel/kernel echo \007\007 set console=vidconsole autoboot Do you by chance have a /boot.config? It sounds like your system is probably running on a serial console. -- Brooks pgph8SbxqASSf.pgp Description: PGP signature
Re: unique hardware identification
In message: [EMAIL PROTECTED] Peter Jeremy [EMAIL PROTECTED] writes: : On Sun, 2007-Jan-28 10:39:36 -0600, Jon Passki wrote: : If the machine is a PXE-compliant device [2], it should have a GUID/ : UUID [1] available. This can be exposed by sysutil/hal [3] via the : smbios.system.uuid field. : : You can also get it via kenv(8) without needing any ports: : # kenv smbios.system.uuid : 9F345F4F-BEFC-D431-1340-61235A56DEF9 I wonder why the smbios stuff isn't exported via sysctls as well... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: a question regarding sys/shm.h
In message: [EMAIL PROTECTED]
Fabian Keil [EMAIL PROTECTED] writes:
: Robert Watson [EMAIL PROTECTED] wrote:
:
: On Wed, 31 Jan 2007, Dag-Erling Smørgrav wrote:
:
: Pascal Hofstee [EMAIL PROTECTED] writes:
: Any additional sugestions/objections are always greatly appreciated.
:
: On 32-bit platforms (i386, powerpc), int is a 32-bit signed integer while
: size_t is a 32-bit unsigned integer.
:
: On 64-bit platforms (amd64, sparc64 etc), int is a 32-bit signed integer
: while size_t is a 64-bit unsigned integer.
:
: In both cases, changing this structure member from int to size_t will
break
: the ABI.
:
: This doesn't mean you shouldn't do it, just that it should be done with
: care.
:
: If we do decide to go ahead with the ABI change, there are a number of
other
: things that should be done simultaneously, such as changing the uid and gid
: fields to uid_t and gid_t.
:
: struct tm's members could be changed as well.
struct tm doesn't have a member that's tv_sec.
Maybe you mean struct timeval and struct timespec?
: Quoting a response I got from Juliusz Chroboczek
: (the author of Polipo) after reporting a compiler
: warning:
:
: |By the way, IEEE 1003.1-2003 says that tv_sec should be a time_t,
: |hence by making it a long, FreeBSD and NetBSD are violating the POSIX
: |standard. Could you please file a bug report with them?
:
: I didn't find any claims about FreeBSD being IEEE 1003.1-2003
: compliant and therefore didn't consider it a bug, but given that
: the topic is *_t changes and time_t hasn't come up yet,
: I'd like to mention it anyway.
I think this is already fixed:
/*
* Structure returned by gettimeofday(2) system call, and used in other calls.
*/
struct timeval {
time_t tv_sec; /* seconds */
suseconds_t tv_usec;/* and microseconds */
};
as is timespec:
struct timespec {
time_t tv_sec; /* seconds */
longtv_nsec;/* and nanoseconds */
};
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: a question regarding sys/shm.h
M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] Fabian Keil [EMAIL PROTECTED] writes: : Robert Watson [EMAIL PROTECTED] wrote: : If we do decide to go ahead with the ABI change, there are a number of other : things that should be done simultaneously, such as changing the uid and gid : fields to uid_t and gid_t. : : struct tm's members could be changed as well. struct tm doesn't have a member that's tv_sec. Maybe you mean struct timeval and struct timespec? I did indeed. Sorry for the noise. Fabian signature.asc Description: PGP signature
Re: unique hardware identification
On Thu, Feb 01, 2007 at 11:38:51AM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Peter Jeremy [EMAIL PROTECTED] writes: : On Sun, 2007-Jan-28 10:39:36 -0600, Jon Passki wrote: : If the machine is a PXE-compliant device [2], it should have a GUID/ : UUID [1] available. This can be exposed by sysutil/hal [3] via the : smbios.system.uuid field. : : You can also get it via kenv(8) without needing any ports: : # kenv smbios.system.uuid : 9F345F4F-BEFC-D431-1340-61235A56DEF9 I wonder why the smbios stuff isn't exported via sysctls as well... and this is probably a lazy vendor :) smbios.bios.reldate=07/12/2006 smbios.bios.vendor=American Megatrends Inc. smbios.bios.version=P1.10 smbios.chassis.maker=To Be Filled By O.E.M. smbios.chassis.serial=To Be Filled By O.E.M. smbios.chassis.tag=To Be Filled By O.E.M. smbios.chassis.version=To Be Filled By O.E.M. smbios.planar.maker= smbios.planar.product=775i945GZ smbios.planar.serial= smbios.planar.version= smbios.socket.enabled=1 smbios.socket.populated=1 smbios.system.maker=To Be Filled By O.E.M. smbios.system.product=775i945GZ smbios.system.serial=To Be Filled By O.E.M. smbios.system.uuid=00020003-0004-0005-0006-000700080009 smbios.system.version=To Be Filled By O.E.M. cheers luigi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unique hardware identification
In message: [EMAIL PROTECTED] Luigi Rizzo [EMAIL PROTECTED] writes: : On Thu, Feb 01, 2007 at 11:38:51AM -0700, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Peter Jeremy [EMAIL PROTECTED] writes: : : On Sun, 2007-Jan-28 10:39:36 -0600, Jon Passki wrote: : : If the machine is a PXE-compliant device [2], it should have a GUID/ : : UUID [1] available. This can be exposed by sysutil/hal [3] via the : : smbios.system.uuid field. : : : : You can also get it via kenv(8) without needing any ports: : : # kenv smbios.system.uuid : : 9F345F4F-BEFC-D431-1340-61235A56DEF9 : : I wonder why the smbios stuff isn't exported via sysctls as well... : : and this is probably a lazy vendor :) : : smbios.bios.reldate=07/12/2006 : smbios.bios.vendor=American Megatrends Inc. : smbios.bios.version=P1.10 : smbios.chassis.maker=To Be Filled By O.E.M. : smbios.chassis.serial=To Be Filled By O.E.M. : smbios.chassis.tag=To Be Filled By O.E.M. : smbios.chassis.version=To Be Filled By O.E.M. : smbios.planar.maker= : smbios.planar.product=775i945GZ : smbios.planar.serial= : smbios.planar.version= : smbios.socket.enabled=1 : smbios.socket.populated=1 : smbios.system.maker=To Be Filled By O.E.M. : smbios.system.product=775i945GZ : smbios.system.serial=To Be Filled By O.E.M. : smbios.system.uuid=00020003-0004-0005-0006-000700080009 : smbios.system.version=To Be Filled By O.E.M. Heh! My comment though is why do we have to go to kenv when we could export these via sysctl, like everything else. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysctl(3) interface
At about the time of 1/31/2007 2:10 AM, Dag-Erling Smørgrav stated the following: Daniel Rudy [EMAIL PROTECTED] writes: I've been taking apart and analyzing the sysctl(8) program to gain a better insight into how to use the sysctl(3) interface. [...] It's using an oid of 0 and 2 to get something, then it comes up with 440 and then a sequence of numbers that are incrementing in a peculiar pattern. sysctl(8) uses undocumented interfaces to a) enumerate the nodes in the sysctl tree and b) obtain the name of a node, given its OID. So, my question is, how do I walk the tree to get the PnP info for all the devices in the system? man 3 devinfo DES A little too late since I already hacked the source for sysctl(8) and figured out how it works. Here's what I have: mib[0] = 0; Unused according to sys/sysctl.h. So, 0,1 - get name from oid. 0,2 - get first sysctl node/leaf? (I haven't used this one yet) 0,3 - get oid from name. 0,4 - get format for oid? (I haven't used this one yet either) At least that's that I have. I wrote a program based on that and it does work, quite well in fact. I am not concerned about portability since the software that I'm writing will run ONLY on FreeBSD and maybe some of the variants. -- Daniel Rudy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unique hardware identification
At about the time of 2/1/2007 11:40 AM, M. Warner Losh stated the following: In message: [EMAIL PROTECTED] Luigi Rizzo [EMAIL PROTECTED] writes: : On Thu, Feb 01, 2007 at 11:38:51AM -0700, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Peter Jeremy [EMAIL PROTECTED] writes: : : On Sun, 2007-Jan-28 10:39:36 -0600, Jon Passki wrote: : : If the machine is a PXE-compliant device [2], it should have a GUID/ : : UUID [1] available. This can be exposed by sysutil/hal [3] via the : : smbios.system.uuid field. : : : : You can also get it via kenv(8) without needing any ports: : : # kenv smbios.system.uuid : : 9F345F4F-BEFC-D431-1340-61235A56DEF9 : : I wonder why the smbios stuff isn't exported via sysctls as well... : : and this is probably a lazy vendor :) : : smbios.bios.reldate=07/12/2006 : smbios.bios.vendor=American Megatrends Inc. : smbios.bios.version=P1.10 : smbios.chassis.maker=To Be Filled By O.E.M. : smbios.chassis.serial=To Be Filled By O.E.M. : smbios.chassis.tag=To Be Filled By O.E.M. : smbios.chassis.version=To Be Filled By O.E.M. : smbios.planar.maker= : smbios.planar.product=775i945GZ : smbios.planar.serial= : smbios.planar.version= : smbios.socket.enabled=1 : smbios.socket.populated=1 : smbios.system.maker=To Be Filled By O.E.M. : smbios.system.product=775i945GZ : smbios.system.serial=To Be Filled By O.E.M. : smbios.system.uuid=00020003-0004-0005-0006-000700080009 : smbios.system.version=To Be Filled By O.E.M. Heh! My comment though is why do we have to go to kenv when we could export these via sysctl, like everything else. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] You know that's a good idea, but there is a problem with that None of this stuff appears on my system and I'm running 6.1. I can't even find dmidump anywhere on the system or in ports either. -- Daniel Rudy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: diskless boot /usr/local/etc/rc.d/ scripts do not run, why?
Hi, Brooks! Thanks for the advice, it helped! I have to say that I use this loader.rc for network boot: load /boot/kernel/kernel echo \007\007 set console=vidconsole autoboot Do you by chance have a /boot.config? It sounds like your system is probably running on a serial console. I do not have boot.config and that machine has vga card and keyboard and etc. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unique hardware identification
On Thu, 2007-Feb-01 21:49:43 -0800, Daniel Rudy wrote: None of this stuff appears on my system and I'm running 6.1. I can't even find dmidump anywhere on the system or in ports either. Please elaborate. kenv(8) states that it first appeared in 4.1.1 and I don't recall seeing any reference to 'dmidump' in this thread. If you're referring to getting smbios data reported in kenv - that is up to your system/BIOS vendor: If they don't embed the information in the BIOS, FreeBSD can't report it. The response on my laptop is complete. My older whitebox desktops either don't have the data populated or don't report it at all. -- Peter Jeremy pgpmFjOmTnU2t.pgp Description: PGP signature
Re: unique hardware identification
--ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 2007-Feb-01 21:49:43 -0800, Daniel Rudy wrote: None of this stuff appears on my system and I'm running 6.1. I can't even find dmidump anywhere on the system or in ports either. Please elaborate. kenv(8) states that it first appeared in 4.1.1 and I don't recall seeing any reference to 'dmidump' in this thread. If you're referring to getting smbios data reported in kenv - that is up to your system/BIOS vendor: If they don't embed the information in the BIOS, FreeBSD can't report it. The response on my laptop is complete. My older whitebox desktops either don't have the data populated or don't report it at all. kenv appeared in 4.1, the smbios. stuff only appeared midway in 6.1 danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
