Re: [Testers wanted] /dev/console cleanups
Jeremy Chadwick [EMAIL PROTECTED] writes: Peter Jeremy [EMAIL PROTECTED] writes: This is deliberate. If the system panics, stuff that was in the message buffer (and might not be on disk) can be read when the system reboots. If there is no crashdump, this might be the only record of what happened. That doesn't sound deliberate at all -- it sounds like a quirk that people (you?) are relying on. No, it is deliberate. Just because you don't like it doesn't mean we're morons. You're under the mentality that the information is *always* available after a panic/reboot -- it isn't. I have 4 different Supermicro motherboards (all from different years) which will most of the time lose the msgbuf after rebooting from single-user -- but sometimes the msgbuf is retained. And no, bad hardware is not responsible for the randomness of the problem. We know there are systems where it doesn't work. That doesn't mean it's not useful when it *does* work. There are also systems where it works reliably, including most SoC and SFF systems. I think it's been discussed in the past how/why this can happen. It has to do with what each BIOS manufacturer chooses to do with some parts of memory during start-up. Mostly whether memory remains powered-on through the reset process. Speaking only of i386 / amd64 systems, there are several ways to reboot a computer: - Return to real mode and call the BIOS reboot subroutine. This will perform a cold boot (memory is cleared) or a warm boot (memory should not be cleared, but the BIOS may do so anyway) depending on the value stored at a specific location in memory. - On systems with an i8042 keyboard controller, one of the controller's output lines is usually wired to the CPU's reset pin. Writing a specific value to one of the keyboard controller's control registers causes it to pull that pin low. - Triple fault: set up an empty interrupt descriptor table and trigger an interrupt (e.g. divide by zero). The CPU will fail to invoke the corresponding interrupt descriptor, causing a double fault interrupt, which will fail to execute, causing a CPU reset. The latter two techniques can be used (and *have* been used) to switch back from protected mode to real mode, because they are faster than the documented method. Memory is *not* cleared, and the CPU will start executing whatever code is stored at 0xfff0 in real memory; this is normally a far jump into the BIOS reboot subroutine, so if you don't pull any tricks (e.g. jump to your own code that does whatever it was you needed to do in real mode, then return to protected mode), they are equivalent to the first technique. - ACPI reset: store the value specified by RESET_VALUE in the FADT into the register specified by RESET_REG in the FADT. According to the ACPI spec, this results in a cold boot. However, this part of the spec is optional, so not all motherboards support it. FreeBSD will only use ACPI reset if the hw.acpi.handle_reboot sysctl is not zero, which it is by default (mostly, if I recall correctly, because ACPI reset is unreliable). DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Testers wanted] /dev/console cleanups
On Wed, Nov 19, 2008 at 11:48:36PM -0800, Nate Eldredge wrote: On Wed, 19 Nov 2008, Jeremy Chadwick wrote: On Thu, Nov 20, 2008 at 05:39:36PM +1100, Peter Jeremy wrote: I hope that never gets committed - it will make debugging kernel problems much harder. There is already a kern.msgbuf_clear sysctl and maybe people who are concerned about msgbuf leakage need to learn to use it. And this sysctl is only usable *after* the kernel loads, which means you lose all of the messages shown from the time the kernel loads to the time the sysctl is set (e.g. hardware detected/configured). This is even less acceptable, IMHO. But surely you can arrange that the contents are written out to /var/log/messages first? E.g. a sequence like - mount /var - write buffer contents via syslogd - clear buffer via sysctl - allow user logins This has two problems, but I'm probably missing something: 1) See my original post, re: users of our systems use dmesg to find out what the status of the system is. By status I don't mean from the point the kernel finished to now, I literally mean they *expect* to see the kernel device messages and all that jazz. No, I'm not making this up, nor am I arguing just to hear myself talk (despite popular belief). I can bring these users into the discussion if people feel it would be useful. 2) I don't understand how this would work (meaning, technically and literally: I do not understand). How do messages like CPU: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (2992.52-MHz K8-class CPU) get written to syslog when syslogd isn't even running (or any filesystems) mounted at that time? There must be some magic involved there (since syslog == libc, not syscall) when syslogd starts, but I don't know how it works. This way the buffer is cleared before any unprivileged users get to do anything. No kernel changes needed, just a little tweaking of the init scripts at most. If you should have a crash and suspect there is useful data in the buffer, you can boot to single-user mode (avoiding the clear) and retrieve it manually. Seems like this should make everyone happy. What I'm not understanding is the resistance towards Rink's patch, assuming the tunable defaults to disabled/off. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Testers wanted] /dev/console cleanups
On Thu, Nov 20, 2008 at 10:53:07AM +0100, Dag-Erling Smørgrav wrote: Jeremy Chadwick [EMAIL PROTECTED] writes: Peter Jeremy [EMAIL PROTECTED] writes: This is deliberate. If the system panics, stuff that was in the message buffer (and might not be on disk) can be read when the system reboots. If there is no crashdump, this might be the only record of what happened. That doesn't sound deliberate at all -- it sounds like a quirk that people (you?) are relying on. No, it is deliberate. Just because you don't like it doesn't mean we're morons. I said nothing about liking/disliking it, nor did I namecall or condescend. Thanks for being a complete prick, des. Jesus christ... -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Testers wanted] /dev/console cleanups
On Thu, 20 Nov 2008, Jeremy Chadwick wrote: On Wed, Nov 19, 2008 at 11:48:36PM -0800, Nate Eldredge wrote: On Wed, 19 Nov 2008, Jeremy Chadwick wrote: On Thu, Nov 20, 2008 at 05:39:36PM +1100, Peter Jeremy wrote: I hope that never gets committed - it will make debugging kernel problems much harder. There is already a kern.msgbuf_clear sysctl and maybe people who are concerned about msgbuf leakage need to learn to use it. And this sysctl is only usable *after* the kernel loads, which means you lose all of the messages shown from the time the kernel loads to the time the sysctl is set (e.g. hardware detected/configured). This is even less acceptable, IMHO. But surely you can arrange that the contents are written out to /var/log/messages first? E.g. a sequence like - mount /var - write buffer contents via syslogd - clear buffer via sysctl - allow user logins This has two problems, but I'm probably missing something: 1) See my original post, re: users of our systems use dmesg to find out what the status of the system is. By status I don't mean from the point the kernel finished to now, I literally mean they *expect* to see the kernel device messages and all that jazz. No, I'm not making this up, nor am I arguing just to hear myself talk (despite popular belief). I can bring these users into the discussion if people feel it would be useful. I forgot about that point. I can sympathize with those users; I feel the same way. It's a good way to learn about a system as a mere user (since usually sysadmins don't remember or bother to disable it). However, in my experience dmesg isn't really the best thing for that purpose; the kernel message buffer tends to get wiped out once the system has been up for a while. (It fills with ipfw logs, ethernet link state changes, etc.) Maybe a better approach would be to point them to /var/log/messages or whichever log file stores them permanently. Or, better yet, do some syslogd magic to make a logfile that can be appropriately readable but doesn't have any overly sensitive messages directed there (e.g. kernel yes, sshd no). 2) I don't understand how this would work (meaning, technically and literally: I do not understand). How do messages like CPU: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (2992.52-MHz K8-class CPU) get written to syslog when syslogd isn't even running (or any filesystems) mounted at that time? There must be some magic involved there (since syslog == libc, not syscall) when syslogd starts, but I don't know how it works. I think you're conflating a couple of things, and I also explained my idea poorly. As I understand it (from memory, which is a little vague), syslogd gets messages from two places: from the kernel via /dev/klog, and from other processes via a Unix domain socket in /var/run. These messages then get sent to the appropriate log files. The syslog(3) function of libc just connects and writes the message to the Unix domain socket. If syslogd isn't running to listen on that socket, syslog(3) won't work very well. Now /dev/klog should be a direct line to the kernel's message buffer. So when syslogd starts and reads /dev/klog for the first time, it will get everything that's accumulated so far, including the earliest boot messages. It should then write them to the appropriate log files. This already works, which is why /var/log/messages contains the kernel copyright message, etc. My idea is, after syslogd does this, but before the system goes multi-user, you should clear the kernel buffer. Early boot messages are already in the log files, so they won't be lost. Maybe the best thing would be to build this functionality into syslogd itself, to minimize the possibility of losing messages due to a race. This way the buffer is cleared before any unprivileged users get to do anything. No kernel changes needed, just a little tweaking of the init scripts at most. If you should have a crash and suspect there is useful data in the buffer, you can boot to single-user mode (avoiding the clear) and retrieve it manually. Seems like this should make everyone happy. What I'm not understanding is the resistance towards Rink's patch, assuming the tunable defaults to disabled/off. It seems reasonable to me. The only catch I can see is that if you have a crash and you want to look at the message buffer after rebooting, you'll have to remember to stop at the loader prompt and turn off that tunable. Which might be easy to forget in the heat of the moment. -- Nate Eldredge [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: build problems with gptzfsboot (AMD64) 8.0-CURRENT
On Thu, 20 Nov 2008 01:46:31 - Pegasus Mc Cleaft [EMAIL PROTECTED] wrote: Hi everyone, I am having difficulties rebuilding the world after some patches were made today. I was wondering if anyone else is experiencing the same troubles? ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x0 -o gptzfsboot.out /usr/obj/usr/src/sys/boot/i386/gptzfsboot/../btx/lib/crt0.o zfsboot.o sio.o gptzfsboot.o ld: gptzfsboot.o: No such file: No such file or directory *** Error code 1 Stop in /usr/src/sys/boot/i386/gptzfsboot. *** Error code 1 I am experiencing the exact same problem with a fresh svn checkout -- Pascal Hofstee ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Reccomendation for tools to use on FreeBSD for a wiki ?
On Wed, 19 Nov 2008 18:24:21 +0100, Julian Stacey [EMAIL PROTECTED] wrote: Hi hackers, Maybe Some of you might suggest some software I might install, Wiki I guess. ? I got zero response from ports@, I could use some reccomendations please. PS From http://wiki.freebsd.org/HelpContents I tried cd /usr/ports/www ; vi *iki*/pkg-descr or is /usr/ports/www/moinmoin the way to go ? Thanks. --- Subject: Reccomendation for ports for web based club events forthcoming diary ? Can anyone reccomend some ports to install on a FreeBSD web server, for a club of mostly non technical people, to support: - All club members can add events to a forthcoming calendar, - All club members can request server to prepare a listing of next next upcoming events, to download (probably in PDF, or perhaps tbl to a pipe or ? - A list of moderators can delete fake events from robots the malicious. - Preferably moderators should not themselves be capable of deleting logged event submission, but only capable of deleting events formatted to the ouput printable programme sheet. (To autopsy for suspect rogue moderators) - I guess first entry criteria might be a fuzzy picture for human to decode password from). 2nd might be mail return for confirm password, - 3rd, A majordomo (later mailman) maintained list of club members moderators etc is available for automated validation. - I hope there will be some packages available, http probably wiki based etc, that will come close enough ? Hi Julian, I have been working with `OddMuse' in the EmacsWiki[1] as a user and as an admin/moderator in some installations of my own. The UI of the wiki is pretty simple, and it does have a very low level of requirements for becoming a `wiki editor', so it may be a good choice for a Wiki where non-technical people produce a lot of the content. OddMuse does have a relatively _unique_ way of treating Wiki content and may require a bit of Perl hackery to configure captchas, but I like the fact that it is basically a relatively small `wiki core' that is fairly trivial to extend by writing Perl modules. See http://www.oddmuse.org/cgi-bin/oddmuse for more details about the OddMuse wiki engine. Wikipedia has a list of other Wiki software at http://en.wikipedia.org/wiki/List_of_wiki_software that may also be useful. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Testers wanted] /dev/console cleanups
On Nov 20, 2008, at 4:03 AM, Jeremy Chadwick wrote: This has two problems, but I'm probably missing something: 1) See my original post, re: users of our systems use dmesg to find out what the status of the system is. By status I don't mean from the point the kernel finished to now, I literally mean they *expect* to see the kernel device messages and all that jazz. No, I'm not making this up, nor am I arguing just to hear myself talk (despite popular belief). I can bring these users into the discussion if people feel it would be useful. Sorry for jumping in late, but... cat /var/run/dmesg.boot Is that acceptable? I know it depends on what end users want, but some of my old hosting customers really just wanted to see the specs of the box and nothing else. Making dmesg a shell script that just cats that file satisfied everyone who asked. Also: On Thu, Nov 20, 2008 at 05:39:36PM +1100, Peter Jeremy wrote: On 2008-Nov-19 02:47:31 -0800, Jeremy Chadwick [EMAIL PROTECTED] wrote: There's a known issue with the kernel message buffer though: it's not NULL'd out upon reboot. This is deliberate. If the system panics, stuff that was in the message buffer (and might not be on disk) can be read when the system reboots. If there is no crashdump, this might be the only record of what happened. That doesn't sound deliberate at all -- it sounds like a quirk that people (you?) are relying on. I do not think any piece of the FreeBSD system (e.g. savecore, etc.) relies on this behaviour. You're under the mentality that the information is *always* available after a panic/reboot -- it isn't. I have 4 different Supermicro motherboards (all from different years) which will most of the time lose the msgbuf after rebooting from single-user -- but sometimes the msgbuf is retained. And no, bad hardware is not responsible for the randomness of the problem. I think it's been discussed in the past how/why this can happen. It has to do with what each BIOS manufacturer chooses to do with some parts of memory during start-up. I'm sure the Quick Boot (e.g. no extensive memory test, which really doesn't test anything these days) option plays a role, and that option is enabled by default on all motherboards I've used in the past 10 years. I've been involved with a few embedded systems, some BSD based some not. In a few cases we've used custom BIOSes on the motherboard. At least one BIOS SDK specifically describes this as a feature. What is exposed to the end user as Quick Boot is actually several options that the motherboard designer/BIOS configurer can select. One of which is specifying which chunks of memory should be preserved after a reboot, up to memory tests should be as non-destructive as possible. While you can't *rely* on it, with careful use of atomic writes and state checking you can pick up where you left off after a reboot on an embedded device that has no long-term storage if it was a warm boot. Or, gathering crash dumps and sending them off to the network. Here, the dmesg buffer is a simple ring buffer in the kernel. The start/end pointers and contents of the ring buffer are deliberately not cleared after a reboot in FreeBSD to at least make the information available if the BIOS didn't clobber it. This can be extremely useful in those a box on the other side of the world keeps rebooting with no panic, if you can tell the BIOS to skip the memory check. In one case I even (ab)used some extra video ram on the motherboard as a dmesg buffer since the video bios didn't wipe it on boot, but the system's bios insisted on doing a full memory test each time. If you have a BIOS that's sometimes but not always wiping the buffer, it's probably because a few bits are being lost while the motherboard turns the DRAM refresh off during the reboot. Some DIMMS can handle no refresh for tens of seconds, some start popping bit errors rather quickly. Take a look at sys/kern/subr_msgbuf.c:msgbuf_reinit. There's a magic number it looks for as well as a checksum on the whole buffer that's updated after every write. If anything changes, the kernel throws out the whole buffer and starts fresh. If you boot with -v you'll probably see msgbuf cksum mismatch. While I don't think any of the shipping FreeBSD tools rely on this behavior, I know I tried submitting a patch back in the FreeBSD-2.2(?) days to fix that overlooked uninitialized buffer and got educated by jkh pretty quickly. :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Testers wanted] /dev/console cleanups
On November 20, 2008 02:42 am Nate Eldredge wrote: On Thu, 20 Nov 2008, Jeremy Chadwick wrote: On Wed, Nov 19, 2008 at 11:48:36PM -0800, Nate Eldredge wrote: On Wed, 19 Nov 2008, Jeremy Chadwick wrote: On Thu, Nov 20, 2008 at 05:39:36PM +1100, Peter Jeremy wrote: I hope that never gets committed - it will make debugging kernel problems much harder. There is already a kern.msgbuf_clear sysctl and maybe people who are concerned about msgbuf leakage need to learn to use it. And this sysctl is only usable *after* the kernel loads, which means you lose all of the messages shown from the time the kernel loads to the time the sysctl is set (e.g. hardware detected/configured). This is even less acceptable, IMHO. But surely you can arrange that the contents are written out to /var/log/messages first? E.g. a sequence like - mount /var - write buffer contents via syslogd - clear buffer via sysctl - allow user logins This has two problems, but I'm probably missing something: 1) See my original post, re: users of our systems use dmesg to find out what the status of the system is. By status I don't mean from the point the kernel finished to now, I literally mean they *expect* to see the kernel device messages and all that jazz. No, I'm not making this up, nor am I arguing just to hear myself talk (despite popular belief). I can bring these users into the discussion if people feel it would be useful. I forgot about that point. I can sympathize with those users; I feel the same way. It's a good way to learn about a system as a mere user (since usually sysadmins don't remember or bother to disable it). However, in my experience dmesg isn't really the best thing for that purpose; the kernel message buffer tends to get wiped out once the system has been up for a while. (It fills with ipfw logs, ethernet link state changes, etc.) Maybe a better approach would be to point them to /var/log/messages or whichever log file stores them permanently. I think what you are looking for is /var/run/dmesg.boot, which stores just the dmesg info from the initial boot. Nothing gets logged to this after the boot is complete. This file has been a life saver quite a few times since I discovered it, and is something I really miss when working with mis-behaving Linux systems. -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Reccomendation for tools to use on FreeBSD for a wiki ?
Hi, Will you tell us which one you selected? Happy to, when I know which why, likely it'll be a while before that. Just an unpaid hobby, not spending 8 hours/day on selection/install tuning. Whether then I'll remember to post, or you'll want to remind me, we'll see :-) PS I started with /usr/ports/www/moinmoin as that's what wiki.freebs.org uses, then I seitched to CGI not FCGI option as it sounded easier. Then I saw post by Giogios need to think about that. Thanks Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML Base64 text are spam. www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: build problems with gptzfsboot (AMD64) 8.0-CURRENT
What is your MACHINE_ARCH ? Mine is amd64, I think there's a problem with the conditional in sys/boot/i386/gptzfsboot/Makefile. ld doesn't need gptzfsboot.o on i386. Olivier 2008/11/20 Olivier SMEDTS [EMAIL PROTECTED]: 2008/11/20 Pascal Hofstee [EMAIL PROTECTED]: On Thu, 20 Nov 2008 01:46:31 - Pegasus Mc Cleaft [EMAIL PROTECTED] wrote: Hi everyone, I am having difficulties rebuilding the world after some patches were made today. I was wondering if anyone else is experiencing the same troubles? ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x0 -o gptzfsboot.out /usr/obj/usr/src/sys/boot/i386/gptzfsboot/../btx/lib/crt0.o zfsboot.o sio.o gptzfsboot.o ld: gptzfsboot.o: No such file: No such file or directory *** Error code 1 Stop in /usr/src/sys/boot/i386/gptzfsboot. *** Error code 1 I am experiencing the exact same problem with a fresh svn checkout Just my me too. I did not experience the problem 24 hours ago (after ZFS version 13 update and zfsboot import). -- Pascal Hofstee ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: [EMAIL PROTECTED]- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: [EMAIL PROTECTED]- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: build problems with gptzfsboot (AMD64) 8.0-CURRENT
2008/11/20 Pascal Hofstee [EMAIL PROTECTED]: On Thu, 20 Nov 2008 01:46:31 - Pegasus Mc Cleaft [EMAIL PROTECTED] wrote: Hi everyone, I am having difficulties rebuilding the world after some patches were made today. I was wondering if anyone else is experiencing the same troubles? ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x0 -o gptzfsboot.out /usr/obj/usr/src/sys/boot/i386/gptzfsboot/../btx/lib/crt0.o zfsboot.o sio.o gptzfsboot.o ld: gptzfsboot.o: No such file: No such file or directory *** Error code 1 Stop in /usr/src/sys/boot/i386/gptzfsboot. *** Error code 1 I am experiencing the exact same problem with a fresh svn checkout Just my me too. I did not experience the problem 24 hours ago (after ZFS version 13 update and zfsboot import). -- Pascal Hofstee ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: [EMAIL PROTECTED]- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: build problems with gptzfsboot (AMD64) 8.0-CURRENT
2008/11/20 Olivier SMEDTS [EMAIL PROTECTED]:
2008/11/20 Pascal Hofstee [EMAIL PROTECTED]:
On Thu, 20 Nov 2008 01:46:31 -
Pegasus Mc Cleaft [EMAIL PROTECTED] wrote:
Hi everyone,
I am having difficulties rebuilding the world after some patches
were made today. I was wondering if anyone else is experiencing the
same troubles?
ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x0 -o
gptzfsboot.out /usr/obj/usr/src/sys/boot/i386/gptzfsboot/../btx/lib/crt0.o
zfsboot.o sio.o gptzfsboot.o ld: gptzfsboot.o: No such file: No such
file or directory *** Error code 1
Stop in /usr/src/sys/boot/i386/gptzfsboot.
*** Error code 1
I am experiencing the exact same problem with a fresh svn checkout
Just my me too.
I did not experience the problem 24 hours ago (after ZFS version 13
update and zfsboot import).
That's it. Seems to work with the following patch :
--- sys/boot/i386/gptzfsboot/Makefile.orig 2008-11-20
19:58:45.0 +0100
+++ sys/boot/i386/gptzfsboot/Makefile 2008-11-20 20:01:53.0 +0100
@@ -65,7 +65,7 @@
zfsboot.o: ${.CURDIR}/../../zfs/zfsimpl.c
.if ${MACHINE_ARCH} == amd64
-beforedepend gptzfsboot.o: machine
+beforedepend gptzfsboot.bin: machine
CLEANFILES+= machine
machine:
ln -sf ${.CURDIR}/../../../i386/include machine
I've cc'ed current@ because HEAD is broken on amd64 for now.
Cheers,
Olivier
--
Pascal Hofstee
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Olivier Smedts _
ASCII ribbon campaign ( )
e-mail: [EMAIL PROTECTED]- against HTML email vCards X
www: http://www.gid0.org- against proprietary attachments / \
Il y a seulement 10 sortes de gens dans le monde :
ceux qui comprennent le binaire,
et ceux qui ne le comprennent pas.
--
Olivier Smedts _
ASCII ribbon campaign ( )
e-mail: [EMAIL PROTECTED]- against HTML email vCards X
www: http://www.gid0.org- against proprietary attachments / \
Il y a seulement 10 sortes de gens dans le monde :
ceux qui comprennent le binaire,
et ceux qui ne le comprennent pas.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: build problems with gptzfsboot (AMD64) 8.0-CURRENT
2008/11/20 Olivier SMEDTS [EMAIL PROTECTED]:
2008/11/20 Olivier SMEDTS [EMAIL PROTECTED]:
2008/11/20 Pascal Hofstee [EMAIL PROTECTED]:
On Thu, 20 Nov 2008 01:46:31 -
Pegasus Mc Cleaft [EMAIL PROTECTED] wrote:
Hi everyone,
I am having difficulties rebuilding the world after some patches
were made today. I was wondering if anyone else is experiencing the
same troubles?
ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x0 -o
gptzfsboot.out /usr/obj/usr/src/sys/boot/i386/gptzfsboot/../btx/lib/crt0.o
zfsboot.o sio.o gptzfsboot.o ld: gptzfsboot.o: No such file: No such
file or directory *** Error code 1
Stop in /usr/src/sys/boot/i386/gptzfsboot.
*** Error code 1
I am experiencing the exact same problem with a fresh svn checkout
Just my me too.
I did not experience the problem 24 hours ago (after ZFS version 13
update and zfsboot import).
That's it. Seems to work with the following patch :
--- sys/boot/i386/gptzfsboot/Makefile.orig 2008-11-20
19:58:45.0 +0100
+++ sys/boot/i386/gptzfsboot/Makefile 2008-11-20 20:01:53.0 +0100
@@ -65,7 +65,7 @@
zfsboot.o: ${.CURDIR}/../../zfs/zfsimpl.c
.if ${MACHINE_ARCH} == amd64
-beforedepend gptzfsboot.o: machine
+beforedepend gptzfsboot.bin: machine
CLEANFILES+= machine
machine:
ln -sf ${.CURDIR}/../../../i386/include machine
Sorry for replying again to my own post :)
The patch is crap, in fact it just breaks the already broken
conditional. At least I can buildworld on amd64 now (I don't use the
recently introduced gptzfsboot).
Makefile experts ?
I've cc'ed current@ because HEAD is broken on amd64 for now.
Cheers,
Olivier
--
Pascal Hofstee
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Olivier Smedts _
ASCII ribbon campaign ( )
e-mail: [EMAIL PROTECTED]- against HTML email vCards X
www: http://www.gid0.org- against proprietary attachments / \
Il y a seulement 10 sortes de gens dans le monde :
ceux qui comprennent le binaire,
et ceux qui ne le comprennent pas.
--
Olivier Smedts _
ASCII ribbon campaign ( )
e-mail: [EMAIL PROTECTED]- against HTML email vCards X
www: http://www.gid0.org- against proprietary attachments / \
Il y a seulement 10 sortes de gens dans le monde :
ceux qui comprennent le binaire,
et ceux qui ne le comprennent pas.
--
Olivier Smedts _
ASCII ribbon campaign ( )
e-mail: [EMAIL PROTECTED]- against HTML email vCards X
www: http://www.gid0.org- against proprietary attachments / \
Il y a seulement 10 sortes de gens dans le monde :
ceux qui comprennent le binaire,
et ceux qui ne le comprennent pas.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: build problems with gptzfsboot (AMD64) 8.0-CURRENT
On Thursday 20 November 2008 18:57:53 Olivier SMEDTS wrote: What is your MACHINE_ARCH ? Mine is amd64, I think there's a problem with the conditional in sys/boot/i386/gptzfsboot/Makefile. ld doesn't need gptzfsboot.o on i386. Olivier 2008/11/20 Olivier SMEDTS [EMAIL PROTECTED]: 2008/11/20 Pascal Hofstee [EMAIL PROTECTED]: On Thu, 20 Nov 2008 01:46:31 - Pegasus Mc Cleaft [EMAIL PROTECTED] wrote: Hi everyone, I am having difficulties rebuilding the world after some patches were made today. I was wondering if anyone else is experiencing the same troubles? SNIP Hi Oliver, My machine is an Core2 Quad running under AMD64. (CPUTYPE?=core2) Thanks for replying. It puts my mind to ease because I was thinking it was a problem I created (I recently moved the /usr/src directory into a seperate zfs filing system) Peg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: build problems with gptzfsboot (AMD64) 8.0-CURRENT
On Thu, Nov 20, 2008 at 07:49:06PM +, Pegasus Mc Cleaft wrote:
On Thursday 20 November 2008 18:57:53 Olivier SMEDTS wrote:
What is your MACHINE_ARCH ?
Mine is amd64, I think there's a problem with the conditional in
sys/boot/i386/gptzfsboot/Makefile.
ld doesn't need gptzfsboot.o on i386.
Now I think I've got it :
All the '.if ${MACHINE_ARCH} == amd64' which replace the amd64 machine
link with an i386 one are useless on 7.0 and -CURRENT since rev. 1.17 of
sys/boot/efi/libefi/Makefile. This file already takes care of replacing
MACHINE_ARCH. And I don't think zfs*boot will be in 6-STABLE.
You can apply the following patch in sys/boot/i386. I'll submit a PR if
it's not committed before.
Cheers,
Olivier
Olivier
2008/11/20 Olivier SMEDTS [EMAIL PROTECTED]:
2008/11/20 Pascal Hofstee [EMAIL PROTECTED]:
On Thu, 20 Nov 2008 01:46:31 -
Pegasus Mc Cleaft [EMAIL PROTECTED] wrote:
Hi everyone,
I am having difficulties rebuilding the world after some patches
were made today. I was wondering if anyone else is experiencing the
same troubles?
SNIP
Hi Oliver,
My machine is an Core2 Quad running under AMD64. (CPUTYPE?=core2)
Thanks for replying. It puts my mind to ease because I was thinking it
was a
problem I created (I recently moved the /usr/src directory into a seperate
zfs
filing system)
Peg
--
Olivier Smedts _
ASCII ribbon campaign( )
e-mail: [EMAIL PROTECTED] - against HTML email vCards X
www: http://www.gid0.org - against proprietary attachments / \
Il y a seulement 10 sortes de gens dans le monde :
ceux qui comprennent le binaire,
et ceux qui ne le comprennent pas.
--- boot2/Makefile.orig 2008-11-20 20:56:31.0 +0100
+++ boot2/Makefile 2008-11-20 20:56:42.0 +0100
@@ -94,11 +94,4 @@
ORG1=`printf %d ${ORG1}` \
REL1=`printf %d ${REL1}` ${.TARGET}
-.if ${MACHINE_ARCH} == amd64
-beforedepend boot2.s: machine
-CLEANFILES+= machine
-machine:
- ln -sf ${.CURDIR}/../../../i386/include machine
-.endif
-
.include bsd.prog.mk
--- gptboot/Makefile.orig 2008-11-20 20:50:34.0 +0100
+++ gptboot/Makefile2008-11-20 20:50:40.0 +0100
@@ -67,11 +67,4 @@
gptboot.o: ${.CURDIR}/../../common/ufsread.c
-.if ${MACHINE_ARCH} == amd64
-beforedepend gptboot.o: machine
-CLEANFILES+= machine
-machine:
- ln -sf ${.CURDIR}/../../../i386/include machine
-.endif
-
.include bsd.prog.mk
--- libfirewire/Makefile.orig 2008-11-20 20:56:07.0 +0100
+++ libfirewire/Makefile2008-11-20 20:56:18.0 +0100
@@ -16,15 +16,4 @@
CFLAGS+= -Wformat -Wall
-.if ${MACHINE_ARCH} == amd64
-CLEANFILES+=machine
-machine:
- ln -sf ${.CURDIR}/../../../i386/include machine
-.endif
-
.include bsd.lib.mk
-
-.if ${MACHINE_ARCH} == amd64
-beforedepend ${OBJS}: machine
-.endif
-
--- libi386/Makefile.orig 2008-11-20 20:55:38.0 +0100
+++ libi386/Makefile2008-11-20 20:55:55.0 +0100
@@ -45,14 +45,4 @@
# the location of libstand
CFLAGS+= -I${.CURDIR}/../../../../lib/libstand/
-.if ${MACHINE_ARCH} == amd64
-CLEANFILES+= machine
-machine:
- ln -sf ${.CURDIR}/../../../i386/include machine
-.endif
-
.include bsd.lib.mk
-
-.if ${MACHINE_ARCH} == amd64
-beforedepend ${OBJS}: machine
-.endif
--- loader/Makefile.orig2008-11-20 20:54:43.0 +0100
+++ loader/Makefile 2008-11-20 20:54:58.0 +0100
@@ -110,10 +110,3 @@
LDADD= ${LIBFICL} ${LIBFIREWIRE} ${LIBZFS} ${LIBI386} -lstand
.include bsd.prog.mk
-
-.if ${MACHINE_ARCH} == amd64
-beforedepend ${OBJS}: machine
-CLEANFILES+= machine
-machine:
- ln -sf ${.CURDIR}/../../../i386/include machine
-.endif
--- zfsboot/Makefile.orig 2008-11-20 20:54:18.0 +0100
+++ zfsboot/Makefile2008-11-20 20:54:27.0 +0100
@@ -98,11 +98,4 @@
ORG1=`printf %d ${ORG1}` \
REL1=`printf %d ${REL1}` ${.TARGET}
-.if ${MACHINE_ARCH} == amd64
-beforedepend zfsboot.s: machine
-CLEANFILES+= machine
-machine:
- ln -sf ${.CURDIR}/../../../i386/include machine
-.endif
-
.include bsd.prog.mk
--- gptzfsboot/Makefile.orig2008-11-20 19:58:45.0 +0100
+++ gptzfsboot/Makefile 2008-11-20 20:50:25.0 +0100
@@ -64,11 +64,4 @@
zfsboot.o: ${.CURDIR}/../../zfs/zfsimpl.c
-.if ${MACHINE_ARCH} == amd64
-beforedepend gptzfsboot.o: machine
-CLEANFILES+= machine
-machine:
- ln -sf ${.CURDIR}/../../../i386/include machine
-.endif
-
.include bsd.prog.mk
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: build problems with gptzfsboot (AMD64) 8.0-CURRENT
2008/11/20 Olivier SMEDTS [EMAIL PROTECTED]:
On Thu, Nov 20, 2008 at 07:49:06PM +, Pegasus Mc Cleaft wrote:
On Thursday 20 November 2008 18:57:53 Olivier SMEDTS wrote:
What is your MACHINE_ARCH ?
Mine is amd64, I think there's a problem with the conditional in
sys/boot/i386/gptzfsboot/Makefile.
ld doesn't need gptzfsboot.o on i386.
Now I think I've got it :
All the '.if ${MACHINE_ARCH} == amd64' which replace the amd64 machine
link with an i386 one are useless on 7.0 and -CURRENT since rev. 1.17 of
sys/boot/efi/libefi/Makefile. This file already takes care of replacing
MACHINE_ARCH. And I don't think zfs*boot will be in 6-STABLE.
Wow, still not good... I was too enthusiastic while waiting for a
fresh buildworld to finish. It worked without cleaning though
(buildworld without patch then patch then make clean in sys/boot/i386
then finish buildworld without cleaning).
Must have missed something. I give up for today, I think I really must sleep :)
You can apply the following patch in sys/boot/i386. I'll submit a PR if
it's not committed before.
Cheers,
Olivier
Olivier
2008/11/20 Olivier SMEDTS [EMAIL PROTECTED]:
2008/11/20 Pascal Hofstee [EMAIL PROTECTED]:
On Thu, 20 Nov 2008 01:46:31 -
Pegasus Mc Cleaft [EMAIL PROTECTED] wrote:
Hi everyone,
I am having difficulties rebuilding the world after some patches
were made today. I was wondering if anyone else is experiencing the
same troubles?
SNIP
Hi Oliver,
My machine is an Core2 Quad running under AMD64. (CPUTYPE?=core2)
Thanks for replying. It puts my mind to ease because I was thinking it
was a
problem I created (I recently moved the /usr/src directory into a seperate
zfs
filing system)
Peg
--
Olivier Smedts _
ASCII ribbon campaign ( )
e-mail: [EMAIL PROTECTED]- against HTML email vCards X
www: http://www.gid0.org- against proprietary attachments / \
Il y a seulement 10 sortes de gens dans le monde :
ceux qui comprennent le binaire,
et ceux qui ne le comprennent pas.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
