Re: 8.x grudges
On Wed, Jul 7, 2010 at 1:52 PM, Mikhail T. 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. I
Re: 8.x grudges
On Wed, Jul 7, 2010 at 1: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... 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 w
Re: net-booting the install disks (Re: 8.x grudges)
2010/7/7 Mikhail T. :
> 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
On Wed, Jul 7, 2010 at 11:22 AM, Mikhail T. 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: Mouse appears on screen but does not move.
On Wed, Jun 23, 2010 at 8:21 AM, Adam Vande More wrote: > On Wed, Jun 23, 2010 at 9:46 AM, Nathan Maier wrote: > >> Hi again, >> I am pretty sure that Adam is right about the version mismatch. I used >> sysinstall to update the ports tree and had to change options from >> 8.0-RELEASE-p3 to 8.0-RELEASE. Cvsup deleted the ports tree. Don't know if >> I have to change the RELENG_8 to something else. >> > Use portsnap. Don't use sysinstall to update your ports tree. -- randi > Yeah you would want to set *default release=cvs tag=RELENG_8_0 > > You may also need to set the date if you want to keep only on RELEASE. > > If you're trying to keep your packages from that date, probably just easier > to use pkg_add -r or download directly eg > > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8.0-release/x11-drivers/ > > Make sure that is your correct ARCH > > > > -- > 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" > ___ 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: sysinstall.8 update to reflect "improved" use of netDev for scripted installs
On Mon, May 24, 2010 at 12:58 PM, Jeremy Chadwick wrote: > On Mon, May 24, 2010 at 03:33:14PM -0400, David Boyd wrote: >> Would it be possible to update the man page for sysinstall to reflect the >> new and improved usage for the netDev variable. This functionality is >> important (to me and my users) and seems to bear documenting. >> >> I realize that there may not be many users of scripted installs who care >> about this, so even a reference to the source code in sysinstall/tcpip.c >> would be acceptable. >> >> /* >> * netDev can be set to several types of values. >> * If netDev is set to ANY, scan all network devices >> * looking for a valid link, and go with the first >> * device found. netDev can also be specified as a >> * comma delimited list, with each network device >> * tried in order. netDev can also be set to a single >> * network device. >> */ >> >> There are two places in sysinstall.8 where the usage of netDev is described. >> >> Thanks, in advance, for considering this request. > > CC'ing randi@, as I'm not sure if she's on -stable or not. I am. :) And I've got a sysinstall filter to catch any mentions. I am always watching! muhahaha. sigh. Anyways, sorry about that, I kind of had it in the back of my mind that the man page and possibly the supplied example install.cfg needed updating, but I completely forgot about it. The 8.1 code freeze should be kicking in really soon, so while I'll work on changes to the documentation, I'm not sure they'll make it in time. -- 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: install touching mbr
On Sat, Apr 3, 2010 at 8:05 PM, Bruce Cran wrote: > On Saturday 03 April 2010 21:58:56 Jeremy Chadwick wrote: >> On Sat, Apr 03, 2010 at 05:48:12PM -0300, Nenhum_de_Nos wrote: >> > I just installed a 8.0R amd64 from memstick. when asked, I said to >> > leave mbr untouched. when I rebooted, it was freebsd bootloader that >> > was on control. this options is not what I think it should, or there >> > is really a issue here ? >> >> I can confirm this behaviour. Someone may have broken something when >> tinkering around in that part of sysinstall (since the Standard vs. >> BootMgr options were moved around compared to previous releases). > > I have a patch at http://reviews.freebsdish.org/r/15/ waiting to be committed. > I believe the "None" option won't change the bootcode itself but will still > mark the FreeBSD partition as active. > > -- > Bruce Cran I disagree with some of the wording. Specifically, lines 100-102 of usr.sbin/sade/menus.c "If you will only have FreeBSD on the machine the boot manager is not needed and it slows down the boot while offering you the choice of which operating system to boot." ^^ not 100% true, as the boot manager also provides the option of PXE booting. This statement seems excessively wordy and unnecessary. Also, should this be broken up into two patches? One for the change in sade, the other for sysinstall? I'm not picky about this, but you are fixing two issues in two separate programs. -- 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: 7.3-RELEASE sysinstall netDev feature
On Tue, Mar 23, 2010 at 1:51 PM, David Boyd wrote: > Randi, > > Sorry for taking so long to reply. > > I won't be able to retry this today. > > But I looked at the code in tcpip.c and the support for the comma separated > list of interface names (or netDev=ALL) is just not there in 7.3-RELEASE. > > I looked at the csup'd source and at the source from the dvd1 image. Yeah, I suspect this wasn't MFC'ed and the release notes will need to be corrected. I'm going to double check this later tonight. FWIW, if this is something you are really that interested in having work, it will work just fine in 7.3-RELEASE, you'd just have to build it yourself. -- 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: 7.3-RELEASE sysinstall netDev feature
On Tue, Mar 23, 2010 at 9:47 AM, Rink Springer wrote: > Hi David, > > On Tue, Mar 23, 2010 at 12:19:11PM -0400, David Boyd wrote: >> Is this the code committed by Rink Springer last October? > > The code I committed (revision 198317) added support for 'netDev=ANY'; > this would select the first device that has an active link. > > Note that the value is case sensitive, so only using 'ANY' will work. > >> This feature would sure be great for our many scripted installs (avoiding >> the hassles associated with plugging the cable into the wrong interface or >> having the interface type change unexpectedly due to hardware swaps). > > What exactly happens in such a case? Is the line planly ignored? Are you > using a non-interactive install? > > Regards, > > -- > Rink P.W. Springer - http://rink.nu > "Beauty often seduces us on the road to truth." > - Dr. Wilson > ___ > 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" > If you can enable debugging and take a look at the debug console, that output would be helpful. What exactly are you specifying for netDev? ANY or a comma delimited list of interfaces? Is it saying that it can't find a network interface or is it prompting you to select one? -- 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.0-RELEASE -> -STABLE and size of /
On Fri, Jan 22, 2010 at 8:27 AM, Marian Hettwer wrote: > Hi All, > > On Fri, 22 Jan 2010 17:21:56 +0100, Oliver Brandmueller > wrote: >> Hi, >> >> I just noticed somthing: I setup an 8.0-RELEASE amd64 box, / is default >> 512M. First step after setup was to csup to RELENG_8 and buildkernel and >> buildworld (no custom kernel, no make.conf). >> >> Instaling the new kernel failed, since /boot/kernel/ is already well >> over 230 MBytes in size. moving that to kernel.old and writing a new one >> with about the same size fails due to no space left on device. >> >> This is not a question; I do know how to get around this and how to >> configure custom kernels so they are a fragment of that size afterwards. >> However, I think this is a clear POLA violation. So, either GENERIC with >> less debugging information (symbols and stuff), which makes debugging >> harder or setting a higher default for / would be options, if not anyone >> else has better ideas. >> > +1 vote for making / bigger. > At least a size where a make installkernel runs through. > > I like FreeBSD because it honors POLA. > And as Oliver stated, this is a clear POLA violation. > > 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" > This is going to happen. It's been on my to-do list for a while, as I find it increasingly annoying. The default sizes of all mount points need to be tweaked a bit. Be patient, there will be some new changes going into sysinstall very soon. -- 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: Dell PowerEdge Virtual Media
On Wed, Dec 9, 2009 at 7:01 PM, Stuart Barkley wrote: > On Tue, 8 Dec 2009 at 20:07 -, Miroslav Lachman wrote: > >> Virtual Media / Virtual Console from all vendors is paint in the >> a... >> >> I have iLO card in HP ML110 G5 and Virtual Media doesn't work at >> all. Virtual device is not detected by FreeBSD nor in BIOS, so I >> can't even boot from it. >> >> Virtual Media (console) on Sun Fire X2100 M2 is accessible only by >> IP address, not by its domain name (I reported it to Sun >> Microsystems 11 month ago and Sun leaves it unfixed. >> >> In Virtual Console of Supermicro, there is problem with keyboard >> input in sysinstall prior to FreeBSD 8.x >> >> So I am disapointed by this hyped feature ;( > > Does anyone here find this stuff useful? Virtual Media is usually crap, in my experience. It's slow as hell and buggy. > We have a vendor pushing "Virtual Media" on us and I don't see the > point at all. I also don't see the point of the screen scraping and > graphics virtual display support. > > I've just started playing with IPMI capable motherboard and another > system with an IPMI add in card. Seems like at lot of extra stuff I > need to disable to secure my operations. nmap shows ssh, http, https, > portmap and some other ports of unknown purpose (plus the silly thing > was configured to send email to the manufacture). The web interface > is a little useful, but not when dealing with several hundred systems. I've never even seen an IPMI web interface. I found IPMI handy (when it worked) when it came to rebooting a frozen server - although you're running FreeBSD, so that shouldn't be a problem. ;) It's also nice for detecting hardware faults. Clearly it's something that needs to be carefully configured for your environment. > All I think I really want is basic (secure, encrypted) IPMI 2.0 to > read system status (power, temperature, fan status, etc) and be able > to power cycle the thing into a network PXE boot. > > The Serial Over Lan stuff looks useful but overly complicated (I come > from a background where we used terminal servers for console access). > I would rather see no video board in the system at all, but nobody > seems to know how to build these boards anymore. SoL works sometimes. It's another one of those slightly buggy things that you can't always count on. It *looks* useful, but usually if your machine is in a bad state - when you need it most - it's not going to work. -- 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: Re[2]: EV1 Servers makes me sick
On 10/3/06, Daniel Gerzo <[EMAIL PROTECTED]> wrote: Hello Nik, Tuesday, October 3, 2006, 4:31:11 PM, you wrote: > Alexandre Vieira wrote: >> I was also told that http://www.serverpronto.com/ is freebsd friendly and >> extremely cheap. > Since this seems to have become a recommendation thread, I'm a happy > customer of http://www.johncompanies.com/. They offer discounts to open > source contributor's too. also layeredtech.com is pretty good. Props to layeredtech. -- Randi Harper -- FreeBSD Tsarina http://freebsdgirl.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
