Re: 8.x grudges
31.07.2010 01:17, Peter Jeremy написав(ла): kenv(1) (in the base) should as well. Cool! Here it is: smbios.bios.reldate=08/13/2003 smbios.bios.vendor=American Megatrends Inc. smbios.bios.version=3.13 smbios.chassis.maker=Chassis Manufacture smbios.chassis.serial=Chassis Serial Number smbios.chassis.tag=Asset-1234567890 smbios.chassis.version=Chassis Version smbios.memory.enabled=1048576 smbios.planar.maker=ASUSTeK Computer INC. smbios.planar.product=A7N8X-LA smbios.planar.serial=X312345678 smbios.planar.version=Rev 1.xx smbios.socket.enabled=1 smbios.socket.populated=1 smbios.system.maker= smbios.system.product= smbios.system.serial= smbios.system.uuid=00020003-0004-0005-0006-000700080009 smbios.system.version= smbios.version=2.3 Yours, -mi ___ 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: 8.x grudges
On 2010-Jul-29 16:50:24 +0200, Oliver Fromme o...@lurza.secnetix.de wrote: Install ports/sysutils/dmidecode and type (as root): # dmidecode -t system -t baseboard It will tell you the vendor and product name, among other things. kenv(1) (in the base) should as well. -- Peter Jeremy pgpbf8VH6Q3UB.pgp Description: PGP signature
Re: 8.x grudges
Mikhail T. mi+t...@aldan.algebra.com wrote: The motherboard version -- I'm not sure still. Something like nVidia nForce2 -- does that identify it enough? Install ports/sysutils/dmidecode and type (as root): # dmidecode -t system -t baseboard It will tell you the vendor and product name, among other things. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ 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: 8.x grudges
09.07.2010 05:49, Peter Jeremy ???(??): I doubt I'm personally in a position to debug this and don't personally use splash screens. Can you reproduce it using an image that you can re-distribute? Ok, the splash-screen problem went away after I put back the original video-card. The one I tried with (a high-end, but old) worked fine in text mode, but, apparently, had issues in the graphical mode... Retracted... 3. Likewise, having device ugen breaks config(8) -- another undocumented incompatibility. It was a valid device for FreeBSD-7. The UPDATING-file enumerates a number of things, that need to be changed, when updating to 8, but the removal of ugen is not mentioned there. Well, the definitive list is sys/conf/NOTES and sys/$(uname -m)/conf/NOTES The NOTES files are code, not documentation... If the UPDATING file did not exist, I'd be looking elsewhere for the changes. But it does exist and so should be complete (perhaps, it should be auto-generated based on the commit-history of the NOTES and GENERIC kernel-configs?) but I agree that the ugen(4) man page is incorrect and a case could be made for having better details of USB2 in UPDATING. I did not even realize, the ugen(4) still exists in 8.1 (and would've thought, it was a remnant from 7.x), if I saw it. My grudge was that the UPDATING file did not tell me about neither it, nor about the sio being broken. How would you like to write up patches and submit a PR? I have some -- much more involved -- patches sitting in the PR database for years, so, pardon me for not accepting your invitation to file more at this time... The ones most ripe for committing are: * handle SIGINFO in sleep(1) http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/139345 -- recent * pkg_add(1) pkg-routines ignore the recorded md5 checksums http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/34628 -- 8 years old * bikeshed entry of Handbook is wrong http://www.freebsd.org/cgi/query-pr.cgi?pr=docs/86342 -- a doc-one, 5 years old now, still valid... Search the PR-db for others, where a dialog/discussion might be necessary -- the above ones are only those completely ready... That's why I asked for the output up to the hang - which might show where the problem is. If you don't have a serial console, take a photo and put it up on the web. Ok, here is the screen-shot http://aldan.algebra.com/%7Emi/tmp/hung-1394-shot.png (firewire enabled in BIOS). Hanging while probing USB-devices... BTW, in all writing you've done, you've never mentioned what FreeBSD version you are running beyond a vague 8.1 prerelease, what motherboard you have (despite my request for this) and only indirectly given the architecture (via the config file you posted). Well, the version was also implied -- 8.1/prerelease as of (approximately) the date of the posting. The motherboard version -- I'm not sure still. Something like nVidia nForce2 -- does that identify it enough? The verbose dmesg.boots are: * 7.3-PRERELEASE Feb 5 http://aldan.algebra.com/%7Emi/tmp/quokka.dmesg.7.3.txt (firewire enabled -- no hang. This is one extracted from /var/log/messages and is a little garbled.) * 8.1-PRERELEASE July 5 http://aldan.algebra.com/%7Emi/tmp/quokka.dmesg.Jul-05.txt (firewire disabled -- otherwise hangs) * 8.1-PRERELEASE July 14 http://aldan.algebra.com/%7Emi/tmp/quokka.dmesg.Jul-14.txt (firewire disabled. Interestingly, the July 14th version reports slightly different memory base) Yours, -mi ___ 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: 8.x grudges
Hi, On Jul 28, 2010, at 11:41 PM, Mikhail T. wrote: 09.07.2010 05:49, Peter Jeremy ???(??): I doubt I'm personally in a position to debug this and don't personally use splash screens. Can you reproduce it using an image that you can re-distribute? Ok, the splash-screen problem went away after I put back the original video-card. The one I tried with (a high-end, but old) worked fine in text mode, but, apparently, had issues in the graphical mode... Retracted... 3. Likewise, having device ugen breaks config(8) -- another undocumented incompatibility. It was a valid device for FreeBSD-7. The UPDATING-file enumerates a number of things, that need to be changed, when updating to 8, but the removal of ugen is not mentioned there. Well, the definitive list is sys/conf/NOTES and sys/$(uname -m)/conf/NOTES The NOTES files are code, not documentation... If the UPDATING file did not exist, I'd be looking elsewhere for the changes. But it does exist and so should be complete (perhaps, it should be auto-generated based on the commit-history of the NOTES and GENERIC kernel-configs?) http://www.freebsd.org/doc/handbook/kernelconfig-config.html : For an exhaustive list of architecture dependent options and devices, see the NOTES file in the same directory as the GENERIC file. For architecture independent options, see /usr/src/sys/conf/NOTES. I duno if this is documentation or not .. the handbook states that this is a list :) Also I'm pretty sure there was an entry for the USB changes in UPDATING: 20090223: The new USB2 stack has now been permanently moved in and all kernel and module names reverted to their previous values (eg, usb, ehci, ohci, ums, ...). The old usb stack can be compiled in by prefixing the name with the letter 'o', the old usb modules have been removed. Updating entry 20090216 for xorg and 20090215 for libmap may still apply. There was a huge change for the GENERIC at this date (+29 -88 lines) so it's doesn't sound correct to document verbosely all of them in UPDATING. -cut- -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ 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: net-booting the install disks (Re: 8.x grudges)
On 12/07/2010 19:22, Marian Hettwer wrote: Hi Adam, Am 12.07.10 19:11, schrieb Adam Vande More: Automated installations have existed on FreeBSD for a long time. You can do this either via netboot or CD based media. Also rolling your own FreeBSD media with custom changes is trivial compared the linux distro's I'm familar with. I haven't used kickstart but I will say the FreeBSD method is easier to work with than the Debian FIA method. Plus there are many post-install configuration utilites like puppet to further automate stuff. I actually like the principle of FAI configspace that much, that a colleague of mine and myself ported the underlying FAI to OpenBSD. I tend to say, that configuring a server with FAI is way easier than with puppet. I'd love to pxeboot a minimal freebsd with a ramdisk and a base set of utilities to use FAI there too, however, my last attempts of doing that with FreeBSD failed. But your opinion may vary, of course :) This page is pretty well out of date, but the concepts remain the same. You can look at the work MFSBSD has done if you interested and there are more up to date howto floating around the www. humm... what is MFSBSD? http://mfsbsd.vx.sk/ (maybe also see http://www.freebsd.org/doc/en/articles/remote-install/preparation.html) Basicly a set of scripts to build a small customised bsd that can run from a memory backed disk (tftp bootable i believe.) I still haven't had an excuse to try it properly but it looks pretty cool. Vince Cheers, Marian ___ 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 ___ 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: net-booting the install disks (Re: 8.x grudges)
08.07.2010 09:53, Jeremy Chadwick написав(ла): Then don't modify loader.conf. Instead, once the Welcome to FreeBSD! portion of loader appears, press 6 to shell to the loader prompt and type: set vfs.root.mountfrom=ufs:/dev/md0 boot Yes, that works... It just should not be necessary. Red Hat's kickstart does not require one to extract CD-images to fiddle with a couple of lines, and FreeBSD comes tantalizingly close to offer the same functionality. Just not quite :-( -mi ___ 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: net-booting the install disks (Re: 8.x grudges)
08.07.2010 12:40, Jeremy Chadwick написав(ла): set vfs.root.mountfrom=ufs:/dev/md0 boot Yes, that works... It just should not be necessary. Okay, so let me get this straight. First the complaint was that you had to modify loader.conf, which involved extracting the CD image, editing the file, yadda yadda. Now that you've been shown you don't have to edit loader.conf, the complaint is it shouldn't be necessary.:-) No, I initially complained, that I had to fiddle with loader's options at boot-time (item 8 -- instead of setting mountfrom, I set init to sysinstall -- don't recall the exact syntax). You then claimed, that you /can't reproduce/ my problem -- and referred me to your instructions http://jdc.parodius.com/freebsd/pxeboot_serial_install_8.html (nice ones, BTW, even for those, who don't need serial-port install), where you explain, how to perform the install via netboot. I pointed out, that your recipe is not a valid counter-example, because -- instead of fiddling with loader's options at boot-time, you fiddle with the loader.conf (and have to extract the entire CD/DVD-image to do that one-line change). One way or the other, some -- very minor -- manual changes are required... It is, of course, an accepted fact, that installing (or upgrading) an OS would require fiddling, but this particular little aspect can be eliminated, I think... The bottom line: the PXE booting framework in FreeBSD could be improved. Even Randi would agree with this point, I think. I perfectly understand -- and am not complaining -- about substantial work not done in any particular area. It is the little things, that could've been done with negligible /marginal/ cost, that are my target. RedHat's kickstart http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/custom-guide/ch-kickstart2.html can do an entire install based on pre-configured rules. Implementing something like that for FreeBSD would, probably, take quite a bit of effort. But being able to just boot straight into install from a CD (or CD-image) across the LAN doesn't seem very complicated, considering, how close we already are... Yes, it is important to me. No, I can not do it myself. I do, what I can in my area of expertise. If this area is not being improved for lack of time/resources, then fine... But I don't think, that's the case, for it seems to me, that the developers, who can do this little improvement, simply don't see a need for it. Yours, -mi ___ 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: 8.x grudges
08.07.2010 17:06, Peter Jeremy написав(ла): On 2010-Jul-07 14:22:22 -0400, Mikhail T.mi+t...@aldan.algebra.com wrote: In no particular order: 1. A picture, that one of the systems was displaying at boot (and then used as a screen-saver), stopped showing properly. The colors are right, but the picture is distorted beyond recognition. The relevant part of loader.conf is: splash_pcx_load=YES vesa_load=YES bitmap_load=YES bitmap_name=/boot/187426-9-quokka-dreaming.pcx It's a bit difficult to provide any useful input without some idea of what the picture should and does look like. Can you please post the actual bitmap as well as a picture of your screen showing the problem. I don't want to post it publicly for copyright reasons. I can e-mail it to you (or anyone else) directly, though. 3. Likewise, having device ugen breaks config(8) -- another undocumented incompatibility. Can you please advise where it is documented that device ugen is valid in a FreeBSD-8 config file? It was a valid device for FreeBSD-7. The UPDATING-file enumerates a number of things, that need to be changed, when updating to 8, but the removal of ugen is not mentioned there. 5. One of the upgraded systems would repeatedly hang at boot, until I disabled the on-board firewire-device through the BIOS... It was not a problem under 7.x, although I don't know, whether the device actually worked. I haven't seen this on any of my systems. Can you please provide details of your motherboard, BIOS and the output from a verbose boot up to the hang. Is there a BIOS update available and have you tried installing it? No BIOS updates :-( I can e-mail boot's output to you directly (please, confirm interest). It would be with the device disabled though, because the boot never completes, if it is enabled. 6. Despite the reported improvements in the USB area, my USB keyboard /still/ does not work during boot. It during POST and then after the booting is complete. But in single-user mode -- no... Had to fish-out the PS2 keyboard... I have had similar problems on one of my USB-only desktops. In my case, moving the keyboard to a different USB port solved the problem. All I can suggest is to work your way through all the USB ports you have available and see if they all behavee the same. I'll try that next time I reboot this system. Thanks, -mi ___ 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: 8.x grudges
08.07.2010 17:36, Lucas Holt написав(ла): Most of us work on open source for free in our own time, and it's impossible to test every possible configuration before a release. I tested several particular configurations -- on several machines -- and reported the overlooked issues. I didn't write a pamphlet, and I didn't post it to Slashdot as evidence of BSD is dying -- I reported it to the developers. No need to get defensive -- or call it rant. Whoever is in a position to fix a particular problem, can now do that... -mi ___ 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: net-booting the install disks (Re: 8.x grudges)
On Thu, Jul 8, 2010 at 1:28 PM, Mikhail T. mi+t...@aldan.algebra.commi%2bt...@aldan.algebra.com wrote: RedHat's kickstart http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/custom-guide/ch-kickstart2.html can do an entire install based on pre-configured rules. Implementing something like that for FreeBSD would, probably, take quite a bit of effort. But being able to just boot straight into install from a CD (or CD-image) across the LAN doesn't seem very complicated, considering, how close we already are... Automated installations have existed on FreeBSD for a long time. You can do this either via netboot or CD based media. Also rolling your own FreeBSD media with custom changes is trivial compared the linux distro's I'm familar with. I haven't used kickstart but I will say the FreeBSD method is easier to work with than the Debian FIA method. Plus there are many post-install configuration utilites like puppet to further automate stuff. This page is pretty well out of date, but the concepts remain the same. You can look at the work MFSBSD has done if you interested and there are more up to date howto floating around the www. http://www.freebsd.org/doc/en/articles/pxe/article.html You can find a sample install.cfg at /usr/src/usr.sbin/sysinstall/install.cfg Roll it into your media and make sure sysinstall is configed to use it. It's really that simple. There may certain aspects of this type of thing which make it more complicated, like installing custom packages, FW setup, etc. but the framework is simpler than many other OS's IMO. -- Adam Vande More ___ 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: net-booting the install disks (Re: 8.x grudges)
12.07.2010 13:11, Adam Vande More wrote: Roll it into your media You lost me right here... Rolling one's own media (for every release and release-candidate) may be Ok for someone in charge of making, at least, several installations per week. For someone like myself, who just wanted to use a downloaded CD-image straight (without burning it first), there is got to be a way to use the FreeBSD-distributed images... I'm not asking for the full power offered by kickstart et al, I just want the booting image to be a little bit smarter than it already is and do The Right Thing^TM regardless of whether it is booting from the local CD-ROM or remotely. Yours, -mi ___ 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: net-booting the install disks (Re: 8.x grudges)
Hi Adam, Am 12.07.10 19:11, schrieb Adam Vande More: Automated installations have existed on FreeBSD for a long time. You can do this either via netboot or CD based media. Also rolling your own FreeBSD media with custom changes is trivial compared the linux distro's I'm familar with. I haven't used kickstart but I will say the FreeBSD method is easier to work with than the Debian FIA method. Plus there are many post-install configuration utilites like puppet to further automate stuff. I actually like the principle of FAI configspace that much, that a colleague of mine and myself ported the underlying FAI to OpenBSD. I tend to say, that configuring a server with FAI is way easier than with puppet. I'd love to pxeboot a minimal freebsd with a ramdisk and a base set of utilities to use FAI there too, however, my last attempts of doing that with FreeBSD failed. But your opinion may vary, of course :) This page is pretty well out of date, but the concepts remain the same. You can look at the work MFSBSD has done if you interested and there are more up to date howto floating around the www. humm... what is MFSBSD? Cheers, Marian ___ 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: net-booting the install disks (Re: 8.x grudges)
Am 12.07.10 19:37, schrieb Mikhail T.: 12.07.2010 13:11, Adam Vande More wrote: Roll it into your media You lost me right here... Rolling one's own media (for every release and release-candidate) may be Ok for someone in charge of making, at least, several installations per week. For someone like myself, who just wanted to use a downloaded CD-image straight (without burning it first), there is got to be a way to use the FreeBSD-distributed images... I'm not asking for the full power offered by kickstart et al, I just want the booting image to be a little bit smarter than it already is and do The Right Thing^TM regardless of whether it is booting from the local CD-ROM or remotely. hm, I second that. While I fully understand that the iso images purpose is _not_ doing a netinstall, I'd like to have a downloadable image which is easy pxebootable and just drops into a shell. Ideally it does a dhcp request, if successful starts a sshd and if not has video and serial output enabled. Did anybody actually stripped down a FreeBSD to do just that? I read my way through the pxeboot articles and the handbook section of netbooting and everything... however, it really sounds a bit overcomplicated to do a make release and stuff. No offense ment, obviously :) best, Marian ___ 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: net-booting the install disks (Re: 8.x grudges)
On Mon, 12 Jul 2010, Marian Hettwer wrote: While I fully understand that the iso images purpose is _not_ doing a netinstall, I'd like to have a downloadable image which is easy pxebootable and just drops into a shell. Ideally it does a dhcp request, if successful starts a sshd and if not has video and serial output enabled. Did anybody actually stripped down a FreeBSD to do just that? I read my way through the pxeboot articles and the handbook section of netbooting and everything... however, it really sounds a bit overcomplicated to do a make release and stuff. No offense ment, obviously :) Not that I've done it (yet), but NanoBSD looks like it would handle the stripping-down part and setting up the md devices pretty painlessly. The only part that remains would be to customize the booting process, which shouldn't be terrible. It's possible to take the livefs memstick image and remove some of the parts that are not needed. But you'll also have to modify the mfsroot image to add /etc, /bin, /sbin, /usr, and by the time that's all done, NanoBSD is likely the easier path. ___ 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: 8.x grudges
In message: aanlktikdj39liaffibdwkfa1vgt4w7m8toxevjykh...@mail.gmail.com
Garrett Cooper yanef...@gmail.com writes:
: On Wed, Jul 7, 2010 at 1:17 PM, Mikhail T. mi+t...@aldan.algebra.com wrote:
: 07.07.2010 14:59, Jeremy Chadwick ???(??):
:
: FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and
: thus not an option) -- the kernel-config files, that worked with
: 7.x, break without this option in them (in addition to all the
: nuisance, that's documented in UPDATING -- which, somehow, makes
: the breakage acceptable). config(8) would not warn about this, but
: kernel build fails.
:
:
: We don't use this option (meaning it's removed from our kernels). It's
: definitely not required. All it does is ensure your kernel can
: comprehend executables/binaries built on 7.x.
:
:
: Attached is the kernel config-file (i386), that worked fine under 7.x. The
: kernel-compile will break (some *freebsd7* structs undefined), without the
: COMPAT_FREEBSD7 option. Try it for yourself...
:
: options SYSVSHM # SYSV-style shared memory
: options SYSVMSG # SYSV-style message queues
: options SYSVSEM # SYSV-style semaphores
:
: Those require COMPAT_FREEBSD7. This does seem like a bug:
:
: static struct syscall_helper_data shm_syscalls[] = {
: SYSCALL_INIT_HELPER(shmat),
: SYSCALL_INIT_HELPER(shmctl),
: SYSCALL_INIT_HELPER(shmdt),
: SYSCALL_INIT_HELPER(shmget),
: #if defined(COMPAT_FREEBSD4) || defined(COMPAT_FREEBSD5) || \
: defined(COMPAT_FREEBSD6) || defined(COMPAT_FREEBSD7)
: SYSCALL_INIT_HELPER(freebsd7_shmctl),
: #endif
:
: The check should be for COMPAT_FREEBSD7 only I would think.
:
: Apart from that, everything else should work without it I would think.
You would think that, but you'd be wrong.
In general, if you have COMPAT_FREEBSDx defined, you need all
COMPAT_FREEBSDy for y x defined.
The reason for this is that we name the compat shim for the version
where it was removed, but it is needed for all prior versions.
freebsd7_shmctl is needed to emulate the earlier versions as well...
This is why we'd like to move to something more like
COMPAT_MIN_FREEBSD=z, but there's hooks into the config system and
syscall tables that make it tricky...
Warner
___
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: net-booting the install disks (Re: 8.x grudges)
On Thu, Jul 08, 2010 at 11:08:04AM -0400, Mikhail T. wrote:
08.07.2010 09:53, Jeremy Chadwick напиÑаÐ=²(ла):
Then don't modify loader.conf. Instead, once the Welcome to FreeBSD!=
portion of loader appears, press 6 to shell to the loader prompt
and type:
set vfs.root.mountfrom=ufs:/dev/md0
boot
Yes, that works... It just should not be necessary.
Okay, so let me get this straight. First the complaint was that you had
to modify loader.conf, which involved extracting the CD image, editing
the file, yadda yadda. Now that you've been shown you don't have to
edit loader.conf, the complaint is it shouldn't be necessary. :-)
There's actually quite a bit about FreeBSD that shouldn't be necessary
(from an administrator's point of view), but that's a
completely separate issue when compared to your when I do thing X in
the kernel config, it breaks. Which of those two approaches do you
want to focus on?
Red Hat's kickstart does not require one to extract CD-images to
fiddle with a couple of lines, and FreeBSD comes tantalizingly close
to offer the same functionality. Just not quite :-(
I've PXE booted Ubuntu and Debian. It was easy to accomplish (read:
easier than FreeBSD) because they offer pxelinux vs. FreeBSD's pxeboot.
pxelinux[1] offers the ability to read a configuration file via TFTP,
which configures pxelinux itself. The configuration capabilities are
very impressive[2]. FreeBSD folks interested in PXE should really take
a look at this thing. I believe the configuration file is read and
applied immediately, so things like serial port speed changes happen
before pxelinux outputs anything (e.g. no need to rebuild pxelinux just
to get a faster rate).
That said, given that FreeBSD's pxeboot requires a bunch of extra work
(rebuilding for faster serial speed, and a bunch of other stuff -- it's
in my doc), I'm a surprised you're not complaining about that. :-)
The bottom line: the PXE booting framework in FreeBSD could be improved.
It has been improved, though not the documentation :-(
you can configure most of the stuff via DHCP, take a look
at src/lib/libstand/bootp.c
example lines from dhcpd.conf:
option FBSD.ind0 hint.uart.0.flags=0x10
option FBSD.ind1 kern.ipc.semmni=256
option FBSD.ind2 kern.ipc.semmns=2048
and with this code in rc.initdiskless:
confpath=`kenv conf-path`
if [ -n $confpath ] ; then
if [ `expr $confpath : '\(.*\):'` ] ; then
echo Mounting $confpath on /conf
mount_nfs $confpath /conf
chkerr $? mount_nfs $confpath /conf
to_umount=${to_umount} $confpath
fi
fi
eval `kenv | sed -n 's/^rc\.//p'`
rm -f /etc/rc.conf /etc/rc.conf.local
for fc in $conf0 $conf1 $conf2 $conf3 $conf4 $conf5 $conf6 $conf7 $conf8
$conf9 rc.conf.$hostname
do
ho=`expr $fc : '\(.*\):'`
fl=`expr $fc : '.*/\(.*\)'`
if [ ${ho} != ]; then
mp=`expr $fc : '\(.*\)/.*'`
mount_nfs $mp /mnt /dev/null 21
if [ -f /mnt/$fl ]; then
echo # from $fc /mnt/$fl /etc/rc.conf
cat /mnt/$fl /etc/rc.conf
fi
umount /mnt /dev/null 21
elif [ -e /conf/$fc ] ; then
echo # from /conf/$fc /etc/rc.conf
cat /conf/$fc /etc/rc.conf
fi
done
and these lines in dhcpd.conf
option FBSD.conf-path=fr-01:/vol/system/share/conf
option FBSD.rc-conf3 rc.ws8
...
will generate a 'personalized' rc.conf
danny
PS: this is not the first time I have posted this.
[...]
___
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: 8.x grudges
On 2010-Jul-08 18:10:48 -0400, Mikhail T. mi+t...@aldan.algebra.com wrote: 08.07.2010 17:06, Peter Jeremy написав(ла): On 2010-Jul-07 14:22:22 -0400, Mikhail T.mi+t...@aldan.algebra.com wrote1. A picture, that one of the systems was displaying at boot (and then used as a screen-saver), stopped showing properly. The colors are right, but the picture is distorted beyond recognition. I don't want to post it publicly for copyright reasons. I can e-mail it to you (or anyone else) directly, though. I doubt I'm personally in a position to debug this and don't personally use splash screens. Can you reproduce it using an image that you can re-distribute? 3. Likewise, having device ugen breaks config(8) -- another undocumented incompatibility. It was a valid device for FreeBSD-7. The UPDATING-file enumerates a number of things, that need to be changed, when updating to 8, but the removal of ugen is not mentioned there. Well, the definitive list is sys/conf/NOTES and sys/$(uname -m)/conf/NOTES but I agree that the ugen(4) man page is incorrect and a case could be made for having better details of USB2 in UPDATING. How would you like to write up patches and submit a PR? 5. One of the upgraded systems would repeatedly hang at boot, until I disabled the on-board firewire-device through the BIOS... It was No BIOS updates :-( I can e-mail boot's output to you directly (please, confirm interest). It would be with the device disabled though, because the boot never completes, if it is enabled. That's why I asked for the output up to the hang - which might show where the problem is. If you don't have a serial console, take a photo and put it up on the web. 6. Despite the reported improvements in the USB area, my USB keyboard /still/ does not work during boot. It during POST and then after I have had similar problems on one of my USB-only desktops. In my case, moving the keyboard to a different USB port solved the problem. All I can suggest is to work your way through all the USB ports you have available and see if they all behavee the same. I'll try that next time I reboot this system. Thanks, I'm not sure if you can actually move the keyboard and have it re-probe until the system is fully up. You might have to reset after you move the keyboard. BTW, in all writing you've done, you've never mentioned what FreeBSD version you are running beyond a vague 8.1 prerelease, what motherboard you have (despite my request for this) and only indirectly given the architecture (via the config file you posted). -- Peter Jeremy pgpvhRewGP7zw.pgp Description: PGP signature
Re: 8.x grudges
Am 07.07.10 22:52, schrieb Mikhail T.: 07.07.2010 16:34, Randi Harper ???(??): Attached is the kernel config-file (i386), that worked fine under 7.x. The kernel-compile will break (some *freebsd7* structs undefined), without the COMPAT_FREEBSD7 option. Try it for yourself... Don't use a kernel config from 7. We've already told you this. Your telling me this is just as valid as warning me against using computer-cases of a particular color. It is a silly requirement. My expecting things, that worked for 7, to work in 8 is reasonable. There may be (documented!) exceptions, but it ought to just work. No. Your expectation is plain wrong. The opposite should be true. If you do a major upgrade (and moving from 7.x to 8 is a major upgrade) you should expect all kinds of changes. What you can expect is, that they're documented in the release notes. This would be a fine gesture of the FreeBSD community. And since I use FreeBSD since 4.0, I can tell, that the documentation of changes is remarkable. If you expect that things continue to work after a major upgrade you really live in some kind of a dreamworld... These changes aren't gratuitous. Did you read the commit messages behind each of the changes? I'm guessing that you haven't. No, and I'm not going to. A commercial OS would've been the laughing stock, if one hand to change C: to 1: between releases, for example... Ah! But changing the $HOME of users of that commercial OS from c:\Documents and Settings\ to c:\Users is okay, right? Wake up man! Again: this particular change seems gratuitous. It's not. You didn't bother researching before complaining. I bothered to type up my list. Presumably, problem-reports are welcome. I've been a Unix-user since 1990, a FreeBSD user since 1993 (or 94?), and a project-member for a decade. If *I* have a problem, then newer users certainly will too. And, guess what, they'll simply go with something, that does not give as much grief... Then they should do. pfff... I'd like to see them using Linux, which obviously never changes arbitrary... ha. And if you're a unix user since the 1990'ies then you really should know better. The modification should be necessary. Why? Why should a netboot act differently from a local boot from CD? Because it's a completely different type of booting? Oh come one... You don't. But there is very little, that needs to be added there for it to just work over both netboot and local CD, and you should do it, instead of arguing with me here... No, I don't know, what it is exactly, but I'm quite certain, it can't be very much. If it's that important to you, then send in a patch. As a FreeBSD user since 1993 (or 94) you could do your beloved OS a favor, right? In fact, the article about PXE booting on the official freebsd website says nothing about using the ISO. You just found some article that said it was possible (and it is) and complained because you didn't like the process? Yes, exactly. I didn't like process -- it is needlessly complicated. The same CD-image, /should/ also be usable out of the box for netbooting. Then make it work, for f*cks sake! From the man page: The amdtemp driver provides support for the on-die digital thermal sensor present in AMD K8, K10 and K11 processors. I know nothing about the driver. But a utility I regularly used stopped working after upgrade, so I added that to my list of upgrade-related grudges. As an old fashioned unix guru you should know lots and lots about the driver. Or at least, as a minimum, you should be aware of the available manpage for a utility you're using regularly! Cheers! ./Marian ___ 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
net-booting the install disks (Re: 8.x grudges)
07.07.2010 14:30, Randi Harper написав(ла):
8.
I tried to do an install on one of the systems via netbooting
(pxeload) the disk1-image. It booted, but the sysinstall had to be
started manually and, once started, did not act the same as when
booted off of CD-ROM. Seems like a simple bit to correct so that
setting init to/usr/sbin/sysinstall/manually on every boot/ is
not necessary...
This shouldn't be the case. IIRC, nothing has changed that would cause
this. More info on your environment please?
Well, I never tried /this/ part before, so I'm not claiming, there is
/re/gression here. Just lack of /pro/gress :-)
I have the following special entry in the dhcpd.conf:
subnet 192.168.1.0 netmask 255.255.255.0 {
range dynamic-bootp 192.168.1.150 192.168.1.186;
next-server 192.168.1.140;
option broadcast-address 192.168.1.255;
option routers 192.168.1.1;
option root-path 192.168.1.140:/cdrom;
filenamepxeboot;
}
The filesystem accessible as /cdrom was an md-accessed
FreeBSD-8.1-RC1-i386-disc1.iso (or bootonly). Can't easily recreate
this, because the netbooting machine has now gone back to its owner.
The problem did not surprise me, because I followed (loosely) the
instructions
http://www.freebsdwiki.net/index.php/Installing_FreeBSD_with_netboot,
where it was mentioned -- along with a work-around. If some simple logic
can be put into the boot-image to allow it to do the right thing without
manual fiddling, it would be great. Thanks!
-mi
___
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: net-booting the install disks (Re: 8.x grudges)
07.07.2010 16:00, Randi Harper написав(ла): So you're complaining that you have to modify the loader.conf? I fail to see the problem. This is by design, and isn't a lack of progress. Yes, I complain, that I have to modify a loader.conf embedded in a CD-image. If extracting hundreds of mega-bytes of files to make a one-line modification is by design, then the design is flawed. Especially, when the effect achieved by the one-line modification can be arrived to automatically -- without such modifications. Yours, -mi ___ 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: 8.x grudges
07.07.2010 16:50, Marcel Moolenaar написав(ла): Not to mention that if you change uart(4) to create dev entries like sio(4) after uart(4) has been in the tree for more than 6 years creating ttyu* entries, you actually introduce a gratuitous change. If sio and uart could co-exist, then you'd be right. But sio no longer builds under 8.x, so some kind of aliasing (either by uart itself or by devfs) would be useful. -mi ___ 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: 8.x grudges
On Jul 7, 2010, at 5:39 PM, Garrett Cooper wrote:
On Wed, Jul 7, 2010 at 1:17 PM, Mikhail T. mi+t...@aldan.algebra.com wrote:
07.07.2010 14:59, Jeremy Chadwick ???(??):
FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and
thus not an option) -- the kernel-config files, that worked with
7.x, break without this option in them (in addition to all the
nuisance, that's documented in UPDATING -- which, somehow, makes
the breakage acceptable). config(8) would not warn about this, but
kernel build fails.
We don't use this option (meaning it's removed from our kernels). It's
definitely not required. All it does is ensure your kernel can
comprehend executables/binaries built on 7.x.
Attached is the kernel config-file (i386), that worked fine under 7.x. The
kernel-compile will break (some *freebsd7* structs undefined), without the
COMPAT_FREEBSD7 option. Try it for yourself...
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores
Those require COMPAT_FREEBSD7.
I have an FreeBSD/amd64 8.1-PRERELEASE system with all COMPAT_FREEBSDx options
except COMPAT_FREEBSD32 commented out in my kernel config file and it builds
fine. So, unless I am misunderstanding you, I don't think options
SYSV{SHM,MSG,SEM} requires COMPAT_FREEBSD7.
Cheers,
Paul.
___
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: 8.x grudges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/08/2010 06:54, for whatever Marian Hettwer wrote: With any major upgrade or release process comes a commitment from the developers and end-users alike that involves a review, testing release. The release part on the end-users behalf is simply a commitment to follow through make needed changes to what has been reviewed and tested continue with the current use accepting the changes. Taking a guess here, but you are probably a manager in a company that is asking you to cut back your test environment because it is hard for you to maintain with a under staffed under knowledged IT department resulting in a non-efficient budget that could end up in more staff being cut. Personally even if the above is not true I would fire you and keep a few more testbeds, just for wasting a free projects developers time by posting non nonsensical radical somewhat fascist views on this list. Everyone has a bad day once in a while but using a troll type manor while ranting and raving obnoxiously instead of getting involved appropriately is unacceptable and will not solve your problem. - -- I say things as they are. Slackers are called slackers, people who can't read manual pages are called losers, and in general, calling things what they are results in developers wasting less time. -- Theo +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBAgAGBQJMNcivAAoJEJBXh4mJ2FR+h68H/1mw7n4/KpDvzDxa8MACUMYI 9lQGKvKIjm2IrOfWlTpnoOAJOYKmsEE2b9fKht0376z1tze/tssNLkFD0CLZt+NK +Vyt7kraqyv6vn85ZQjLU1OD1z8XAOwVI1EMHusGaJi8VfscLerT1rIDplc1hfFt uH5GYnvepyqxKxtB9a2+eXwyjuz/dlfx4Dj8TvhdbfF9Ge5HuzWZcb4xzCIYPeIA KSrqxbOn5bpgiOW4i83hUT88Ntl7ZTw83UfnsiFOPQmtlzfQorc8QOF+gdjGAsG+ k4AuNoo4fBKbu50kSLO4hf+dccIga3Y3a5P2iwS+ANXbsHs9PcSNZ8p35Tk0MM8= =0IA0 -END PGP SIGNATURE- ___ 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: net-booting the install disks (Re: 8.x grudges)
On Wed, 7 Jul 2010, Mikhail T. wrote: 07.07.2010 16:00, Randi Harper ???(??): So you're complaining that you have to modify the loader.conf? I fail to see the problem. This is by design, and isn't a lack of progress. Yes, I complain, that I have to modify a loader.conf embedded in a CD-image. If extracting hundreds of mega-bytes of files to make a one-line modification is by design, then the design is flawed. Especially, when the effect achieved by the one-line modification can be arrived to automatically -- without such modifications. There's a hole in the bucket .. ___ 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: net-booting the install disks (Re: 8.x grudges)
On Wed, Jul 07, 2010 at 04:29:14PM -0400, Mikhail T. wrote: 07.07.2010 16:00, Randi Harper написав(ла): So you're complaining that you have to modify the loader.conf? I fail to see the problem. This is by design, and isn't a lack of progress. Yes, I complain, that I have to modify a loader.conf embedded in a CD-image. If extracting hundreds of mega-bytes of files to make a one-line modification is by design, then the design is flawed. Especially, when the effect achieved by the one-line modification can be arrived to automatically -- without such modifications. Then don't modify loader.conf. Instead, once the Welcome to FreeBSD! portion of loader appears, press 6 to shell to the loader prompt and type: set vfs.root.mountfrom=ufs:/dev/md0 boot If you want me to test/verify that this works, I can do so when I get home in about an hour (I do have a PXE boot environment set up for testing). If it does work (I don't see why it wouldn't), your next question will be then why doesn't your doc tell me to do it that way?, which I can answer as well: I based a small portion of my written documentation on what others had written. Many of the other docs advocated doing the same, particularly for setting serial port speed, comconsole, blah blah (because there is no /boot.config used in this boot environment, so you can't do something like add -S115200 -Dh to that file). I chose to continue using that nomenclature. -- | Jeremy Chadwick j...@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-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: 8.x grudges
Hi jhell, ehm... Am 08.07.10 14:46, wrote jhell: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/08/2010 06:54, for whatever Marian Hettwer wrote: I certainly not wrote the text below. That's what, I guess, you wrote. Your MUA is defect. And honestly, I don't know why that's a reply to my email (which you completely deleted, apart from the On 07/08/2010 06:54, for whatever Marian Hettwer wrote) thingy.. confused, Marian PS.: I guess your Mail should have been a reply to someone else's mail?! With any major upgrade or release process comes a commitment from the developers and end-users alike that involves a review, testing release. The release part on the end-users behalf is simply a commitment to follow through make needed changes to what has been reviewed and tested continue with the current use accepting the changes. Taking a guess here, but you are probably a manager in a company that is asking you to cut back your test environment because it is hard for you to maintain with a under staffed under knowledged IT department resulting in a non-efficient budget that could end up in more staff being cut. Personally even if the above is not true I would fire you and keep a few more testbeds, just for wasting a free projects developers time by posting non nonsensical radical somewhat fascist views on this list. Everyone has a bad day once in a while but using a troll type manor while ranting and raving obnoxiously instead of getting involved appropriately is unacceptable and will not solve your problem. - -- I say things as they are. Slackers are called slackers, people who can't read manual pages are called losers, and in general, calling things what they are results in developers wasting less time. -- Theo +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBAgAGBQJMNcivAAoJEJBXh4mJ2FR+h68H/1mw7n4/KpDvzDxa8MACUMYI 9lQGKvKIjm2IrOfWlTpnoOAJOYKmsEE2b9fKht0376z1tze/tssNLkFD0CLZt+NK +Vyt7kraqyv6vn85ZQjLU1OD1z8XAOwVI1EMHusGaJi8VfscLerT1rIDplc1hfFt uH5GYnvepyqxKxtB9a2+eXwyjuz/dlfx4Dj8TvhdbfF9Ge5HuzWZcb4xzCIYPeIA KSrqxbOn5bpgiOW4i83hUT88Ntl7ZTw83UfnsiFOPQmtlzfQorc8QOF+gdjGAsG+ k4AuNoo4fBKbu50kSLO4hf+dccIga3Y3a5P2iwS+ANXbsHs9PcSNZ8p35Tk0MM8= =0IA0 -END PGP SIGNATURE- ___ 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 ___ 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: net-booting the install disks (Re: 8.x grudges)
On Thu, Jul 08, 2010 at 11:08:04AM -0400, Mikhail T. wrote: 08.07.2010 09:53, Jeremy Chadwick написав(ла): Then don't modify loader.conf. Instead, once the Welcome to FreeBSD! portion of loader appears, press 6 to shell to the loader prompt and type: set vfs.root.mountfrom=ufs:/dev/md0 boot Yes, that works... It just should not be necessary. Okay, so let me get this straight. First the complaint was that you had to modify loader.conf, which involved extracting the CD image, editing the file, yadda yadda. Now that you've been shown you don't have to edit loader.conf, the complaint is it shouldn't be necessary. :-) There's actually quite a bit about FreeBSD that shouldn't be necessary (from an administrator's point of view), but that's a completely separate issue when compared to your when I do thing X in the kernel config, it breaks. Which of those two approaches do you want to focus on? Red Hat's kickstart does not require one to extract CD-images to fiddle with a couple of lines, and FreeBSD comes tantalizingly close to offer the same functionality. Just not quite :-( I've PXE booted Ubuntu and Debian. It was easy to accomplish (read: easier than FreeBSD) because they offer pxelinux vs. FreeBSD's pxeboot. pxelinux[1] offers the ability to read a configuration file via TFTP, which configures pxelinux itself. The configuration capabilities are very impressive[2]. FreeBSD folks interested in PXE should really take a look at this thing. I believe the configuration file is read and applied immediately, so things like serial port speed changes happen before pxelinux outputs anything (e.g. no need to rebuild pxelinux just to get a faster rate). That said, given that FreeBSD's pxeboot requires a bunch of extra work (rebuilding for faster serial speed, and a bunch of other stuff -- it's in my doc), I'm a surprised you're not complaining about that. :-) The bottom line: the PXE booting framework in FreeBSD could be improved. Even Randi would agree with this point, I think. But the question then becomes: what can you bring to the table which can help improve the situation? If you have the skills to help improve the situation, please help. By making it better for yourself, you can help make it better for everyone; a win-win situation. Anyway, your list of irritations when upgrading from 7.x to 8.x are mainly opinions -- and that's okay. I don't necessarily have a problem with your opinions, despite some being inaccurate or wrong; nothing wrong with being wrong! I'm not being sarcastic when I say I *do* appreciate the feedback you've provided (the method of approach is similar to how I go about things; I've quite a big list of WTFs when it comes to software in general), but you need to be reasonable and focus on a compromise. I think the community wants to help you but you definitely want things a certain way or have a lot of pre-conceived notions regarding what kernel or userland pieces should or should not change. That's just not a realistic way to approach computing these days. So like I said: things change. It's very hard to keep up with all the changes between major FreeBSD releases. The longevity of your use of FreeBSD doesn't matter -- I go back to the 2.2.x days. The difference between 2.x and 8.x is immense, and I'm talking on *all* levels. I had to adapt too, and it takes time to get familiar with all the changes. So please be a bit flexible and we'll do our best to help you fix what's broken *and* help you understand why things are different. [1]: http://syslinux.zytor.com/wiki/index.php/PXELINUX [2]: http://syslinux.zytor.com/wiki/index.php/SYSLINUX#How_do_I_Configure_SYSLINUX.3F (Not a typo; the pxelinux =~ syslinux, same options. See [1], section What is PXELINUX for validation) -- | Jeremy Chadwick j...@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-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: 8.x grudges
On 07/08/2010 10:08, Marian Hettwer wrote: Hi jhell, ehm... Am 08.07.10 14:46, wrote jhell: On 07/08/2010 06:54, for whatever Marian Hettwer wrote: I certainly not wrote the text below. That's what, I guess, you wrote. Your MUA is defect. And honestly, I don't know why that's a reply to my email (which you completely deleted, apart from the On 07/08/2010 06:54, for whatever Marian Hettwer wrote) thingy.. confused, Marian PS.: I guess your Mail should have been a reply to someone else's mail?! Yeah... that was not intended to go to you. ugh! ;( -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ ___ 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: 8.x grudges
On 2010-Jul-07 14:22:22 -0400, Mikhail T. mi+t...@aldan.algebra.com wrote: In no particular order: 1. A picture, that one of the systems was displaying at boot (and then used as a screen-saver), stopped showing properly. The colors are right, but the picture is distorted beyond recognition. The relevant part of loader.conf is: splash_pcx_load=YES vesa_load=YES bitmap_load=YES bitmap_name=/boot/187426-9-quokka-dreaming.pcx It's a bit difficult to provide any useful input without some idea of what the picture should and does look like. Can you please post the actual bitmap as well as a picture of your screen showing the problem. 3. Likewise, having device ugen breaks config(8) -- another undocumented incompatibility. Can you please advise where it is documented that device ugen is valid in a FreeBSD-8 config file? 5. One of the upgraded systems would repeatedly hang at boot, until I disabled the on-board firewire-device through the BIOS... It was not a problem under 7.x, although I don't know, whether the device actually worked. I haven't seen this on any of my systems. Can you please provide details of your motherboard, BIOS and the output from a verbose boot up to the hang. Is there a BIOS update available and have you tried installing it? 6. Despite the reported improvements in the USB area, my USB keyboard /still/ does not work during boot. It during POST and then after the booting is complete. But in single-user mode -- no... Had to fish-out the PS2 keyboard... I have had similar problems on one of my USB-only desktops. In my case, moving the keyboard to a different USB port solved the problem. All I can suggest is to work your way through all the USB ports you have available and see if they all behavee the same. -- Peter Jeremy pgpHkZwBBtkAL.pgp Description: PGP signature
Re: 8.x grudges
On 07/08/10 17:06, Peter Jeremy wrote: On 2010-Jul-07 14:22:22 -0400, Mikhail T.mi+t...@aldan.algebra.com wrote: In no particular order: 1. A picture, that one of the systems was displaying at boot (and then used as a screen-saver), stopped showing properly. The colors are right, but the picture is distorted beyond recognition. The relevant part of loader.conf is: splash_pcx_load=YES vesa_load=YES bitmap_load=YES bitmap_name=/boot/187426-9-quokka-dreaming.pcx It's a bit difficult to provide any useful input without some idea of what the picture should and does look like. Can you please post the actual bitmap as well as a picture of your screen showing the problem. 3. Likewise, having device ugen breaks config(8) -- another undocumented incompatibility. Can you please advise where it is documented that device ugen is valid in a FreeBSD-8 config file? NAME ugen -- USB generic device support SYNOPSIS To compile this driver into the kernel, place the following line in your kernel configuration file: device ugen Alternatively, to load the driver as a module at boot time, place the following line in loader.conf(5): ugen_load=YES DESCRIPTION The ugen driver provides support for all USB devices that do not have a special driver. It supports access to all parts of the device, but not in a way that is as convenient as a special purpose driver. There can be up to 127 USB devices connected to a USB bus. Each USB device can have up to 16 endpoints. Each of these endpoints will commu- snip uname -a FreeBSD lholt-desktop.primemediaanalysis.com 8.0-RELEASE-p3 FreeBSD 8.0-RELEASE-p3 #0: Tue May 25 20:54:11 UTC 2010 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 I'm not going to argue in favor of any points in this rant, but it is in the man page. As someone who's done some release engineering and worked with sysinstall on my own project, I can tell you it's a real pain and developers in the FreeBSD community deserve courtesy. Most of us work on open source for free in our own time, and it's impossible to test every possible configuration before a release. Luke ___ 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: 8.x grudges
On Thu, Jul 8, 2010 at 2:36 PM, Lucas Holt l...@foolishgames.com wrote: On 07/08/10 17:06, Peter Jeremy wrote: On 2010-Jul-07 14:22:22 -0400, Mikhail T.mi+t...@aldan.algebra.com wrote: In no particular order: 1. A picture, that one of the systems was displaying at boot (and then used as a screen-saver), stopped showing properly. The colors are right, but the picture is distorted beyond recognition. The relevant part of loader.conf is: splash_pcx_load=YES vesa_load=YES bitmap_load=YES bitmap_name=/boot/187426-9-quokka-dreaming.pcx It's a bit difficult to provide any useful input without some idea of what the picture should and does look like. Can you please post the actual bitmap as well as a picture of your screen showing the problem. 3. Likewise, having device ugen breaks config(8) -- another undocumented incompatibility. Can you please advise where it is documented that device ugen is valid in a FreeBSD-8 config file? NAME ugen -- USB generic device support SYNOPSIS To compile this driver into the kernel, place the following line in your kernel configuration file: device ugen Alternatively, to load the driver as a module at boot time, place the following line in loader.conf(5): ugen_load=YES DESCRIPTION The ugen driver provides support for all USB devices that do not have a special driver. It supports access to all parts of the device, but not in a way that is as convenient as a special purpose driver. There can be up to 127 USB devices connected to a USB bus. Each USB device can have up to 16 endpoints. Each of these endpoints will commu- snip uname -a FreeBSD lholt-desktop.primemediaanalysis.com 8.0-RELEASE-p3 FreeBSD 8.0-RELEASE-p3 #0: Tue May 25 20:54:11 UTC 2010 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 I'm not going to argue in favor of any points in this rant, but it is in the man page. Looks like you found a bug. :) ugen is not listed in any of the NOTES files, and is not a valid device entry for a 8.x kernel config file. Maybe that man page got skipped in the USB stack upgrade? Should definitely add a PR for this man page to be updated for the new USB stack. Maybe even do an audit of the rest of the USB devices to make sure the man pages for those are correct as well. -- Freddie Cash fjwc...@gmail.com ___ 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: 8.x grudges
On Thu, Jul 08, 2010 at 02:46:16PM -0700, Freddie Cash wrote: On Thu, Jul 8, 2010 at 2:36 PM, Lucas Holt l...@foolishgames.com wrote: On 07/08/10 17:06, Peter Jeremy wrote: On 2010-Jul-07 14:22:22 -0400, Mikhail T.mi+t...@aldan.algebra.com wrote: In no particular order: 1. A picture, that one of the systems was displaying at boot (and then used as a screen-saver), stopped showing properly. The colors are right, but the picture is distorted beyond recognition. The relevant part of loader.conf is: splash_pcx_load=YES vesa_load=YES bitmap_load=YES bitmap_name=/boot/187426-9-quokka-dreaming.pcx It's a bit difficult to provide any useful input without some idea of what the picture should and does look like. Can you please post the actual bitmap as well as a picture of your screen showing the problem. 3. Likewise, having device ugen breaks config(8) -- another undocumented incompatibility. Can you please advise where it is documented that device ugen is valid in a FreeBSD-8 config file? NAME ugen -- USB generic device support SYNOPSIS To compile this driver into the kernel, place the following line in your kernel configuration file: device ugen Alternatively, to load the driver as a module at boot time, place the following line in loader.conf(5): ugen_load=YES DESCRIPTION The ugen driver provides support for all USB devices that do not have a special driver. It supports access to all parts of the device, but not in a way that is as convenient as a special purpose driver. There can be up to 127 USB devices connected to a USB bus. Each USB device can have up to 16 endpoints. Each of these endpoints will commu- snip uname -a FreeBSD lholt-desktop.primemediaanalysis.com 8.0-RELEASE-p3 FreeBSD 8.0-RELEASE-p3 #0: Tue May 25 20:54:11 UTC 2010 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 I'm not going to argue in favor of any points in this rant, but it is in the man page. Looks like you found a bug. :) ugen is not listed in any of the NOTES files, and is not a valid device entry for a 8.x kernel config file. Maybe that man page got skipped in the USB stack upgrade? Should definitely add a PR for this man page to be updated for the new USB stack. Maybe even do an audit of the rest of the USB devices to make sure the man pages for those are correct as well. In this specific case it's a bug -- someone didn't remove ugen.4 from the build tree. But be careful when it comes to relying on man to indicate a feature existing. Some older users may remember how catman pages could (can? It may still happen -- though my quick dig through periodic's 330.catman indicates catman(1)'s -r flag is now used, so things SHOULD be in sync at all times now) get out of sync. With regards to leftover man pages in /usr/share/man/manX, I believe mergemaster now handles clean-up of those, and probably catX too. Can't remember (I've been up for 22 hours, cut me some slack :-) ). I will take a moment to mention periodic(8)'s weekly_catman_enable variable, which is wonderful except for the fact that tons of our man pages don't play nice with nroff -man so you'll see tons of warnings every week -- with no filenames emitted to track down the offender. Frustrating! Maybe catman(1)'s -v flag emits the filename it's handing off to nroff? Not sure. Either way, highly frustrating. So for rebuilding catman pages, I recommend folks do it manually. Run /etc/periodic/weekly/330.catman by hand (with the periodic.conf variable set to yes of course), enjoy the warnings, then disable the variable in the conf once more. Man pages!!! *shakes fist angrily* -- | Jeremy Chadwick j...@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-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: 8.x grudges
Date: Thu, 08 Jul 2010 17:36:17 -0400 From: Lucas Holt l...@foolishgames.com Sender: owner-freebsd-sta...@freebsd.org On 07/08/10 17:06, Peter Jeremy wrote: On 2010-Jul-07 14:22:22 -0400, Mikhail T.mi+t...@aldan.algebra.com wrote: In no particular order: 1. A picture, that one of the systems was displaying at boot (and then used as a screen-saver), stopped showing properly. The colors are right, but the picture is distorted beyond recognition. The relevant part of loader.conf is: splash_pcx_load=YES vesa_load=YES bitmap_load=YES bitmap_name=/boot/187426-9-quokka-dreaming.pcx It's a bit difficult to provide any useful input without some idea of what the picture should and does look like. Can you please post the actual bitmap as well as a picture of your screen showing the problem. 3. Likewise, having device ugen breaks config(8) -- another undocumented incompatibility. Can you please advise where it is documented that device ugen is valid in a FreeBSD-8 config file? NAME ugen -- USB generic device support SYNOPSIS To compile this driver into the kernel, place the following line in your kernel configuration file: device ugen Alternatively, to load the driver as a module at boot time, place the following line in loader.conf(5): ugen_load=YES DESCRIPTION The ugen driver provides support for all USB devices that do not have a special driver. It supports access to all parts of the device, but not in a way that is as convenient as a special purpose driver. There can be up to 127 USB devices connected to a USB bus. Each USB device can have up to 16 endpoints. Each of these endpoints will commu- snip uname -a FreeBSD lholt-desktop.primemediaanalysis.com 8.0-RELEASE-p3 FreeBSD 8.0-RELEASE-p3 #0: Tue May 25 20:54:11 UTC 2010 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 I'm not going to argue in favor of any points in this rant, but it is in the man page. As someone who's done some release engineering and worked with sysinstall on my own project, I can tell you it's a real pain and developers in the FreeBSD community deserve courtesy. Most of us work on open source for free in our own time, and it's impossible to test every possible configuration before a release. Oops! This one seems to have been left in the V8 sources, but there is no ugen device in version 8. ugen still sort of exists, but it is part of the base USB driver and not a separate device any longer. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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: 8.x grudges
On Thu, 8 Jul 2010, Jeremy Chadwick wrote: With regards to leftover man pages in /usr/share/man/manX, I believe mergemaster now handles clean-up of those, and probably catX too. Never has, never will. :) What I actually advocate is 'rm -r /usr/share/man' before doing installworld. Been doing that myself for years and years, never have to deal with the out of date man page problem you described so well in your post. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ 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: 8.x grudges
On Wed, Jul 7, 2010 at 11:22 AM, Mikhail T. mi+t...@aldan.algebra.com wrote: 8. I tried to do an install on one of the systems via netbooting (pxeload) the disk1-image. It booted, but the sysinstall had to be started manually and, once started, did not act the same as when booted off of CD-ROM. Seems like a simple bit to correct so that setting init to /usr/sbin/sysinstall/manually on every boot/ is not necessary... This shouldn't be the case. IIRC, nothing has changed that would cause this. More info on your environment please? ___ 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: 8.x grudges
On Wed, 07 Jul 2010 14:22:22 -0400 Mikhail T. mi+t...@aldan.algebra.com wrote: 9. The k8temp utility (installed by sysutils/k8temp http://www.freshports.org/sysutils/k8temp), which worked fine on both of my AMD-machines, no longer works on the Athlon one (still works on the Opteron-based server). In case you are not aware of it: amdtemp(4) performs the same function (more or less) as k8temp. HTH -- Torfinn ___ 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: 8.x grudges
On Wed, Jul 07, 2010 at 02:22:22PM -0400, Mikhail T. wrote: I'm upgrading several systems these days to the 8.1 (pre-release) and have hit the following troubles... I could file a formal PR for each, I suppose, but, maybe, this way will get the right people's attention sooner. 2. FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and thus not an option) -- the kernel-config files, that worked with 7.x, break without this option in them (in addition to all the nuisance, that's documented in UPDATING -- which, somehow, makes the breakage acceptable). config(8) would not warn about this, but kernel build fails. We don't use this option (meaning it's removed from our kernels). It's definitely not required. All it does is ensure your kernel can comprehend executables/binaries built on 7.x. 3. Likewise, having device ugen breaks config(8) -- another undocumented incompatibility. This sounds like you not including all of the necessary USB/device framework in your kernel configuration. You're not providing enough output for us to help diagnose the problem, though. Be aware that config(8) changed during recent days and requires a rebuild, although the build infrastructure normally instructs you to do this (otherwise kernel won't build). I noticed it when upgrading from an early version of RELENG_8 to a more recent version, and it was kind enough to tell me to rebuild it. 4. The sio(4) is described in UPDATING as removed, but rouses no complaint from config(8) either. It just breaks the kernel build... It should be an alias for uart, IMHO -- all I want is for my serial ports to be usable, whether their driver is called Serial Input/Output or Universal Asynchronous Receiver and Transmitter. I disagree (re: it should be an alias). sio(4) is deprecated (meaning it's not used by default any more), and it's left in the driver tree solely as a fall-back method if someone runs into uart(4) problems. I'm sure it'll eventually be removed, but for now, it remains. The point I'm going to make here is this: sio(4) is different than uart(4). Aliasing one to the other will do nothing but confuse folks. If we're going to do that, why not rename all of our Ethernet interfaces ethX and so on? ;-) I'll take a moment to point out that your complaints about the kernel configuration file, so far, seem to stem from you not migrating your kernel configuration from 7.x to 8.x. Things change -- that's the reality of the situation. The way I do this is, when upgrading major releases (7.x-8.x), to start fresh using GENERIC as my base template and then adding/adjusting while comparing against the older kernels' config. Others do it differently, this is just how I do it. (BTW, about the /dev-entries -- do we /really/ have to change the names of the serial port-devices every couple of years? It is rather painful to reconfigure the fax- and ppp-software, etc.) How does the Microsoft world manage to stay with the COM1, COM2 for decades?) Like I said: things change. 5. One of the upgraded systems would repeatedly hang at boot, until I disabled the on-board firewire-device through the BIOS... It was not a problem under 7.x, although I don't know, whether the device actually worked. This is a commonly-reported problem, assuming at boot you mean while the kernel is starting. Or unless you're using a certain model of Shuttle box, but that turned out to be literally a BIOS bug: http://koitsu.wordpress.com/2009/05/22/shuttle-sg45h7-firewire-bug-in-bios-sg45u10o/ 6. Despite the reported improvements in the USB area, my USB keyboard /still/ does not work during boot. It during POST and then after the booting is complete. But in single-user mode -- no... Had to fish-out the PS2 keyboard... This is also a commonly-reported problem (and one I've harped on as well). When you say during boot: does it work during loader (the screen with the FreeBSD logo on it)? If the keyboard works during loader but not once the kernel + kernel USB stack loads (e.g. when booting into single-user), then look at the very bottom of this page for a couple things to try: http://wiki.freebsd.org/BugBusting/Commonly_reported_issues If the keyboard DOES NOT work during loader, then it sounds like your BIOS isn't setting the system up so that USB keyboards get emulated as PS/2 (this setup gets stomped by the kernel later, obviously). Usually BIOSes offer an option like USB Legacy Enable or USB Keyboard Enable which provides this functionality. It's important to remember that there is no USB stack loaded via the bootstraps, which focus on your system/BIOS. Linux and Solaris have the same problem, as I understand it. Welcome to PC architecture evolution, if you can call it that. :-) Regardless, this is one of the reasons I still have not made the move to USB
Re: 8.x grudges
Date: Wed, 07 Jul 2010 14:22:22 -0400 From: Mikhail T. mi+t...@aldan.algebra.com Sender: owner-freebsd-sta...@freebsd.org I'm upgrading several systems these days to the 8.1 (pre-release) and have hit the following troubles... I could file a formal PR for each, I suppose, but, maybe, this way will get the right people's attention sooner. In no particular order: 1. A picture, that one of the systems was displaying at boot (and then used as a screen-saver), stopped showing properly. The colors are right, but the picture is distorted beyond recognition. The relevant part of loader.conf is: splash_pcx_load=YES vesa_load=YES bitmap_load=YES bitmap_name=/boot/187426-9-quokka-dreaming.pcx the picture file is identified as: PCX 772x551 772x551+0+0 8-bit PseudoClass 256c 454KB 0.039u 0:00.093 2. FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and thus not an option) -- the kernel-config files, that worked with 7.x, break without this option in them (in addition to all the nuisance, that's documented in UPDATING -- which, somehow, makes the breakage acceptable). config(8) would not warn about this, but kernel build fails. FREEBSD_COMPAT7 is certainly an option. I build without it just fine. But the kernel-config files, that worked with 7.x, break without this option in them I think points to your real problem. 3. Likewise, having device ugen breaks config(8) -- another undocumented incompatibility. It certainly does. ugen is no longer a valid device with the new USB stack in 8. (It is essentially built into the base USB driver.) It seems that you expect to be able to build a kernel for V8 using a V7 configuration file. THIS WILL NOT WORK! You must always re-do customizations when performing a major version upgrade. You should always start with GENERIC for a major version and make the required changes to it. I believe the current recommendation is to include GENERIC in your custom kernel configuration and then add or delete options and devices as desired. (This probably works best if your config file is close to GENERIC.) 4. The sio(4) is described in UPDATING as removed, but rouses no complaint from config(8) either. It just breaks the kernel build... It should be an alias for uart, IMHO -- all I want is for my serial ports to be usable, whether their driver is called Serial Input/Output or Universal Asynchronous Receiver and Transmitter. (BTW, about the /dev-entries -- do we /really/ have to change the names of the serial port-devices every couple of years? It is rather painful to reconfigure the fax- and ppp-software, etc.) How does the Microsoft world manage to stay with the COM1, COM2 for decades?) This would be nice, but the sio and uart drivers have co-existed for quite a while. They could not have the same name. Of course, a it would have been possible to rename the uart driver to sio when sio was removed or make it an alias, but that was not done. I suspect primarily to not break things when people discovered that sio and uart are NOT the same in the way they work. Not an issue for most, since they are close. 5. One of the upgraded systems would repeatedly hang at boot, until I disabled the on-board firewire-device through the BIOS... It was not a problem under 7.x, although I don't know, whether the device actually worked. Odd. Sounds like a bug. I don't have a firewire port, so I have no idea about this. 6. Despite the reported improvements in the USB area, my USB keyboard /still/ does not work during boot. It during POST and then after the booting is complete. But in single-user mode -- no... Had to fish-out the PS2 keyboard... All I can say is that it works fine for me. It may be tied to your building a V8 kernel with a V7 config. It may also be tied to having libusb from ports installed. Since libusb is now part of the base system, having the ports version around can break lots of USB stuff. 7. All my dangerously dedicated disks lost the s1 in the subdevice-names after the upgrade: /dev/da1s1d became /dev/da1d, etc. I like the shorter names (and there are, indeed, no slices there), but having to fix them manually upon reboot was unpleasant and uncalled for. As with uart/sio, backward-compatibility aliases are a fine idea and really improves user's experience... No, this one is due to a major re-structuring of how disks work in V8. As has been oft noted, dangerously dedicated is called that because it IS dangerous. While commonly used, it does not play nicely with standards and is prone to some fairly serious potential issues on upgrade. dangerously dedicated has been marked as use it at your own
Re: net-booting the install disks (Re: 8.x grudges)
2010/7/7 Mikhail T. mi+t...@aldan.algebra.com:
07.07.2010 14:30, Randi Harper написав(ла):
8.
I tried to do an install on one of the systems via netbooting
(pxeload) the disk1-image. It booted, but the sysinstall had to be
started manually and, once started, did not act the same as when
booted off of CD-ROM. Seems like a simple bit to correct so that
setting init to /usr/sbin/sysinstall/manually on every boot/ is
not necessary...
This shouldn't be the case. IIRC, nothing has changed that would cause
this. More info on your environment please?
Well, I never tried this part before, so I'm not claiming, there is
regression here. Just lack of progress :-)
I have the following special entry in the dhcpd.conf:
subnet 192.168.1.0 netmask 255.255.255.0 {
range dynamic-bootp 192.168.1.150 192.168.1.186;
next-server 192.168.1.140;
option broadcast-address 192.168.1.255;
option routers 192.168.1.1;
option root-path 192.168.1.140:/cdrom;
filename pxeboot;
}
The filesystem accessible as /cdrom was an md-accessed
FreeBSD-8.1-RC1-i386-disc1.iso (or bootonly). Can't easily recreate this,
because the netbooting machine has now gone back to its owner.
The problem did not surprise me, because I followed (loosely) the
instructions, where it was mentioned -- along with a work-around. If some
simple logic can be put into the boot-image to allow it to do the right
thing without manual fiddling, it would be great. Thanks!
-mi
So you're complaining that you have to modify the loader.conf? I
fail to see the problem. This is by design, and isn't a lack of
progress.
-- randi
___
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: 8.x grudges
07.07.2010 14:59, Jeremy Chadwick ???(??): FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and thus not an option) -- the kernel-config files, that worked with 7.x, break without this option in them (in addition to all the nuisance, that's documented in UPDATING -- which, somehow, makes the breakage acceptable). config(8) would not warn about this, but kernel build fails. We don't use this option (meaning it's removed from our kernels). It's definitely not required. All it does is ensure your kernel can comprehend executables/binaries built on 7.x. Attached is the kernel config-file (i386), that worked fine under 7.x. The kernel-compile will break (some *freebsd7* structs undefined), without the COMPAT_FREEBSD7 option. Try it for yourself... 3. Likewise, having device ugen breaks config(8) -- another undocumented incompatibility. This sounds like you not including all of the necessary USB/device framework in your kernel configuration. You're not providing enough output for us to help diagnose the problem, though. Put device ugen back into the attached kernel-config file and see config's error yourself. 4. The sio(4) is described in UPDATING as removed, but rouses no complaint from config(8) either. It just breaks the kernel build... It should be an alias for uart, IMHO -- all I want is for my serial ports to be usable, whether their driver is called Serial Input/Output or Universal Asynchronous Receiver and Transmitter. I disagree (re: it should be an alias). sio(4) is deprecated (meaning it's not used by default any more), and it's left in the driver tree solely as a fall-back method if someone runs into uart(4) problems. If it were merely deprecated it would've still worked. It does not -- put device sio into the attached kernel-config and try building -- you'll get the compile-error. Whether deliberately or through bit-rot, uart /replaced/ sio... I'll take a moment to point out that your complaints about the kernel configuration file, so far, seem to stem from you not migrating your kernel configuration from 7.x to 8.x. Things change -- that's the reality of the situation. The way I do this is, when upgrading major releases (7.x-8.x), to start fresh using GENERIC as my base template and then adding/adjusting while comparing against the older kernels' config. Others do it differently, this is just how I do it. Yes, your way is fine. But so is mine. It is perfectly reasonable to expect my method to work just as well -- the 7-8 is not revolutionary, but simply the next step. I read the UPDATING file and, though annoyed a little, took care of things mentioned in there... The remaining things are enumerated here... (BTW, about the /dev-entries -- do we /really/ have to change the names of the serial port-devices every couple of years? It is rather painful to reconfigure the fax- and ppp-software, etc.) How does the Microsoft world manage to stay with the COM1, COM2 for decades?) Like I said: things change. Well, pardon the political pun, but I don't believe in change for the sake of change. These particular changes are gratuitous. If sio is no longer available -- and replaced by uart, why change the /dev-entries?.. 5. One of the upgraded systems would repeatedly hang at boot, until I disabled the on-board firewire-device through the BIOS... It was not a problem under 7.x, although I don't know, whether the device actually worked. This is a commonly-reported problem, assuming at boot you mean while the kernel is starting. Or unless you're using a certain model of Shuttle box, but that turned out to be literally a BIOS bug: http://koitsu.wordpress.com/2009/05/22/shuttle-sg45h7-firewire-bug-in-bios-sg45u10o/ No, this is not it /at all/. The link above describes a crash in the BIOS (and no POST), if firewire circuitry is disabled in BIOS. My problem is with FreeBSD kernel hanging on boot, if the firewire circuitry is enabled in BIOS. The boot was fine under 7.x, so this can not be due to a BIOS-bug -- the only thing, that changed, is the OS... This is also a commonly-reported problem (and one I've harped on as well). When you say during boot: does it work during loader (the screen with the FreeBSD logo on it)? Yes. If the keyboard works during loader but not once the kernel + kernel USB stack loads (e.g. when booting into single-user), then look at the very bottom of this page for a couple things to try: http://wiki.freebsd.org/BugBusting/Commonly_reported_issues Will do, thanks! Still, I was hoping, things will just work with 8.1... Regardless, this is one of the reasons I still have not made the move to USB keyboards and stick with PS/2 keyboards on FreeBSD. While renovating the house, I ran USB-, audio-, and video-cables through the walls from server room to
Re: 8.x grudges
On Wed, Jul 7, 2010 at 1:17 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: 07.07.2010 14:59, Jeremy Chadwick ???(??): FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and thus not an option) -- the kernel-config files, that worked with 7.x, break without this option in them (in addition to all the nuisance, that's documented in UPDATING -- which, somehow, makes the breakage acceptable). config(8) would not warn about this, but kernel build fails. We don't use this option (meaning it's removed from our kernels). It's definitely not required. All it does is ensure your kernel can comprehend executables/binaries built on 7.x. Attached is the kernel config-file (i386), that worked fine under 7.x. The kernel-compile will break (some *freebsd7* structs undefined), without the COMPAT_FREEBSD7 option. Try it for yourself... Don't use a kernel config from 7. We've already told you this. 3. Likewise, having device ugen breaks config(8) -- another undocumented incompatibility. This sounds like you not including all of the necessary USB/device framework in your kernel configuration. You're not providing enough output for us to help diagnose the problem, though. Put device ugen back into the attached kernel-config file and see config's error yourself. 4. The sio(4) is described in UPDATING as removed, but rouses no complaint from config(8) either. It just breaks the kernel build... It should be an alias for uart, IMHO -- all I want is for my serial ports to be usable, whether their driver is called Serial Input/Output or Universal Asynchronous Receiver and Transmitter. I disagree (re: it should be an alias). sio(4) is deprecated (meaning it's not used by default any more), and it's left in the driver tree solely as a fall-back method if someone runs into uart(4) problems. If it were merely deprecated it would've still worked. It does not -- put device sio into the attached kernel-config and try building -- you'll get the compile-error. Whether deliberately or through bit-rot, uart /replaced/ sio... I'll take a moment to point out that your complaints about the kernel configuration file, so far, seem to stem from you not migrating your kernel configuration from 7.x to 8.x. Things change -- that's the reality of the situation. The way I do this is, when upgrading major releases (7.x-8.x), to start fresh using GENERIC as my base template and then adding/adjusting while comparing against the older kernels' config. Others do it differently, this is just how I do it. Yes, your way is fine. But so is mine. It is perfectly reasonable to expect my method to work just as well -- the 7-8 is not revolutionary, but simply the next step. I read the UPDATING file and, though annoyed a little, took care of things mentioned in there... The remaining things are enumerated here... Your way clearly isn't fine, as it doesn't work. (BTW, about the /dev-entries -- do we /really/ have to change the names of the serial port-devices every couple of years? It is rather painful to reconfigure the fax- and ppp-software, etc.) How does the Microsoft world manage to stay with the COM1, COM2 for decades?) Like I said: things change. Well, pardon the political pun, but I don't believe in change for the sake of change. These particular changes are gratuitous. If sio is no longer available -- and replaced by uart, why change the /dev-entries?.. These changes aren't gratuitous. Did you read the commit messages behind each of the changes? I'm guessing that you haven't. 5. One of the upgraded systems would repeatedly hang at boot, until I disabled the on-board firewire-device through the BIOS... It was not a problem under 7.x, although I don't know, whether the device actually worked. This is a commonly-reported problem, assuming at boot you mean while the kernel is starting. Or unless you're using a certain model of Shuttle box, but that turned out to be literally a BIOS bug: http://koitsu.wordpress.com/2009/05/22/shuttle-sg45h7-firewire-bug-in-bios-sg45u10o/ No, this is not it /at all/. The link above describes a crash in the BIOS (and no POST), if firewire circuitry is disabled in BIOS. My problem is with FreeBSD kernel hanging on boot, if the firewire circuitry is enabled in BIOS. The boot was fine under 7.x, so this can not be due to a BIOS-bug -- the only thing, that changed, is the OS... Yes. Sometimes there are bugs that exist that aren't triggered until an external influence makes them apparent. This is also a commonly-reported problem (and one I've harped on as well). When you say during boot: does it work during loader (the screen with the FreeBSD logo on it)? Yes. If the keyboard works during loader but not once the kernel + kernel USB stack loads (e.g. when booting into single-user), then look at the
Re: 8.x grudges
On Jul 7, 2010, at 1:34 PM, Randi Harper wrote: Well, pardon the political pun, but I don't believe in change for the sake of change. These particular changes are gratuitous. If sio is no longer available -- and replaced by uart, why change the /dev-entries?.. These changes aren't gratuitous. Did you read the commit messages behind each of the changes? I'm guessing that you haven't. Not to mention that if you change uart(4) to create dev entries like sio(4) after uart(4) has been in the tree for more than 6 years creating ttyu* entries, you actually introduce a gratuitous change. It's all about perspective... -- Marcel Moolenaar xcl...@mac.com ___ 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: 8.x grudges
07.07.2010 16:34, Randi Harper ???(??): Attached is the kernel config-file (i386), that worked fine under 7.x. The kernel-compile will break (some *freebsd7* structs undefined), without the COMPAT_FREEBSD7 option. Try it for yourself... Don't use a kernel config from 7. We've already told you this. Your telling me this is just as valid as warning me against using computer-cases of a particular color. It is a silly requirement. My expecting things, that worked for 7, to work in 8 is reasonable. There may be (documented!) exceptions, but it ought to just work. Yes, your way is fine. But so is mine. It is perfectly reasonable to expect my method to work just as well -- the 7-8 is not revolutionary, but simply the next step. I read the UPDATING file and, though annoyed a little, took care of things mentioned in there... The remaining things are enumerated here... Your way clearly isn't fine, as it doesn't work. That's an obviously flawed argument -- this line of thinking can be used against ANY ONE reporting ANY BUG -- if one has a problem, then one's way of doing things clearly isn't fine. These changes aren't gratuitous. Did you read the commit messages behind each of the changes? I'm guessing that you haven't. No, and I'm not going to. A commercial OS would've been the laughing stock, if one hand to change C: to 1: between releases, for example... Again: this particular change seems gratuitous. It's not. You didn't bother researching before complaining. I bothered to type up my list. Presumably, problem-reports are welcome. I've been a Unix-user since 1990, a FreeBSD user since 1993 (or 94?), and a project-member for a decade. If *I* have a problem, then newer users certainly will too. And, guess what, they'll simply go with something, that does not give as much grief... To put it in simple terms, there were changes made to geom, and the way that sysinstall writes out dedicated disks wasn't compatible. Search the mailing list archives. If this is a known problem, it is even more of an outrage, that some shim was not introduced to keep the users from hitting this particular bump. The modification should be necessary. Why? Why should a netboot act differently from a local boot from CD? Just because you don't want to make the modification doesn't mean it was made that way by accident. No, I never claimed this to have been an accident... That variable can be set to any number of things. We don't advertise the iso image just working out of the box for pxe booting. You don't. But there is very little, that needs to be added there for it to just work over both netboot and local CD, and you should do it, instead of arguing with me here... No, I don't know, what it is exactly, but I'm quite certain, it can't be very much. In fact, the article about PXE booting on the official freebsd website says nothing about using the ISO. You just found some article that said it was possible (and it is) and complained because you didn't like the process? Yes, exactly. I didn't like process -- it is needlessly complicated. The same CD-image, /should/ also be usable out of the box for netbooting. Funny. It works just fine in 8.0 on my Athlon. Have you tried updating the port? Yes, I have -- and I said so in my very first e-mail on this subject. For someone, who expects people to research mailing lists, you do a terrible job of following a one-day-old thread... Also, even if it didn't work, this is an issue you should take up with the author of the port. Tom -- the maintainer -- is still in CC... From the man page: The amdtemp driver provides support for the on-die digital thermal sensor present in AMD K8, K10 and K11 processors. I know nothing about the driver. But a utility I regularly used stopped working after upgrade, so I added that to my list of upgrade-related grudges. -mi ___ 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: 8.x grudges
On Wed, Jul 7, 2010 at 1:17 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: 07.07.2010 14:59, Jeremy Chadwick ???(??): FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and thus not an option) -- the kernel-config files, that worked with 7.x, break without this option in them (in addition to all the nuisance, that's documented in UPDATING -- which, somehow, makes the breakage acceptable). config(8) would not warn about this, but kernel build fails. We don't use this option (meaning it's removed from our kernels). It's definitely not required. All it does is ensure your kernel can comprehend executables/binaries built on 7.x. Attached is the kernel config-file (i386), that worked fine under 7.x. The kernel-compile will break (some *freebsd7* structs undefined), without the COMPAT_FREEBSD7 option. Try it for yourself... While you may get lucky sometimes, it's very *VERY* rare to be able to re-use a kernel config file across major version releases, at least unchanged. Going from 4.x to 5.x required a new kernel config file. (4.x was my first real install of FreeBSD that was upgraded.) Going from 5.x to 6.x required a new kernel config file. Going from 6.x to 7.x required a new kernel config file. Why do you think going from 7.x to 8.x would be any different? When doing major version upgrades, always start with GENERIC from the new release, and add build your custom config file from there. This is way things have been for many, many, many years. Minor version upgrades (7.x to 7.y) rarely require a new kernel config file, although it's still a good idea to start with GENERIC for the duration of the upgrade. But major upgrades have pretty much always required it. -- Freddie Cash fjwc...@gmail.com ___ 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: 8.x grudges
On Wed, Jul 7, 2010 at 1:52 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: I know nothing about the driver. But a utility I regularly used stopped working after upgrade, so I added that to my list of upgrade-related grudges. Was this before or after re-compiling all your installed ports, which is necessary step between major version upgrades? -- Freddie Cash fjwc...@gmail.com ___ 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: 8.x grudges
On Wed, Jul 7, 2010 at 1:17 PM, Mikhail T. mi+t...@aldan.algebra.com wrote:
07.07.2010 14:59, Jeremy Chadwick ???(??):
FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and
thus not an option) -- the kernel-config files, that worked with
7.x, break without this option in them (in addition to all the
nuisance, that's documented in UPDATING -- which, somehow, makes
the breakage acceptable). config(8) would not warn about this, but
kernel build fails.
We don't use this option (meaning it's removed from our kernels). It's
definitely not required. All it does is ensure your kernel can
comprehend executables/binaries built on 7.x.
Attached is the kernel config-file (i386), that worked fine under 7.x. The
kernel-compile will break (some *freebsd7* structs undefined), without the
COMPAT_FREEBSD7 option. Try it for yourself...
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores
Those require COMPAT_FREEBSD7. This does seem like a bug:
static struct syscall_helper_data shm_syscalls[] = {
SYSCALL_INIT_HELPER(shmat),
SYSCALL_INIT_HELPER(shmctl),
SYSCALL_INIT_HELPER(shmdt),
SYSCALL_INIT_HELPER(shmget),
#if defined(COMPAT_FREEBSD4) || defined(COMPAT_FREEBSD5) || \
defined(COMPAT_FREEBSD6) || defined(COMPAT_FREEBSD7)
SYSCALL_INIT_HELPER(freebsd7_shmctl),
#endif
The check should be for COMPAT_FREEBSD7 only I would think.
Apart from that, everything else should work without it I would think.
Thanks,
-Garrett
___
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: 8.x grudges
On Wed, Jul 7, 2010 at 1:52 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: 07.07.2010 16:34, Randi Harper ???(??): Attached is the kernel config-file (i386), that worked fine under 7.x. The kernel-compile will break (some *freebsd7* structs undefined), without the COMPAT_FREEBSD7 option. Try it for yourself... Don't use a kernel config from 7. We've already told you this. Your telling me this is just as valid as warning me against using computer-cases of a particular color. It is a silly requirement. My expecting things, that worked for 7, to work in 8 is reasonable. There may be (documented!) exceptions, but it ought to just work. Yes, your way is fine. But so is mine. It is perfectly reasonable to expect my method to work just as well -- the 7-8 is not revolutionary, but simply the next step. I read the UPDATING file and, though annoyed a little, took care of things mentioned in there... The remaining things are enumerated here... Your way clearly isn't fine, as it doesn't work. That's an obviously flawed argument -- this line of thinking can be used against ANY ONE reporting ANY BUG -- if one has a problem, then one's way of doing things clearly isn't fine. These changes aren't gratuitous. Did you read the commit messages behind each of the changes? I'm guessing that you haven't. No, and I'm not going to. A commercial OS would've been the laughing stock, if one hand to change C: to 1: between releases, for example... Again: this particular change seems gratuitous. It's not. You didn't bother researching before complaining. I bothered to type up my list. Presumably, problem-reports are welcome. I've been a Unix-user since 1990, a FreeBSD user since 1993 (or 94?), and a project-member for a decade. If *I* have a problem, then newer users certainly will too. And, guess what, they'll simply go with something, that does not give as much grief... To put it in simple terms, there were changes made to geom, and the way that sysinstall writes out dedicated disks wasn't compatible. Search the mailing list archives. If this is a known problem, it is even more of an outrage, that some shim was not introduced to keep the users from hitting this particular bump. The modification should be necessary. Why? Why should a netboot act differently from a local boot from CD? There's a lot of secret sauce done for detecting whether or not you're booting from CD vs pxebooting in a release image, as well as within the sysinstall application as to what environment its dealing with, as well as what you get after things are done with a vanilla build and a sysinstall install (as I've discovered on my own). Unfortunately assuming both methods to produce the same result is flawed :(... Thanks, -Garrett ___ 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: 8.x grudges
5. One of the upgraded systems would repeatedly hang at boot, until I disabled the on-board firewire-device through the BIOS... It was not a problem under 7.x, although I don't know, whether the device actually worked. This is a commonly-reported problem, assuming at boot you mean while the kernel is starting. Or unless you're using a certain model of Shuttle box, but that turned out to be literally a BIOS bug: http://koitsu.wordpress.com/2009/05/22/shuttle-sg45h7-firewire-bug-in-bios-sg45u10o/ Looking at this link, it doesn't match the described issue. Mikhail's machine would not boot *until* he disabled the firewire controller in the BIOS. The referenced issue on that Shuttle based machine talks about disabling the firewire controller and *then* it still being alive when the system powers on and crashing the system. I interpret this as a bug. Sean Also, I suck at reply-to. sean ___ 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: 8.x grudges
5. One of the upgraded systems would repeatedly hang at boot, until I disabled the on-board firewire-device through the BIOS... It was not a problem under 7.x, although I don't know, whether the device actually worked. This is a commonly-reported problem, assuming at boot you mean while the kernel is starting. Or unless you're using a certain model of Shuttle box, but that turned out to be literally a BIOS bug: http://koitsu.wordpress.com/2009/05/22/shuttle-sg45h7-firewire-bug-in-bios-sg45u10o/ Looking at this link, it doesn't match the described issue. Mikhail's machine would not boot *until* he disabled the firewire controller in the BIOS. The referenced issue on that Shuttle based machine talks about disabling the firewire controller and *then* it still being alive when the system powers on and crashing the system. I interpret this as a bug. Sean ___ 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: 8.x grudges
On Wed, Jul 7, 2010 at 1:52 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: Your telling me this is just as valid as warning me against using computer-cases of a particular color. It is a silly requirement. My expecting things, that worked for 7, to work in 8 is reasonable. There may be (documented!) exceptions, but it ought to just work. Ok. So I guess that a registry backup from Windows XP should work in Windows 7? We both know the world doesn't work that way. Not only is it ridiculous, it inhibits progress. Do you have any idea how many lines of code we have to deal with to plan for older setups? Even just with the stuff that I work on, it's a constant consideration to plan for existing setups and older hardware. Sometimes changes have to be made. For everything to always be compatible, you'd be overly complicating things that are already complicated enough, just because you think the process is inconvenient. In other words, submit a patch. Yes, your way is fine. But so is mine. It is perfectly reasonable to expect my method to work just as well -- the 7-8 is not revolutionary, but simply the next step. I read the UPDATING file and, though annoyed a little, took care of things mentioned in there... The remaining things are enumerated here... Your way clearly isn't fine, as it doesn't work. That's an obviously flawed argument -- this line of thinking can be used against ANY ONE reporting ANY BUG -- if one has a problem, then one's way of doing things clearly isn't fine. I can't boot my computer without power. There must be a bug! If you're doing it wrong, then it's not a bug. Would you expect to be able to use a FreeBSD 2.x kernel config file with 8.x? These changes aren't gratuitous. Did you read the commit messages behind each of the changes? I'm guessing that you haven't. No, and I'm not going to. A commercial OS would've been the laughing stock, if one hand to change C: to 1: between releases, for example... It's not like this was a minor version bump. You expect to treat it like it is. Most commercial operating systems don't have a simple upgrade path between major versions without other problems, such as application compatibility issues, requiring hardware upgrades, etc. Again: this particular change seems gratuitous. It's not. You didn't bother researching before complaining. I bothered to type up my list. Presumably, problem-reports are welcome. I've been a Unix-user since 1990, a FreeBSD user since 1993 (or 94?), and a project-member for a decade. If I have a problem, then newer users certainly will too. And, guess what, they'll simply go with something, that does not give as much grief... PRs are welcome. Not uninformed rants on mailing lists with people that continue to argue because the world didn't start rotating a different direction at their command. I'm surprised you didn't mention your beard length. New users won't be using a FreeBSD 7 kernel config file. They'll be using a FreeBSD 8 kernel config file because they are new. They also won't care that we renamed the serial device between 7.x and 8.x. My logic rocks worlds. To put it in simple terms, there were changes made to geom, and the way that sysinstall writes out dedicated disks wasn't compatible. Search the mailing list archives. If this is a known problem, it is even more of an outrage, that some shim was not introduced to keep the users from hitting this particular bump. Yawn. Submit a patch. I dare you. The modification should be necessary. Why? Why should a netboot act differently from a local boot from CD? Because you're booting over a freaking network and not physical media. I am running out of good metaphors for you. Just accept the fact that installing over different media types means the configuration is different. Go look up what that variable means. That might be a good start. You don't. But there is very little, that needs to be added there for it to just work over both netboot and local CD, and you should do it, instead of arguing with me here... No, I don't know, what it is exactly, but I'm quite certain, it can't be very much. So you don't know what the problem is, you don't really know why things have to be done this way, but you're sure that making this change will have no unintended effects. If I made all my commits that way, I'd break the build. Oh, wait... In fact, the article about PXE booting on the official freebsd website says nothing about using the ISO. You just found some article that said it was possible (and it is) and complained because you didn't like the process? Yes, exactly. I didn't like process -- it is needlessly complicated. The same CD-image, should also be usable out of the box for netbooting. It's obvious you hate process, as you don't file PRs against these problems, you don't search the mailing list, you don't post questions in appropriate places, etc. Funny. It works just fine in 8.0 on my Athlon. Have you
Re: 8.x grudges
On Wed, 07 Jul 2010 12:34:55 -0700 Kevin Oberman ober...@es.net wrote: k8temp is for older AMD system running K8 cores. It has been mostly replaced with amdtemp which works on newer cores. I'm not sure if amdtemp will work on K8 cores, though. It does (amdtemp works on K8s): r...@kg-quiet# uname -a FreeBSD kg-quiet.kg4.no 7.3-STABLE FreeBSD 7.3-STABLE #8: Mon Apr 5 21:10:07 CEST 2010 r...@kg-quiet.kg4.no:/usr/obj/usr/src/sys/QUIET amd64 r...@kg-quiet# sysctl hw.machine hw.machine: amd64 r...@kg-quiet# sysctl dev.amdtemp dev.amdtemp.0.%desc: AMD K8 Thermal Sensors dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%parent: hostb4 dev.amdtemp.0.sensor0.core0: 45.0C dev.amdtemp.0.sensor0.core1: 46.0C dev.amdtemp.0.sensor1.core0: 46.0C dev.amdtemp.0.sensor1.core1: 46.0C HTH -- Torfinn ___ 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: 8.x grudges
On Thu, 08 Jul 2010 00:20:56 +0200 Torfinn Ingolfsen torfinn.ingolf...@broadpark.no wrote: On Wed, 07 Jul 2010 12:34:55 -0700 Kevin Oberman ober...@es.net wrote: k8temp is for older AMD system running K8 cores. It has been mostly replaced with amdtemp which works on newer cores. I'm not sure if amdtemp will work on K8 cores, though. It does (amdtemp works on K8s): r...@kg-quiet# uname -a FreeBSD kg-quiet.kg4.no 7.3-STABLE FreeBSD 7.3-STABLE #8: Mon Apr 5 21:10:07 CEST 2010 r...@kg-quiet.kg4.no:/usr/obj/usr/src/sys/QUIET amd64 r...@kg-quiet# sysctl hw.machine hw.machine: amd64 r...@kg-quiet# sysctl dev.amdtemp dev.amdtemp.0.%desc: AMD K8 Thermal Sensors dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%parent: hostb4 dev.amdtemp.0.sensor0.core0: 45.0C dev.amdtemp.0.sensor0.core1: 46.0C dev.amdtemp.0.sensor1.core0: 46.0C dev.amdtemp.0.sensor1.core1: 46.0C I forgot a part: r...@kg-quiet# sysctl hw.model hw.model: AMD Athlon(tm) 64 Processor 3000+ -- Torfinn ___ 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: 8.x grudges
For what its worth, we have had good success migrating our kernel configs from 6 - 7 - 8 with very few changes, and no real problems. The secret is to create a kernel that is based of GENERIC using include in a clean the include that config in top level one which adds the specific additional options you want. It doesn't remove the requirement to check for changes between the versions and act appropriately but it does make this process as simple as diffing the two GENERIC configs and updating our clean and addition configs with the few changes needed. This structure also means kernels compile really quickly :) e.g. [MULTIPLAY] include MULTIPLAY_CLEAN ident MULTIPLAY makeoptions MODULES_OVERRIDE=linux linprocfs acpi nullfs unionfs accf_http if_lagg options PRINTF_BUFR_SIZE=128 # Fix scrambled output on console options COMPAT_LINUX32 options INCLUDE_CONFIG_FILE options DEVICE_POLLING [/MULTIPLAY] [MULTIPLAY_CLEAN] include GENERIC nooptions INET6 nooptions SCTP nooptions NFS_ROOT nooptions NTFS nooptions MSDOSFS # SCSI Controllers nodeviceahc ... [/MULTIPLAY_CLEAN] Hope this helps. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: 8.x grudges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/7/10 4:17 PM, Mikhail T. wrote: 07.07.2010 14:59, Jeremy Chadwick написав(ла): FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and thus not an option) -- the kernel-config files, that worked with 7.x, break without this option in them (in addition to all the nuisance, that's documented in UPDATING -- which, somehow, makes the breakage acceptable). config(8) would not warn about this, but kernel build fails. We don't use this option (meaning it's removed from our kernels). It's definitely not required. All it does is ensure your kernel can comprehend executables/binaries built on 7.x. Attached is the kernel config-file (i386), that worked fine under 7.x. The kernel-compile will break (some *freebsd7* structs undefined), without the COMPAT_FREEBSD7 option. Try it for yourself... Jeremy is correct. COMPAT_FREEBSD7 means, despite this being FreeBSD 8, set things that have changed up to work in a way that is compatible with FreeBSD 7 *wherever* *possible*. Since you are trying to use a FreeBSD 7 based kernel config file you need that option, but people not trying to hold on to the FreeBSD 7 ways of doing things do not need that option. I'm not quite sure why you find that surprising, though it may have to do with a mis-conception on your part described below. The way I do this is, when upgrading major releases (7.x-8.x), to start fresh using GENERIC as my base template and then adding/adjusting while comparing against the older kernels' config. Others do it differently, this is just how I do it. Yes, your way is fine. But so is mine. It is perfectly reasonable to expect my method to work just as well -- the 7-8 is not revolutionary, but simply the next step. I read the UPDATING file and, though annoyed a little, took care of things mentioned in there... The remaining things are enumerated here... Actually it's not perfectly reasonable to *expect* your method to work just as well given the general goals of the FreeBSD Project as a whole. Your method *may* work but it's by no means guaranteed, or even a major priority I'm afraid. Your method *may* work. But you can't *expect* it. We like many similar Projects have a wide variety of people involved (both developers and end-users) and an equally wide variety of needs those people have. On the one extreme we have developers who feel their hands are tied by not being able to make user-visible changes to stuff - they feel they could make the system better faster if they could change things in incompatible ways faster. On the other extreme we have people who hate change for reasons similar to what you are expressing here - it's a pain in the butt to need to change config files, it sucks if all the old executable files suddenly stop working, etc. So, there has been a long-standing compromise in place. For bumps in *minor* version numbers you can expect to be able to use your old config files, old executables continue to work, etc. This is, for example, moving from 7.2 to 7.3. However for bumps in *major* version numbers there can and likely will be changes made that cause exactly what you are seeing here. A 7.X kernel config file *might* work OK on 8.X but we do not guarantee that. If it does happen to work great, if not sorry. What you call simply the next step is a bump in minor version number. Depending on how active the developers have been and what they've focused on major version number bumps *can* qualify as what you call revolutionary. This general mode of operation has been in place for a very long time (it pre-dates my involvement on the Release Engineering Team). - -- Ken Smith - - From there to here, from here to | kensm...@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw1Oc0ACgkQ/G14VSmup/bEiQCfdtr8UkPp/QRcwUpGTlpRtJ2f RNsAn3+cV4jDuyQ38Wvm5eTiVObJ4DLy =4Bm7 -END PGP SIGNATURE- ___ 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
