libc ABI changes in RELENG_7
Hi Building a samba package in a recent RELENG_7 box and install on a 7.1-RELEASE system I found ABI changes that make ldconfig fail. This is related to a new strndup symbol in libc that samba build autodetect and use. This is really necesary? -- josemi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS UP: MFC of local_startup changes to rc.d complete
El Jueves, 29 de Diciembre de 2005 16:54, Carlos Eduardo G. Carvalho escribió: > Em Qui, 2005-12-29 às 16:41 +0100, Jose M Rodriguez escreveu: > > A lot of things has been changed, an now, it's really hard to get > > an idea about the boot process and the order used to launch the > > components. > > I'm sorry if I am saying something that is out of the discussion, I > didn't see the first messages, but Isn't it easy to do something > like: > > # cd /etc/rc.d > # rcorder * > preseedrandom > initdiskless > rcconf.sh > initrandom > dumpon > vinum > gbde_swap > gbde > ccd > (supressed output) Which only covers the base system scripts and send you docens of entries Also, now in head, a second scan is done. As far I know, the most important point are: mountcritlocal NETWORKING mountcritremote SERVERS DAEMON LOGIN I never said that this info is not guessable or even documented. Only that: - The docs are disperse. - The docs are not porters aware -- josemi -- This mail was scanned by AntiVir Milter. This product is licensed for non-commercial use. See www.antivir.de for details. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: MFC of local_startup changes to rc.d complete
El Lunes, 26 de Diciembre de 2005 09:53, Doug Barton escribió: > Jose M Rodriguez wrote: > > But this doesn't solve the real problem. We've lost a reference > > model about rc and the interaction with the base system and ports. > > I'm not sure what that last sentence means. > Form our old rc system, to the initial import from NetBSD, to what we have now in HEAD. A lot of things has been changed, an now, it's really hard to get an idea about the boot process and the order used to launch the components. > > - some kinda of style for ports/system rc scripts > > - some docs about keywords and stage support > > As I said in one of my recent heads up messages, man rc(8). > As far I know, rc(8) depends on the FreeBSD version used. I doubt RELENG_4_11 rc(8) may be enough. This kind of information must be on the porter's handbook. > > - some kinda of timeline model > > Timeline for what? > To guess the keywords to use for the rc script. > -- josemi -- This mail was scanned by AntiVir Milter. This product is licensed for non-commercial use. See www.antivir.de for details. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: MFC of local_startup changes to rc.d complete
El Viernes, 23 de Diciembre de 2005 16:17, Florent Thoumie escribió: > On Friday 23 December 2005 16:12, Jose M Rodriguez wrote: > > El Viernes, 23 de Diciembre de 2005 15:38, Florent Thoumie escribió: > > > On Friday 23 December 2005 15:19, Jose M Rodriguez wrote: > > > > I'm not sure this is the way to go, but ... > > > > > > > > - some kinda of style for ports/system rc scripts > > ? In the way of style(9). > > > - some docs about keywords and stage support > > It's quite simple enough but yar wrote an article about it : > > http://people.freebsd.org/~yar/rcng/article.html > > I thought it already made it to the doc tree. > I think this is about the rc framework. But not about the hard details: Also, if we now support rcorder for localpkg, we're implemening, at last, a two stage boot process ( we can't read the local rc scripts at the very beginning of the boot process). > > - some kinda of timeline model > > There's one. > Commit, MFC, fix broken ports. Sorry, it's boot process timeline, not working timeline. We need a good reference for good tagging of rc scripts. -- josemi -- This mail was scanned by AntiVir Milter. This product is licensed for non-commercial use. See www.antivir.de for details. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: MFC of local_startup changes to rc.d complete
El Viernes, 23 de Diciembre de 2005 15:38, Florent Thoumie escribió: > On Friday 23 December 2005 15:19, Jose M Rodriguez wrote: > > I'm not sure this is the way to go, but ... > > > > Can someone put a document on what is the desired model? I think > > we have too much little pieces of disperse notes about this. > > > > Also, some working notes about ports and RELENG_4/RELENG_5 src > > issues will be of interest. > > > > Hope this can be tweak in time for 6.1 (Jan). > > Convert your old script to rcNG scripts and use USE_RC_SUBR= > script.sh. Ensure that the rcorder preamble contains meaningful > keywords (PROVIDES, REQUIRES, BEFORE, ...) for all your rcNG scripts. > bsd.port.mk should do the rest. Some time working with binary oriented software systems have teach me that simple changes may become harder when size and numbers grow up. I think this may be even harder with a non-binary oriented system like ports. But this doesn't solve the real problem. We've lost a reference model about rc and the interaction with the base system and ports. - some kinda of style for ports/system rc scripts - some docs about keywords and stage support - some kinda of timeline model ... I think that this is more or less out there, but not in a strict document that may guide for the change to FreeBSD-6.1 -- josemi -- This mail was scanned by AntiVir Milter. This product is licensed for non-commercial use. See www.antivir.de for details. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: MFC of local_startup changes to rc.d complete
El Miércoles, 21 de Diciembre de 2005 09:23, Doug Barton escribió: > Howdy, > > As has been discussed for a couple weeks now, I have MFC'ed to > RELENG_6 the changes in /etc/rc* that bring new-style boot scripts > from the local_startup directories (by default /usr/local/etc/rc.d > and /usr/X11R6/etc/rc.d) into the base rcorder. For old style scripts > (those that don't use rc.subr) there should be no changes. They will > still run out of /etc/rc.d/localpkg. For those scripts that have been > converted to use rc.subr, they will still be run the same way that > they are now. The difference is that they will be added to the base > rcorder list, and run in that spot instead of in localpkg. To get an > idea of the current list (minus any local scripts) in RELENG_6, see > http://people.freebsd.org/~dougb/rcorder-6.all > > In an ideal world, there should be no problems related to running the > scripts in a different order. However, it is anticipated that there > may be a brief period while scripts for whom the ordering is > significant are adjusted. These are extremely easy changes to make, > and do not otherwise affect the functionality of the packages in any > way. If you run into one of these problems, please report it to the > port's maintainer, and [EMAIL PROTECTED] ASAP. In almost all > cases however the scripts will run close enough to their old position > as not to make any difference, since currently localpkg is fairly > late in the order. > > This change is being made so that port authors and users can take > advantage of the greater control these features will give them. Some > authors have already stepped forward and added new functionality to > their ports that take advantage of these features. If anyone has > questions about the changes, or what they offer you, feel free to ask > on [EMAIL PROTECTED] You can also find more information in > rc(8) on an updated system. > > > Happy Holidays, > > Doug > I'm not sure this is the way to go, but ... Can someone put a document on what is the desired model? I think we have too much little pieces of disperse notes about this. Also, some working notes about ports and RELENG_4/RELENG_5 src issues will be of interest. Hope this can be tweak in time for 6.1 (Jan). -- josemi -- This mail was scanned by AntiVir Milter. This product is licensed for non-commercial use. See www.antivir.de for details. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Routes not deleted after link down
El Domingo, 19 de Junio de 2005 10:48, Michal Vanco escribió: > On Sunday 19 June 2005 10:29, Gleb Smirnoff wrote: > > On Sat, Jun 18, 2005 at 10:14:32PM +0200, Jose M Rodriguez wrote: > > J> Second, you may need a route daemon for this. ospf is a well > > known J> canditate where convergence in case of lost link is a > > must. > > > > While an OSPF daemon may stop advertising the affected route to its > > neighbors, the kernel will still have the route installed and thus > > the box won't be able to contact other hosts on the connected net, > > while they are reachable via alternate pass. > > Routing protocol should be responsible for removing affected routes > from FIB. For example quagga should remove all routes learned via > particular ospf neighbour when that neighbour is not reachable > anymore due to link goes down. But in case when no daemons are used > (`static' and `connected' are also `routing protocols'), kernel > should be responsible for doing that. > > > I've checked that Cisco routers remove route from FIB when > > interface link goes down. I haven't checked Junipers yet. > > Junipers do the same. It is the only feasible behaviour for router. > > > From my viewpoint, removing route (or marking it unusable) is a > > correct behavior for router. Not sure it is correct for desktop. > > Sure. > > > My vote is that we should implement this functionality and make it > > switchable via sysctl. I'd leave the default as is. > I'm not sure of this. I also think that a devd or monitor daemon will be enough and easy to implement. I think NetBSD have allready some kinda of net monitor daemon for pppoe support (via sppp). Not sure if route support is included. But seems easy and clean that a kernel based solution. -- josemi > Agree. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Routes not deleted after link down
El Domingo, 19 de Junio de 2005 00:04, Michal Vanco escribió: > On Saturday 18 June 2005 20:48, Chuck Swiger wrote: > > Michal Vanco wrote: > > > i discovered that routes are not deleted from routing table after > > > link on interface goes down. For example: > > > > [ ... ] > > > > > Should't all routes via bge0 be deleted after link on bge0 goes > > > down? > > > > Maybe. If the system was not going to be reconnected to that > > network anytime soon, it would be a good idea. On the other hand, > > if the link down was due to a transient failure of a wireless > > connection, which will be back up in a second or two, it's much > > better not to drop the route and kill any open connections. > > hmm ... this approach is may be appropriate for deskop instalation. > what about internet router? shouldn't "fast convergence" be better in > this case? imagine two links connected to the same router with > different metrics. if first of them goes down, the second never gets > used in this case. > > michal First, this is a thread for net, not stable. Second, you may need a route daemon for this. ospf is a well known canditate where convergence in case of lost link is a must. Also, you can monitor link status and do the switch from a daemon. Userland ppp have more or less this. -- josemi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: how can I use all the plugins in mozilla
El Jueves, 9 de Junio de 2005 18:27, Maher Mohamed escribió: > i instaled the mozilla and the linuxpluginwrapper port > but i still get this error messages > > > LoadPlugin: failed to initialize shared library > /usr/compat/linux/usr/local/Adobe/Acrobat7.0/Browser/intellinux/nppdf >.so [Shared object "libc.so.6" not found, required by "nppdf.so"] > > why is that? > and what is exactly that i should do. > I am using FreeBSD 5.4 Stable > thank you There's a little problem with linuxpluginwrapper libmap.conf, you must s,compat,usr/compat,: # Acrobat7 with Mozilla/Firebird/Galeon/Epiphany/Konqueror [/usr/compat/linux/usr/local/Adobe/Acrobat7.0/Browser/intellinux/nppdf.so] libc.so.6 pluginwrapper/acrobat.so -- josemi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysinstall new disc layout in 5.4 RELEASE
El Martes, 10 de Mayo de 2005 20:58, bazzoola escribió: > Jose M Rodriguez wrote: > >El Martes, 10 de Mayo de 2005 18:15, Freddie Cash escribió: > >>On May 10, 2005 02:35 am, bazzoola wrote: > >>>First, thanks for all the people who took the time and effort to > >>>make this happen :) > >>> > So, should this be considered a bug in sysinstall because it didnt > ask for the disc even tho it should have known that it is located on > disc2. > > bazzoola Please, send-pr this to bin -- josemi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysinstall new disc layout in 5.4 RELEASE
El Martes, 10 de Mayo de 2005 18:53, Freddie Cash escribió: > On May 10, 2005 09:33 am, you wrote: > > El Martes, 10 de Mayo de 2005 18:15, Freddie Cash escribió: > > > On May 10, 2005 02:35 am, bazzoola wrote: > > > > First, thanks for all the people who took the time and effort > > > > to make this happen :) > > > > > > Not Any more. Now Install/LiveCD/Rescue is done by disc1, which > > include also the packages needed by sysinstall. > > > > disc2 is a collection of aditional packages that, at last in the > > i386 case, include the full gnome/kde ports (Not lite). > > Well, what do you know, you're right. Somebody needs to update the > Handbook, then, because this is not listed in there anywhere. I had > to ddig around in the Release Notes for 5.4 to find any mention of > this, and it wasn't too well highlighted in there. > > Even a note in the FTP directory would have helped. > > Anyone know what happened to the mini-inst CD? It was really nice to > only have to download a 200 MB ISO instead of a 600 MB one, > especially since I don't use packages for anything. been there, 5.4-RELEASE-i386-bootonly.iso. -- josemi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysinstall new disc layout in 5.4 RELEASE
El Martes, 10 de Mayo de 2005 18:15, Freddie Cash escribió: > On May 10, 2005 02:35 am, bazzoola wrote: > > First, thanks for all the people who took the time and effort to > > make this happen :) > > > > I just finished downloading the images thru torrents. I burned both > > i386 disc one and two then installed 5.4. Everything worked fine as > > usual. > > CD1 is the installation CD. This includes about 400 MB of > pre-compiled packages that can be installed. > > CD2 is a LiveCD mainly meant for rescue situations via sysinstall's > "Fixit" feature. Not Any more. Now Install/LiveCD/Rescue is done by disc1, which include also the packages needed by sysinstall. disc2 is a collection of aditional packages that, at last in the i386 case, include the full gnome/kde ports (Not lite). -- josemi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: MFC pxe fixes
El Miércoles, 4 de Mayo de 2005 09:36, Danny Braniss escribió: > sorry if this looks like im highjacking hte thread, but i've > submitted a PR http://www.freebsd.org/cgi/query-pr.cgi?pr=61239 > which among other things, places ALL the dhcp variables in the > environment. > > danny I can't see how this will be on FreeBSD-5.4 or -stable. If you're interested on this, open a thread on current. This is about making pxeboot compiled with LOADER_TFTP_SUPPORT defined works as documented. Also, point that your workplan makes a second bootp transaction needed. Try make the bootp/dhcp packet parser independent of bootp.c (At last, exportable), so we can parse the 'bootplayer' binary packet pxe allready have. ALso, I'm not sure we can redefine CLASSID without breaking PXE (not dhcp) compatibility. Remember that the PXE bios has allready do the bootp/dhcp transaction for us, and the correct path is only parse the 'bootplayer' (really a bootp/dhcp packet in binary form) than we get from the bios. -- josemi -- josemi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: MFC pxe fixes
El Jueves, 28 de Abril de 2005 15:42, Jose M Rodriguez escribió:
> Hi,
>
> I note that the long standing bug that prevents do a nfsroot mount
> after operate pxeloader in tftp mode is recent solved in -CURRENT
> pxe.c
>
> I think this can be missed for 5.4 REL, but I'll be glad to see this
> MFC as time permitting.
>
I pointing to changes in revs 1.21 and 1.22 of
src/sys/boot/i386/libi386/pxe.c
In special, rev 1.21, from kan, 7 weeks ago.
I can't see this breaking any ABI, but making things work as documented.
Tested on RELENG_5_4 as attached patch
--
josemi
--- pxe.diff begins here ---
Index: pxe.c
===
RCS file: /home/cvs/freebsd/src/sys/boot/i386/libi386/pxe.c,v
retrieving revision 1.20
diff -u -r1.20 pxe.c
--- pxe.c 25 Aug 2003 23:28:31 - 1.20
+++ pxe.c 28 Apr 2005 17:49:35 -
@@ -27,7 +27,7 @@
*/
#include
-__FBSDID("$FreeBSD: src/sys/boot/i386/libi386/pxe.c,v 1.20 2003/08/25
23:28:31 obrien Exp $");
+__FBSDID("$FreeBSD: src/sys/boot/i386/libi386/pxe.c,v 1.22 2005/04/17
21:38:22 wollman Exp $");
#include
#include
@@ -308,6 +308,7 @@
}
setenv("boot.nfsroot.server", inet_ntoa(rootip), 1);
setenv("boot.nfsroot.path", rootpath, 1);
+ setenv("dhcp.host-name", hostname, 1);
}
}
pxe_opens++;
@@ -413,6 +414,22 @@
/* structure truncated here */
};
extern struct nfs_iodesc nfs_root_node;
+extern int rpc_port;
+
+static void
+pxe_rpcmountcall()
+{
+ struct iodesc *d;
+ int error;
+
+ if (!(d = socktodesc(pxe_sock)))
+ return;
+d->myport = htons(--rpc_port);
+d->destip = rootip;
+ if ((error = nfs_getrootfh(d, rootpath, nfs_root_node.fh)) != 0)
+ printf("NFS MOUNT RPC error: %d\n", error);
+ nfs_root_node.iodesc = d;
+}
static void
pxe_setnfshandle(char *rootpath)
@@ -421,6 +438,14 @@
u_char *fh;
charbuf[2 * NFS_FHSIZE + 3], *cp;
+ /*
+* If NFS files were never opened, we need to do mount call
+* ourselves. Use nfs_root_node.iodesc as flag indicating
+* previous NFS usage.
+*/
+ if (nfs_root_node.iodesc == NULL)
+ pxe_rpcmountcall();
+
fh = &nfs_root_node.fh[0];
buf[0] = 'X';
cp = &buf[1];
--- pxe.diff ends here ---
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
enable dummynet from /etc/rc.d
Hi, This is FreeBSD-5.4 RC3 I'm working in a replacement rc.firewall script and found no /etc/rc.d method to launch dummynet (load module). Right now, dummynet is kernel based, but I want this be able to work from stock kernel (ipfw, ipfw6, dummynet from modules). I missed some rc.conf var or rc.d/ module? If this will be added, maybe /etc/rc.d/ipfw the right place? And what about firewall_dummynet for the controlling knob? -- josemi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UPDATE: ATA mkIII official patches for releng_5
El Jueves, 28 de Abril de 2005 17:41, Damian Gerow escribió: > Thus spake Jose M Rodriguez ([EMAIL PROTECTED]) [28/04/05 06:10]: > : > Any clues at all? I'd *really* like to apply the patches to my > : > system, but continuously run into that kmod.mk problem. > : > : Using this in RELENG_5_4 without problems. latest -n patchset. > : look into the list archive for the sos announce. > > I'm using the latest -n patchset. I tried against RELENG_5_4, and > against a RELENG_5 sup from last night. I still get the kmod.mk > build error. > > I'm positive it's something about my build environment, but I don't > know /what/. > For safety, and only about what I'm using (RELENG_5_4), you: - cvs/cvsup fresh sources - apply the patchset - untar the tarball And get what build error? -- josemi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
MFC pxe fixes
Hi, I note that the long standing bug that prevents do a nfsroot mount after operate pxeloader in tftp mode is recent solved in -CURRENT pxe.c I think this can be missed for 5.4 REL, but I'll be glad to see this MFC as time permitting. thanks in advance, -- josemi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UPDATE: ATA mkIII official patches for releng_5
El Jueves, 28 de Abril de 2005 11:30, Damian Gerow escribió: > Any clues at all? I'd *really* like to apply the patches to my > system, but continuously run into that kmod.mk problem. Using this in RELENG_5_4 without problems. latest -n patchset. look into the list archive for the sos announce. -- josemi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VIA M1000 mini-itx system installation woes - WRITE_DMA error - cabling?
El Martes, 26 de Abril de 2005 23:31, W C escribió: > Hi all, > > I am attempting to install 5.3-R from cd (iso image download) and > sysinstall is failing > to write the chosen (Auto Layout) filesystem to disk, the Toshiba 80G > on the primary ide channel as master. The error on vty1 is (from > memory) ad0: WRITE_DMA, error=84. > The drive is detected by BIOS as a UDMA100 device. There is nothing > else on this IDE channel, and only a cd drive on the other IDE slot. > > A search of -questions reveals this error is a UDMA mismatch, > possible caused by 80-pin cabling, and fixable with atacontrol ad0 > udma33 pio bla bla bla. However, I do not yet have a running system > to run atacontrol from, as I am installing. I have rooted around in > the bios for an option to force the drive to UDMA33 speed, to no > avail. Does anyone know how I can work around this problem and > install FreeBSD to this neat little system? Do I have bad cabling, a > bad drive, or ??? > Ther're two types of 80pins ribbons, and found that you can interchange them in some scenarios. As a first aid, try change the cable, loocking for the presence (or not) of a cut cable. Also, you may use a 40pins ribbon, that will get you in UDMA33 . -- josemi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PXE booting a 5.4-RC2 system ...
El Monday 18 April 2005 01:34, Joe Greco escribió: > So I'm playing with 5.4-RC2. > > I can get the system to PXE boot into a normal full base system > environment just fine, all the way to multiuser. > > However, for system installs, we've historically PXE booted the boot > floppy images and then proceeded to do NFS or FTP based installs. > > So I set off to do this with 5.4-RC2. I pulled the contents out of > boot.flp, kern1.flp, and kern2.flp and stuffed them all on one of our > boot servers. > > /boot/5.4X-i386-load 358 # ls -al > total 3716 > drwxr-xr-x 4 root wheel 512 Apr 17 18:14 . > drwxr-xr-x 10 root wheel 512 Apr 17 18:07 .. > drwxr-xr-x 2 root operator 512 Apr 10 04:26 .snap > -rw-r--r-- 1 root wheel 138998 Apr 10 04:26 acpi.ko.gz > drwxr-xr-x 3 root wheel 512 Apr 10 04:26 boot > -rw-r--r-- 1 root wheel 1425408 Apr 10 04:26 kernel.gz.aa > -rw-r--r-- 1 root wheel 1060816 Apr 10 04:26 kernel.gz.ab > -rw-r--r-- 1 root wheel 16384 Apr 10 04:26 kernel.gz.boot > -rw-r--r-- 1 root wheel 91 Apr 10 04:26 kernel.gz.split > -rw-r--r-- 1 root wheel 1081726 Apr 10 04:26 mfsroot.gz > -rw-r--r-- 1 root wheel 69 Apr 17 18:10 notes > > Same setup works fine with /boot/5.4X-i386-pxe1, which is just the > entire 5.4-RC2 distribution extracted to that directory. > > Going back to the above setup: > > The client PC, a Gigabyte 7VM400-RZ with an AMD 2700 XP and 512MB > RAM, a CD drive, and an Adaptec 2940U2W controller, starts loading > the PXE loader just fine. > > PXE Loader 1.00 > > Building the boot loader arguments > Relocating the loader and the BTX > Starting the BTX loader > > BTX loader 1.00 BTX is version 1.01 > Console: internal video/keyboard > BIOS drive A: is disk0 > > PXE version 2.1, real mode entry point @9e2b:00f6 > BIOS 640kB/490432kB available memory > > FreeBSD/i386 bootstrap loader, Revision 1.1 > ([EMAIL PROTECTED], Sun Apr 10 04:50:34 UTC 2005) > pxe_open: server addr: > pxe_open: server path: /boot/5.4X-i386-load > pxe_open: gateway ip: X > Loading /boot/defaults/loader.conf > panic: free: guard1 fail @ 0x54a7c from > /usr/src/lib/libstand/gzipfs.c:192 --> Press a key on the console to > reboot <-- > > So I figure maybe it's a bug or maybe I need to tweak something. > Anyone have a clue which is the correct answer? > try what is used in the CD install boot: mount a kernel and use a mfsroot. This maybe even more easy to setup. Take a look into boot/ of CD1. -- josemi > Thanks, > > ... JG ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with world build in RELENG_5_4
El Thursday 14 April 2005 18:51, Doug White escribió: > On Mon, 11 Apr 2005, Jose M Rodriguez wrote: > > Hi, > > > > I found a little problem with RELENG_5_4 buildworld in my env. > > > > I have a little patched RELENG_5_4 src in a local cvs server, > > mounted ro,-L in the build machine (/usr/src) > > > > No rpc.lockd or rpc.statd daemon running in both machines. build > > machine timesync with cvs server by ntpdate before build. > > > > Every time I do a rm -rf /usr/obj/* && cd /usr/src && make > > buildworld I get: > > > > ===> share/info > > ===> include > > rm -f osreldate.h version vers.c > > rm: version: Read-only file system > > *** Error code 1 > > > > The only thing I change form previous week builds are the -L mount > > and disabling the rpc.lockd and rpc.statd daemons in both machines. > > > > I can solve the problem doing a make obj before make buildworld. > > Sounds like these files may be leftovers from a local build on the > NFS server. You might try doing 'make cleandir; make cleandir' on > the server to remove any remnants. > No builds made in the nfs server ever. make cleandir gets to the same result. > Areyou setting MAKEOBJDIRPREFIX in /etc/make.conf? No. /usr/obj is in a local fs. Only /usr/src is in the nfs server and mounted ro. Seems I can't reproduce it with nfs locking enabled and well configured. Nor with /usr/obj populated before the build. Maybe a make issue? -- josemi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RELENG_5 broken?
Anyone seen this?
--
josemi
cc -c -Os -fno-strict-aliasing -fomit-frame-pointer -march=pentium
-mtune=c3 -pi
pe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-proto
types -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99
-nostd
inc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica
-I/usr/src/sys/con
trib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf
-I/usr/src/s
ys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd
-I/usr/src/sys/contrib
/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000
--param i
nline-unit-growth=100 --param large-function-growth=1000
-mno-align-long-string
s -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2
-ffreesta
nding -Werror /usr/src/sys/kern/subr_bus.c
/usr/src/sys/kern/subr_bus.c:1082: warning: no previous prototype for
'devclass_
get_drivers'
*** Error code 1
Stop in /usr/obj/usr/src/sys/ANTARES.
*** Error code 1
---
#include
__FBSDID("$FreeBSD: src/sys/kern/subr_bus.c,v 1.156.2.6 2005/04/14
04:54:15 njl
Exp $");
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Problems with world build in RELENG_5_4
Hi, I found a little problem with RELENG_5_4 buildworld in my env. I have a little patched RELENG_5_4 src in a local cvs server, mounted ro,-L in the build machine (/usr/src) No rpc.lockd or rpc.statd daemon running in both machines. build machine timesync with cvs server by ntpdate before build. Every time I do a rm -rf /usr/obj/* && cd /usr/src && make buildworld I get: cc -Os -fno-strict-aliasing -mtune=athlon-xp -pipe -I. -I/usr/src/usr.sbin/confi g -I/usr/obj/usr/src/i386/legacy/usr/include -static -L/usr/obj/usr/src/i386/l egacy/usr/lib -o config config.o main.o lang.o mkmakefile.o mkheaders.o mkoption s.o -ll -legacy sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 config /usr/obj/usr/sr c/i386/legacy/usr/sbin -- >>> stage 2.1: cleaning up the object tree -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE =pentium-mmx GROFF_BIN_PATH=/usr/obj/usr/src/i386/legacy/usr/bin GROFF_FONT_PA TH=/usr/obj/usr/src/i386/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/u sr/src/i386/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/i386 INSTAL L="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/us r/obj/usr/src/i386/legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games:/usr/ob j/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/ games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 DESTDIR=/usr/obj/usr/s rc/i386 par-cleandir ===> share/info ===> include rm -f osreldate.h version vers.c rm: version: Read-only file system *** Error code 1 The only thing I change form previous week builds are the -L mount and disabling the rpc.lockd and rpc.statd daemons in both machines. I can solve the problem doing a make obj before make buildworld. Can someone reproduce this? thanks in advance, -- josemi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problems with devfs amd /dev/fd/
Doug White escribió: On Tue, 4 Jan 2005, Jose M Rodriguez wrote: Hi, trying to import foomatic-rip, I found great changes under /dev/fd/ going from RELENG_4 to RELENG_5. Seems that /dev/fd/3 is used by several pipe construct like foomatic-rip to get a free backwards error channel. Digging a bit, I found that now, I need mount fdescfs to get this. I think this is not well documented in release notes. Nothing in the FreeBSD base system depends on /dev/fd. foomatic-rip a third-party program. It would be appropriate for the port to print a message reminding the user to mount fdescfs if they plan to use this application, but not appropriate to enable it by default just for this one port. Also, seems that support /dev/fd/3 in devfs may be a good idea. Add a sysctl to control how many /dev/fd/n devfs create will be even better. fdesc is populated automatically based on the calling program. If the program has file descriptor 3 open then /dev/fd/3 will be available. Likewise, if it is closed, /dev/fd/3 will not exist. Yes, but with fdescfs mounted, not with only devfs. This is not a so clean change from RELENG_4 to RELENG_5. I think this need a simple note on release docs. -- josemi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
problems with devfs amd /dev/fd/
Hi, trying to import foomatic-rip, I found great changes under /dev/fd/ going from RELENG_4 to RELENG_5. Seems that /dev/fd/3 is used by several pipe construct like foomatic-rip to get a free backwards error channel. Digging a bit, I found that now, I need mount fdescfs to get this. I think this is not well documented in release notes. Also, seems that support /dev/fd/3 in devfs may be a good idea. Add a sysctl to control how many /dev/fd/n devfs create will be even better. -- josemi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: names of supfiles in /usr/share/examples/cvsup
El Lunes, 6 de Diciembre de 2004 08:39, Rob escribió: > Hi, > > For 5.3 in /usr/share/examples/cvsup, there's: > > stable-supfile : for FreeBSD-stable > standard-supfile : for FreeBSD-current > > I find this naming rather confusing. Why "stable" refers to STABLE, > but "standard" refers to CURRENT ? > > This causes unnecessary confusion. Why not the following name > convention: > > release-supfile : for FreeBSD-RELEASE Better security-supfile. There is just one release, things like RELENG_5_3 are security branchs, not release branchs. > stable-supfile : for FreeBSD-STABLE > current-supfile : for FreeBSD-CURRENT > -- josemi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problems with loader
El Jueves, 2 de Diciembre de 2004 19:57, Kevin Oberman escribió: > > From: Jose M Rodriguez <[EMAIL PROTECTED]> > > Date: Thu, 2 Dec 2004 19:30:50 +0100 > > Sender: [EMAIL PROTECTED] > > > > El Jueves, 2 de Diciembre de 2004 19:06, Konstantin Volevatch escribió: > > > Hi, Jose! > > > > > > In /boot/defaults/loader.conf : > > > module_path="/boot/modules" > > > > > > You can override it with: > > > module_path="/boot/kernel" > > > > tried. doesn' work. Anyone else see this? > > Still sounds like a broken module path to me. But the correct fix is > in UPDATING. See the entry for 20040806. I install a brand new /boot from fresh build. I tried put module_path="/boot/kernl". no look. After that, I try a /boot/loader.conf: loader_color="YES" verbose_loading="YES" beastie_disable="YES" snd_via8233_load="YES" After kernel load, I can see a: snd_via8233...failed breaking into the loader, show: module_path=/boot/kernel;/boot/modules After boot, kldload snd_via8233 works without problems. I only can see minor changes fron ru@ (3 weeks) and iedowse@ (2 month). But no clues on this. Any help on this is welcome -- josemi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problems with loader
El Jueves, 2 de Diciembre de 2004 19:06, Konstantin Volevatch escribiÃ: > Hi, Jose! > > In /boot/defaults/loader.conf : > module_path="/boot/modules" > > You can override it with: > module_path="/boot/kernel" > tried. doesn' work. Anyone else see this? > Ð ÑÐÐÐÑ ÐÑ ÐÐÑÐÐÑÐ 02 ÐÑÑ 2004 18:47 Jose M > Rodriguez ÑÐÐ(a): > > Hi, > > this is RELENG_5 as of today, but I notice this several days > > before. > > > > Right now, I can't load modules from loader via _load="YES" > > on /boot/loader.conf > > > > Only kernel and acpi module loaded. > > > > Notice this with snd_via8233_load="YES" > > > > This is a known issue? > > > > thanks in advance, > > > > -- > > josemi > > > > ___ > > [EMAIL PROTECTED] mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to > > "[EMAIL PROTECTED]" -- josemi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
problems with loader
Hi, this is RELENG_5 as of today, but I notice this several days before. Right now, I can't load modules from loader via _load="YES" on /boot/loader.conf Only kernel and acpi module loaded. Notice this with snd_via8233_load="YES" This is a known issue? thanks in advance, -- josemi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Named 9.3.0 && weird error at bootup
El Lunes, 15 de Noviembre de 2004 19:51, Samuel Trommel escribió: > Hello, > > > > Recently I upgraded from 5.2.1-release to 5.3-release. When I try to > start named I get a weird error: > > > > Nov 15 19:23:12 freebsd named[1152]: starting BIND 9.3.0 -4 -u bind > -t /var/named/etc/namedb/ -c /etc/named.conf this doesn't seems good configured. How is your named setup? -- josemi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
