Mostly static binaries with crunchgen
Adrian Steinmann's talk at EuroBSDcon regarding a single user SSH daemon for rescue purposes highlighted an interesting point regarding some binaries. The GEOM userland binaries such as gmirror, gstripe, etc. use dlopen() to load classes from /lib/geom and therefore cannot be statically linked and, by extension, cannot be crunched with crunchgen. Adrian mentioned that it would be useful if crunchgen(1) supported mostly static binaries; i.e., a libs_so extension to crunchgen which would allow these binaries to be crunched, simply requiring then that rtld and the libraries be made available on the memory disk. This allows those of us who use GEOM classes to make a small rescue disk. I started to add this to crunchgen on the way home, and have worked with Adrian to finish it off. The patch is attached. It simply adds a libs_so keyword which specifies libraries that will be linked statically; all current config files continue to produce the same code as they did before. I'd like to commit this with a 6 week MFC period or so, but my mentor is currently busy. Could someone else please take this up? Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) Index: crunchgen.1 === RCS file: /home/ncvs/src/usr.sbin/crunch/crunchgen/crunchgen.1,v retrieving revision 1.28 diff -u -r1.28 crunchgen.1 --- crunchgen.1 30 May 2002 07:51:22 - 1.28 +++ crunchgen.1 14 Dec 2005 21:11:30 - @@ -16,7 +16,7 @@ .\ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL U.M. .\ BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES .\ WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN -.\ ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR +.\ ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTUOUS ACTION, ARISING OUT OF OR .\ IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. .\ .\ Author: James da Silva, Systems Design and Analysis Group @@ -139,7 +139,7 @@ .Nm . This is useful to define some make variables such as .Va RELEASE_CRUNCH -or similar, which might affect the behaviour of +or similar, which might affect the behavior of .Xr make 1 and are annoying to pass through environment variables. .It Fl m Ar makefile-name @@ -210,6 +210,21 @@ Multiple .Ic libs lines can be specified. +.It Ic libs_so Ar libspec ... +A list of library specifications to be dynamically linked in the +crunched binary. +These libraries will need to be made available via the run-time link-editor +.Xr rtld 1 +when the component program that requires them is executed from +the crunched binary. +Multiple +.Ic libs_so +lines can be specified. +The +.Ic libs_so +directive overrides a library specified gratuitously on a +.Ic libs +line. .It Ic buildopts Ar buildopts ... A list of build options to be added to every make target. .It Ic ln Ar progname linkname @@ -417,9 +432,15 @@ .Dq Pa kcopy can be copied onto an install floppy and hard-linked to the names of the component programs. +.Pp +Note that if the +.Ic libs_so +command had been used, copies of the libraries so named +would also need to be copied to the install floppy. .Sh SEE ALSO .Xr crunchide 1 , -.Xr make 1 +.Xr make 1 , +.Xr rtld 1 .Sh CAVEATS While .Nm @@ -446,3 +467,10 @@ .Pp Copyright (c) 1994 University of Maryland. All Rights Reserved. +.Pp +The +.Ic libs_so +keyword was added in 2005 by +.An Adrian Steinmann Aq [EMAIL PROTECTED] +and +.An Ceri Davies Aq [EMAIL PROTECTED] . Index: crunchgen.c === RCS file: /home/ncvs/src/usr.sbin/crunch/crunchgen/crunchgen.c,v retrieving revision 1.35 diff -u -r1.35 crunchgen.c --- crunchgen.c 20 Jan 2005 10:49:03 - 1.35 +++ crunchgen.c 14 Dec 2005 21:11:30 - @@ -74,6 +74,7 @@ strlst_t *keeplist; strlst_t *links; strlst_t *libs; + strlst_t *libs_so; int goterror; } prog_t; @@ -83,6 +84,7 @@ strlst_t *buildopts = NULL; strlst_t *srcdirs = NULL; strlst_t *libs = NULL; +strlst_t *libs_so = NULL; prog_t *progs = NULL; char confname[MAXPATHLEN], infilename[MAXPATHLEN]; @@ -106,6 +108,8 @@ void add_string(strlst_t **listp, char *str); int is_dir(char *pathname); int is_nonempty_file(char *pathname); +int subtract_strlst(strlst_t **lista, strlst_t **listb); +int in_list(strlst_t **listp, char *str); /* helper routines for main() */ @@ -238,6 +242,7 @@ void add_progs(int argc, char **argv); void add_link(int argc, char **argv); void add_libs(int argc, char **argv); +void add_libs_so(int argc, char **argv); void add_buildopts(int argc, char **argv); void add_special(int argc, char **argv); @@ -292,6 +297,8 @@ f = add_link; else if(!strcmp(fieldv[0], libs)) f = add_libs;
pppd and DNS
Hi, Looking through pppd sources I found that it doesn't know how to request DNS info from the server, while ppp can. Here I mean requesting DNS info and updating /etc/resolv.conf. Did anyone tried to make it possible with pppd? Since I used to pppd I'd like to teach him this useful functionality. -ip -- Laugh and the world laughs with you. cry and ... you have to blow your nose. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Sat, Dec 17, 2005 at 05:37:20AM -0500, Allen wrote: On Saturday 17 December 2005 03:55, Christian Brueffer wrote: On Sat, Dec 17, 2005 at 08:55:00AM +, Allen wrote: I know about the port tool, but what I'd love to have is a tool you could run from the CLI or the GUI that would check for updates, and then ask which ones to install, similar to Swaret on Slackware. This way people can do the usual updates if they want, and people like me can show people BSD and how great it is. You probably haven't seen ports/security/freebsd-update yet. Actually, I've seen that and it does come close... But it didn't seem to like updating the Kernel or anything similar to the base system in the time I spent with it. Look harder; those are the *only* things it will update. This is not portupgrade. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpjw89aCk0dx.pgp Description: PGP signature
Re: My wish list for 6.1
On Mon, Dec 19, 2005 at 10:34:23AM +0100, Dirk GOUDERS wrote: 3. Full review and update of the install docs, handbook, FAQ, etc. There are sections that are embarrassingly out of date (one section of the handbook apparently states that we only support a single brand of wifi cards). A co-worker of mine tried to install 6.0 using just the handbook install guide, and discovered that it really doesn't match reality anymore, in both big and small ways. Contact me directly if you would like his list of comments. I am wondering if it wouldn't be advantageous to have versioned documents that just cover one specific release and not to cover all realeases in single documents. I could imagine that it is harder to cover everything in single documents than to perhaps copy the existing documentation when a new branch is created and edit it to match just the new release. Maybe, I do not realize how much more work this would be but it would probably enforce regular reviews of the documentation and the readers would benefit from it. This is exactly the idea that I have been pimping to anyone who will listen for the last three months or so. I also think that it is advantageous for users who are using, say 4.2, to be able to find documentation for 4.2 without having to interpret a nest of if you have 4.x do this, if 5.0 through 5.3 do that, else do the other. I don't think it's a lot of work to just branch the handbook (and FAQ if we decide to keep it) - in fact, for me, it would be a definite win - at release time, but it just doesn't seem to be what other people want done. I would encourage those interested to ask about it on [EMAIL PROTECTED] Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpxdR4OjEBSb.pgp Description: PGP signature
Re: My wish list for 6.1
On Tue, 2005-12-20 at 14:22 +, Ceri Davies wrote: On Mon, Dec 19, 2005 at 10:34:23AM +0100, Dirk GOUDERS wrote: 3. Full review and update of the install docs, handbook, FAQ, etc. There are sections that are embarrassingly out of date (one section of the handbook apparently states that we only support a single brand of wifi cards). A co-worker of mine tried to install 6.0 using just the handbook install guide, and discovered that it really doesn't match reality anymore, in both big and small ways. Contact me directly if you would like his list of comments. I am wondering if it wouldn't be advantageous to have versioned documents that just cover one specific release and not to cover all realeases in single documents. I could imagine that it is harder to cover everything in single documents than to perhaps copy the existing documentation when a new branch is created and edit it to match just the new release. Maybe, I do not realize how much more work this would be but it would probably enforce regular reviews of the documentation and the readers would benefit from it. This is exactly the idea that I have been pimping to anyone who will listen for the last three months or so. I also think that it is advantageous for users who are using, say 4.2, to be able to find documentation for 4.2 without having to interpret a nest of if you have 4.x do this, if 5.0 through 5.3 do that, else do the other. I don't think it's a lot of work to just branch the handbook (and FAQ if we decide to keep it) - in fact, for me, it would be a definite win - at release time, but it just doesn't seem to be what other people want done. Yep, I really like this. The current mess is impossible to maintain (and also impossible to read). Yesterday I tried to update the kernel configuration chapter to cover 6.0, but I gave up since there are do this for 4.X, do that for 5.X, and maybe this too for 6.X everywhere. -- Joel - joel at FreeBSD dot org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mostly static binaries with crunchgen
On Tuesday 20 December 2005 06:41 am, Ceri Davies wrote: Adrian Steinmann's talk at EuroBSDcon regarding a single user SSH daemon for rescue purposes highlighted an interesting point regarding some binaries. The GEOM userland binaries such as gmirror, gstripe, etc. use dlopen() to load classes from /lib/geom and therefore cannot be statically linked and, by extension, cannot be crunched with crunchgen. Adrian mentioned that it would be useful if crunchgen(1) supported mostly static binaries; i.e., a libs_so extension to crunchgen which would allow these binaries to be crunched, simply requiring then that rtld and the libraries be made available on the memory disk. This allows those of us who use GEOM classes to make a small rescue disk. I started to add this to crunchgen on the way home, and have worked with Adrian to finish it off. The patch is attached. It simply adds a libs_so keyword which specifies libraries that will be linked statically; all current config files continue to produce the same code as they did before. I'd like to commit this with a 6 week MFC period or so, but my mentor is currently busy. Could someone else please take this up? I don't think you should change TORTIOUS to TORTUOUS in the license. Reading license disclaimers may indeed be tortuous, but tortious is an actual legal term, not a misspelling. It comes from the root word 'tort' which is a legal word for 'sue' (basically). The other concern is does this force the entire crunch to require a working rtld now? If so, that would mean that this wouldn't be appropriate for something such as /rescue. If there were a way to statically link rtld into the crunch itself that would probably be ideal, but I'm not sure that is possible. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
This is exactly the idea that I have been pimping to anyone who will listen for the last three months or so. I also think that it is advantageous for users who are using, say 4.2, to be able to find documentation for 4.2 without having to interpret a nest of if you have 4.x do this, if 5.0 through 5.3 do that, else do the other. I don't think it's a lot of work to just branch the handbook (and FAQ if we decide to keep it) - in fact, for me, it would be a definite win - at release time, but it just doesn't seem to be what other people want done. I would like to add that I could imagine that it would be easier for authors to just change/add some documentation that matches the target release and not to have to think about if version=something else ... constructs. Also, sometimes it is good to be able to just throw away things that are out-of-date. I would encourage those interested to ask about it on [EMAIL PROTECTED] Well, I would be surprised if that hasn't already been discussed. Have to search the archives... Dirk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
Yep, I really like this. The current mess is impossible to maintain (and also impossible to read). Yesterday I tried to update the kernel configuration chapter to cover 6.0, but I gave up since there are do this for 4.X, do that for 5.X, and maybe this too for 6.X everywhere. Seems as if my imagination was correct ;-) By the way, I tried to search the archive (doc@) for a possible earlier discussion of this subject but have a hard time to find proper words to search for... Dirk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mostly static binaries with crunchgen
On Tue, Dec 20, 2005 at 10:29:27AM -0500, John Baldwin wrote: On Tuesday 20 December 2005 06:41 am, Ceri Davies wrote: Adrian Steinmann's talk at EuroBSDcon regarding a single user SSH daemon for rescue purposes highlighted an interesting point regarding some binaries. The GEOM userland binaries such as gmirror, gstripe, etc. use dlopen() to load classes from /lib/geom and therefore cannot be statically linked and, by extension, cannot be crunched with crunchgen. Adrian mentioned that it would be useful if crunchgen(1) supported mostly static binaries; i.e., a libs_so extension to crunchgen which would allow these binaries to be crunched, simply requiring then that rtld and the libraries be made available on the memory disk. This allows those of us who use GEOM classes to make a small rescue disk. I started to add this to crunchgen on the way home, and have worked with Adrian to finish it off. The patch is attached. It simply adds a libs_so keyword which specifies libraries that will be linked statically; all current config files continue to produce the same code as they did before. I'd like to commit this with a 6 week MFC period or so, but my mentor is currently busy. Could someone else please take this up? I don't think you should change TORTIOUS to TORTUOUS in the license. Reading license disclaimers may indeed be tortuous, but tortious is an actual legal term, not a misspelling. It comes from the root word 'tort' which is a legal word for 'sue' (basically). Ah, I had parsed that as a whitespace change. Will revert :) The other concern is does this force the entire crunch to require a working rtld now? If so, that would mean that this wouldn't be appropriate for something such as /rescue. If there were a way to statically link rtld into the crunch itself that would probably be ideal, but I'm not sure that is possible. No, just the dynamic bits require rtld. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpsccv4pS7IO.pgp Description: PGP signature
Re: My wish list for 6.1
On Tue, Dec 20, 2005 at 03:46:53PM +0100, Joel Dahl wrote: On Tue, 2005-12-20 at 14:22 +, Ceri Davies wrote: This is exactly the idea that I have been pimping to anyone who will listen for the last three months or so. I also think that it is advantageous for users who are using, say 4.2, to be able to find documentation for 4.2 without having to interpret a nest of if you have 4.x do this, if 5.0 through 5.3 do that, else do the other. I don't think it's a lot of work to just branch the handbook (and FAQ if we decide to keep it) - in fact, for me, it would be a definite win - at release time, but it just doesn't seem to be what other people want done. Yep, I really like this. The current mess is impossible to maintain (and also impossible to read). Yesterday I tried to update the kernel configuration chapter to cover 6.0, but I gave up since there are do this for 4.X, do that for 5.X, and maybe this too for 6.X everywhere. Yes, that's my major concern. I find working on the current documents too difficult. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpOKAMKs1nL1.pgp Description: PGP signature
Re: Mostly static binaries with crunchgen
John Baldwin [EMAIL PROTECTED] writes: I don't think you should change TORTIOUS to TORTUOUS in the license. Reading license disclaimers may indeed be tortuous, but tortious is an actual legal term, not a misspelling. It comes from the root word 'tort' which is a legal word for 'sue' (basically). Uh, no. It's a legal word for harm, damage or injury. 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: Mostly static binaries with crunchgen
On Tuesday 20 December 2005 11:57 am, Dag-Erling Smørgrav wrote: John Baldwin [EMAIL PROTECTED] writes: I don't think you should change TORTIOUS to TORTUOUS in the license. Reading license disclaimers may indeed be tortuous, but tortious is an actual legal term, not a misspelling. It comes from the root word 'tort' which is a legal word for 'sue' (basically). Uh, no. It's a legal word for harm, damage or injury. Ok, reason for a civil suit (it's been a few years). -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mostly static binaries with crunchgen
On Tuesday 20 December 2005 10:58 am, Ceri Davies wrote: On Tue, Dec 20, 2005 at 10:29:27AM -0500, John Baldwin wrote: The other concern is does this force the entire crunch to require a working rtld now? If so, that would mean that this wouldn't be appropriate for something such as /rescue. If there were a way to statically link rtld into the crunch itself that would probably be ideal, but I'm not sure that is possible. No, just the dynamic bits require rtld. So you can still run /foo without rtld being present if foo doesn't need dlopen, etc.? It looks like you link the crunch with -o dynamic, so isn't the kernel going to complain when you try to exec it that it can't find rtld if rtld is missing? (Think about /rescue if your rtld is hosed and/or missing.) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD VGA Framebuffer
Hi I'm wondering if anyone knows if freebsd has a vga framebuffer? and how to use it? Cheers ~ Dale ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mostly static binaries with crunchgen
On Tue, Dec 20, 2005 at 01:43:58PM -0500, John Baldwin wrote: On Tuesday 20 December 2005 10:58 am, Ceri Davies wrote: On Tue, Dec 20, 2005 at 10:29:27AM -0500, John Baldwin wrote: The other concern is does this force the entire crunch to require a working rtld now? If so, that would mean that this wouldn't be appropriate for something such as /rescue. If there were a way to statically link rtld into the crunch itself that would probably be ideal, but I'm not sure that is possible. No, just the dynamic bits require rtld. So you can still run /foo without rtld being present if foo doesn't need dlopen, etc.? It looks like you link the crunch with -o dynamic, so isn't the kernel going to complain when you try to exec it that it can't find rtld if rtld is missing? (Think about /rescue if your rtld is hosed and/or missing.) Sorry, you're correct of course. It's still useful in Adrian's environment at least (because he puts rtld on an MFS). Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpru3o6Qts6M.pgp Description: PGP signature
Re: Mostly static binaries with crunchgen
On Tuesday 20 December 2005 04:31 pm, Ceri Davies wrote: On Tue, Dec 20, 2005 at 01:43:58PM -0500, John Baldwin wrote: On Tuesday 20 December 2005 10:58 am, Ceri Davies wrote: On Tue, Dec 20, 2005 at 10:29:27AM -0500, John Baldwin wrote: The other concern is does this force the entire crunch to require a working rtld now? If so, that would mean that this wouldn't be appropriate for something such as /rescue. If there were a way to statically link rtld into the crunch itself that would probably be ideal, but I'm not sure that is possible. No, just the dynamic bits require rtld. So you can still run /foo without rtld being present if foo doesn't need dlopen, etc.? It looks like you link the crunch with -o dynamic, so isn't the kernel going to complain when you try to exec it that it can't find rtld if rtld is missing? (Think about /rescue if your rtld is hosed and/or missing.) Sorry, you're correct of course. It's still useful in Adrian's environment at least (because he puts rtld on an MFS). One workaround for this case would be to have two crunches, one for the pure-static stuff and one for the dynamic-using stuff. Alternatively, if you had a way to statically link the rtld functions into the crunch you could still use just one crunch. I just want to make sure we don't go turning this on for /rescue since that needs to work if rtld is hosed (unless we go the route of two crunches). -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD VGA Framebuffer
В сообщении от Среда 21 Декабрь 2005 02:51 Dale DuRose написал(a): Hi I'm wondering if anyone knows if freebsd has a vga framebuffer? and how to use it? Cheers ~ Dale Yes and No - there is no framebuffer as it is in Linux, but if you want to have a better resolution in your console, see graphics and so on, try load VESA module and use vidcontrol with mode VESA_800x600. Read man vidcontrol for all this. Best regards, Bachilo Dmitry ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
error on first boot
hi all i'm new in freebsd, i've install freebsd 6.0, everything ok, but when i finish and start for my first boot, i've got error below: ad0:Failure-read_mul status=59ready,dsc,dkq,errorerror=40uncorrectablelba=12431 g_vfs_done():ad0s1a[(offset=6332416,lenght=32768)] error=5 vnode_pager_getpage:i/o read error. vm_fault : page read error,pid 57 (unit) dec 20 16 :01:03 init fatal signal : segmentation fault. any idea ? thank's alot __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD VGA Framebuffer
On Wed, Dec 21, 2005 at 09:51:24AM +1300, Dale DuRose wrote: Hi I'm wondering if anyone knows if freebsd has a vga framebuffer? and how to use it? Yes it has. It's sources are in /usr/src/dev/fb and there is no man page (at least on RELENG_4). Not sure it even exist in RELENG_[56]. -ip -- If there are only two shows worth watching, they will be on together. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem booting FreeBSD from cboot FreeBSD from cdrom using grubdrom using grub
Hi,
I'm trying to make an iso image that will boot FreeBSD using GRUB boot
loader.
Grub will boot /boot/loader and the loader will boot /boot/kernel. It
goes well on my disk, but when I try to make a livecd, it fails. I spend
some time figuring out that /boot/loader does not probe cd it self, it
depends on boot2 to tell him which cd to boot from. So I did some hack
on /boot/loader. Bellow is the diff:
*** sys/boot/i386/loader/main.c.bak Sun Dec 11 19:32:29 2005
--- sys/boot/i386/loader/main.c Sun Dec 11 22:04:29 2005
***
*** 228,235
if ((new_currdev.d_type == biosdisk.dv_type)
((new_currdev.d_kind.biosdisk.unit = bd_bios2unit(biosdev)) ==
-1)) {
printf(Can't work out which disk we are booting from.\n
! Guessed BIOS device 0x%x not found by probes, defaulting
to disk0:\n, biosdev);
! new_currdev.d_kind.biosdisk.unit = 0;
}
env_setenv(currdev, EV_VOLATILE, i386_fmtdev(new_currdev),
i386_setcurrdev, env_nounset);
--- 228,238
if ((new_currdev.d_type == biosdisk.dv_type)
((new_currdev.d_kind.biosdisk.unit = bd_bios2unit(biosdev)) ==
-1)) {
printf(Can't work out which disk we are booting from.\n
! Guessed BIOS device 0x%x not found by probes, defaulting
to cd0(%d):\n, biosdev, biosdev);
! bc_add(biosdev);
! new_currdev.d_type = bioscd.dv_type;
! new_currdev.d_dev = bioscd;
! new_currdev.d_kind.bioscd.unit = bc_bios2unit(biosdev);
}
env_setenv(currdev, EV_VOLATILE, i386_fmtdev(new_currdev),
i386_setcurrdev, env_nounset);
Then the kernel starts, but when the kernel try to mount the root fs, it
stops. I have the follow line in my /etc/fstab
/dev/acd0c / cd9660 ro 0 0
I am stranded. Can anyone help? I'm using FreeBSD 5.4
thanks
Tony
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD VGA Framebuffer
On Wed, 21 Dec 2005 07:51, Dale DuRose wrote: Hi Hello I'm wondering if anyone knows if freebsd has a vga framebuffer? and how to use it? You could look into KGI: http://kgi-wip.sourceforge.net/ http://people.freebsd.org/~nsouch/kgi4BSD/ There is patch set around for RELENG_6 from a few months ago. You have to build a new kernel with sources, setup LibGGI and give it ago. Cheers ~ Dale -Alastair ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
