Re: disk management
On Fri, Jan 13, 2012 at 04:20:07PM +0200, Vitali wrote: There is one more philosophical side effect of this question - speed. The closer the partition is placed to the outer cylinders, the faster the data are read from it. More a methaphysical question. On modern disks, the correspondence between block/cyl number and physcial location is very blurred. B B B B -Otto Yeah, Otto, I'm aware of it, and still that makes me experiment every time I got an opportunity to. Anyway, you can use your system for years, upload and delete little and large files, but defragmentation ratio is very close to 0.0%. Either the system is not aware of this location blur or really the system sees that the file blocks location is indeed convenient for the system. In my experiments I saw large avi files being copied to the outsider /usr from a flash device 4.5mb p/s, and to the insider /var slower - depending on the size of the /usr - from 2.7mb p/s to 3.2mb p/s. I'm not insisting, I'm only telling about the results of my experiments... :) I know very little about physical design of HDD's and the vendors do not feel like sharing that information. :) Hww scientific, conduct one experiment and distill a general rule from it. -Otto
'pkg_add -u' question
I have a notebook with a couple of devices which require non-free firmware. When I installed 5.0-release (amd64 from CD) it asked me if I wanted those files downloaded on first boot; when I said YES it proceeded to find and download them and everything 'just worked'. (This was very convenient; my thanks to the developers who made it happen.) But when I upgraded to a 5.0-current snapshot (and later rebuilt from source, most recently as of 9 January 2012) and then ran 'pkg_add -ui' it was unable to update those files: Couldn't find updates for uvideo-firmware-1.2p0, iwn-firmware-5.6p0. I'd expect that making 'pkg_add -u' able to find these files would be fairly simple (either by giving it access to the same data used by the installer or by recording where it was found with any package added from a source not in PKG_PATH), and it would certainly make life a bit more convenient when upgrading. Am I missing something important, is this on someone's TODO list, do the installer and pkg_add developers not talk to each other, or what? Thanks in advance for any information. Dave PS: Before someone jumps all over me, I am _not_ demanding that anyone drop everything and implement this immediately; I'd just like to understand why this doesn't work and whether it's likely to start working anytime soon. And I recognize we've got more urgent/important things to do as a good reason for leaving this alone. I haven't looked into the pkg_add source myself because it's large, complicated and (especially) under active development. -- Dave Anderson d...@daveanderson.com
Re: 'pkg_add -u' question
Hi Dave, Dave Anderson wrote on Sat, Jan 14, 2012 at 12:14:57PM -0500: and then ran 'pkg_add -ui' it was unable to update those files: Couldn't find updates for uvideo-firmware-1.2p0, iwn-firmware-5.6p0. The firmwares live in a different package repository, that's why pkg_add(1) doesn't find them by default. If you do want to check for new firmwares, take the above message as a reminder to run $ sudo fw_update manually. But note that's not necessarily related to doing an operating system upgrade. I'd expect that making 'pkg_add -u' able to find these files would be fairly simple (either by giving it access to the same data used by the installer or by recording where it was found with any package added from a source not in PKG_PATH), I'm not sure i would want pkg_add(1) to look outside the PKG_PATH. and it would certainly make life a bit more convenient when upgrading. Am I missing something important, is this on someone's TODO list, The only (potential, minor) problem i see is that people might run pkg_add(1), see the couldn't find, and not know about fw_update(1). That's probably what happened to you. I'm not sure how to improve that. Messages printed by programs should be terse, so i don't think pkg_add(1) should print a suggestion to run fw_update(1) when it sees *-firmware-* packages it can't update. Most people will know that anyway, and there is no strong reason to check for firmware updates at that particular time. Maybe it could be mentioned in the pkg_add(1) manual. Then again, that manual doesn't document the Couldn't find updates diagnostic at all, so far. do the installer and pkg_add developers not talk to each other, Actually, i have met all of krw@, halex@ and espie@ at least twice during hackathons, but never together; so you may have a point... :-D /irony But no, that's not the root cause of the issue. Yours, Ingo
Re: 'pkg_add -u' question
Dave Anderson wrote: I have a notebook with a couple of devices which require non-free firmware. When I installed 5.0-release (amd64 from CD) it asked me if I wanted those files downloaded on first boot; when I said YES it proceeded to find and download them and everything 'just worked'. (This was very convenient; my thanks to the developers who made it happen.) But when I upgraded to a 5.0-current snapshot (and later rebuilt from source, most recently as of 9 January 2012) and then ran 'pkg_add -ui' it was unable to update those files: Couldn't find updates for uvideo-firmware-1.2p0, iwn-firmware-5.6p0. I don't think the firmware files live in the same place as ordinary packages. I expect that the place these files reside is not in your PKG_PATH. If I remember correctly you should have a similar check for firmware files option during upgrades as during install. Did you check your (or root's) mail ? I think there might be a message telling whether it was necessary to update any firmware files. I'd expect that making 'pkg_add -u' able to find these files would be fairly simple (either by giving it access to the same data used by the installer or by recording where it was found with any package added from a source not in PKG_PATH), and it would certainly make life a bit more convenient when upgrading. Am I missing something important, is this on someone's TODO list, do the installer and pkg_add developers not talk to each other, or what? AFAICT the tool used is fw_update(1). $ file /usr/sbin/fw_update /usr/sbin/fw_update: Bourne shell script text executable You could check this script to see if it has any clues to help you fulfill your expectations.
gvrp support
hello! does OpenBSD support GVRP ? Cheers, Ilya Shipitsin
Re: 'pkg_add -u' question
On Sat, Jan 14, 2012 at 06:51:05PM +0100, Ingo Schwarze wrote: Hi Dave, Dave Anderson wrote on Sat, Jan 14, 2012 at 12:14:57PM -0500: and then ran 'pkg_add -ui' it was unable to update those files: Couldn't find updates for uvideo-firmware-1.2p0, iwn-firmware-5.6p0. The firmwares live in a different package repository, that's why pkg_add(1) doesn't find them by default. If you do want to check for new firmwares, take the above message as a reminder to run $ sudo fw_update manually. But note that's not necessarily related to doing an operating system upgrade. I'd expect that making 'pkg_add -u' able to find these files would be fairly simple (either by giving it access to the same data used by the installer or by recording where it was found with any package added from a source not in PKG_PATH), I'm not sure i would want pkg_add(1) to look outside the PKG_PATH. and it would certainly make life a bit more convenient when upgrading. Am I missing something important, is this on someone's TODO list, The only (potential, minor) problem i see is that people might run pkg_add(1), see the couldn't find, and not know about fw_update(1). That's probably what happened to you. I'm not sure how to improve that. Messages printed by programs should be terse, so i don't think pkg_add(1) should print a suggestion to run fw_update(1) when it sees *-firmware-* packages it can't update. Most people will know that anyway, and there is no strong reason to check for firmware updates at that particular time. Maybe it could be mentioned in the pkg_add(1) manual. Then again, that manual doesn't document the Couldn't find updates diagnostic at all, so far. do the installer and pkg_add developers not talk to each other, Actually, i have met all of krw@, halex@ and espie@ at least twice during hackathons, but never together; so you may have a point... :-D /irony But no, that's not the root cause of the issue. Yours, Ingo i guess we haven;t done a great job of advertising fw_update. for example, no other man page references the tool. it certainly isn;t helpful that pkg_add informs you that it hasn;t been able to find updates. i'm not sure how easy it would be to fix, but it might be better if it said nothing at all (though then you would probably forget they were installed at all). i think at a minimum pkg_add probably should document that fw_update handles non-free firmware, and we should probably update the packages section of afterboot(8) too. however i'm not sure when the author intended fw_update to be used. i.e. in the course of upgrading or whenever you please. jmc
Re: 'pkg_add -u' question
On Sat, 14 Jan 2012, Ingo Schwarze wrote: Hi Dave, Dave Anderson wrote on Sat, Jan 14, 2012 at 12:14:57PM -0500: and then ran 'pkg_add -ui' it was unable to update those files: Couldn't find updates for uvideo-firmware-1.2p0, iwn-firmware-5.6p0. The firmwares live in a different package repository, that's why pkg_add(1) doesn't find them by default. If you do want to check for new firmwares, take the above message as a reminder to run $ sudo fw_update manually. But note that's not necessarily related to doing an operating system upgrade. Thanks for the pointer; fw_update looks like it's exactly what I need. I'd expect that making 'pkg_add -u' able to find these files would be fairly simple (either by giving it access to the same data used by the installer or by recording where it was found with any package added from a source not in PKG_PATH), I'm not sure i would want pkg_add(1) to look outside the PKG_PATH. and it would certainly make life a bit more convenient when upgrading. Am I missing something important, is this on someone's TODO list, The only (potential, minor) problem i see is that people might run pkg_add(1), see the couldn't find, and not know about fw_update(1). That's probably what happened to you. Yes. I'm not sure how to improve that. Messages printed by programs should be terse, so i don't think pkg_add(1) should print a suggestion to run fw_update(1) when it sees *-firmware-* packages it can't update. Most people will know that anyway, and there is no strong reason to check for firmware updates at that particular time. Maybe it could be mentioned in the pkg_add(1) manual. Then again, that manual doesn't document the Couldn't find updates diagnostic at all, so far. Perhaps when the 'Install non-free firmware files on first boot' option is selected the installer should mention fw_update? And/or 'pkg_add -u' should mention it as a possible solution if it issues the couldn't find message? I probably should have tried 'apropos firmware', but was fixated on pkg_add and didn't think to look for a different tool. _Some_ sort of more prominent mention of fw_update appears to be desirable. Dave do the installer and pkg_add developers not talk to each other, Actually, i have met all of krw@, halex@ and espie@ at least twice during hackathons, but never together; so you may have a point... :-D /irony But no, that's not the root cause of the issue. Yours, Ingo -- Dave Anderson d...@daveanderson.com
Re: Multiple ISP-connections/Routing/Packet filtering
Hello, Unfortunately, the pf.conf syntax has changed since v4.6 and while I do plan to upgrade my own firewall to v5.0 (I've bought the CD already) I haven't yet had time to perform the upgrade. As a result, I haven't worked out what the equivalent 'modern' syntax would be, but you might be able to get some hints from what I'm using in v4.6. I'm really looking forward the result of your upgrade. I have a plain pass in on $if_bnt inet proto tcp to any port 25 reply-to $if_bnt, I can see traffic comming through $if_bnt but never see any response going out (on any interface). I can see a state is created in the state-table. SMTP port is answering on another internet-facing interface without any problem. If I change the rule to pass in on $if_bnt inet proto icmp reply-to $if_bnt, I can see a state is created, I can see the icmp-request comes through $if_bnt but icmp-reply goes out through another internet-connected interface. I read on some website that (FreeBSD pf's) reply-to only works with traffic passing through the router but not with traffic terminating on the router. Denis
Re: gvrp support
Ilya Shipitsin chipits...@gmail.com wrote: does OpenBSD support GVRP ? No. -- Christian naddy Weisgerber na...@mips.inka.de
Servizi innovativi
Nuovi servizi finanziari
Re: 'pkg_add -u' question
On 2012-01-14, Jason McIntyre j...@cava.myzen.co.uk wrote: however i'm not sure when the author intended fw_update to be used. i.e. in the course of upgrading or whenever you please. fw_update is run automatically on the first boot after you upgrade via the usual installer (bsd.rd / install51.iso / cd51.iso etc).
Re: 'pkg_add -u' question
On Sat, Jan 14, 2012 at 10:13:07PM +, Stuart Henderson wrote: On 2012-01-14, Jason McIntyre j...@cava.myzen.co.uk wrote: however i'm not sure when the author intended fw_update to be used. i.e. in the course of upgrading or whenever you please. fw_update is run automatically on the first boot after you upgrade via the usual installer (bsd.rd / install51.iso / cd51.iso etc). right. but is there any reason to discourage people from running it when they please, or do we just expect it to be done automatically after upgrade? i ask because we need to watch how we word this. we could reasonably assume that people would also run it from time to time just to see if there's an update available, right? jmc
Re: UPGRADE DAMNIT
+1 remote upgrades are so clean and effective, and the directions are clear enough that I've not been able to drink enough beer to interfere with the process. On Fri, Jan 13, 2012 at 11:45 AM, Marc Espie es...@nerim.net wrote: On Thu, Jan 12, 2012 at 05:16:15PM +, Kevin Chadwick wrote: I'm surprised you've had so much help. Personally and If I had time I'd want to find out the problem but I'd be wiping and reinstalling from scratch anyway, especially with an unknown cause. Of course having install scripts makes that decision much easier. It shouldn't be hard to copy your configs off, just make a root drive backup first in case you miss something. Surely faster than reading the upgrade guides for 7 releases. Boohoo. 7 releases. That's called backlog. Or dropping the ball. Upgrade every six months or every year and you won't have to suffer through this ! As far as I'm concerned, the major advantage OpenBSD has over lots of other stuff is that you can decide to update much more easily. The only question in 99% of the cases is: do you have enough time to do it ? The next version of the OS is always better than the previous one, and generally, all things that used to work do work still. If something breaks, it's considered a major issue to be fixed shortly. Heck, even though we sometimes mothball some old shit, we're agressively promoting the use of completely obsolete wacky hardware thanks to our obsessive-compulsive old-shit specialists. We have a track-record of still running on cheese boxes that the distinguished competition abandonned years ago. As opposed to a lot of other places where generally, you waitsee on the ml for a few weeks to make sure your stuff won't fall apart when you update.
OpenBSD related jobs?
OpenBSD is so far above and beyond anything else out there that I am having a hard time using other systems. I would *love* to work for an OpenBSD-centric company, either part-time, or full-time, preferably from home. Feel free to email me at s...@ramov.com for further details, if you're interested. Thanks, -Sime
Re: 'pkg_add -u' question
Jason McIntyre [j...@cava.myzen.co.uk] wrote: right. but is there any reason to discourage people from running it when they please, or do we just expect it to be done automatically after upgrade? i ask because we need to watch how we word this. we could reasonably assume that people would also run it from time to time just to see if there's an update available, right? How often is firmware updated without a maching driver update? fw_update is really just to provide an automated fuction during install or upgrade, the same time when you are getting a new kernel/drier, it would be rare that a new firmware is available for an existing system, although potentially useful given how buggy some of these things are. -- There are only three sports: bullfighting, motor racing, and mountaineering; all the rest are merely games. - E. Hemingway
Re: 'pkg_add -u' question
On Sat, Jan 14, 2012 at 10:13:07PM +, Stuart Henderson wrote: On 2012-01-14, Jason McIntyre j...@cava.myzen.co.uk wrote: however i'm not sure when the author intended fw_update to be used. i.e. in the course of upgrading or whenever you please. fw_update is run automatically on the first boot after you upgrade via the usual installer (bsd.rd / install51.iso / cd51.iso etc). right. but is there any reason to discourage people from running it when they please, or do we just expect it to be done automatically after upgrade? i ask because we need to watch how we word this. we could reasonably assume that people would also run it from time to time just to see if there's an update available, right? people can run fw_update any time they want to, and yes if there are newer firmwares it will pick them up.
Re: The (unofficial) opebsd repo in github is outdated
On Sat, 14 Jan 2012 01:46:50 +0100, joshua stein j...@jcs.org wrote: The openbsd repo in github is outdated. Are the owners reading the list? Can someone update the repo?. Github doesn't show me a contact address for the organization, so I thing this list is the best option for report the problem. the cvs-to-git conversion tool i was using was not producing 100% accurate trees, leaving some extra files in some of the release branches and causing some builds to break. the trees were not being updated while i was resuming work on my own conversion tool to fix these problems. since a few people have asked about them, i've just deleted the github repos to avoid confusion. the new trees will have different histories and git commit hashes so they will need to be re-downloaded/forked anyway. i will push the new trees back up to github when the tool is finished and i have verified that all of the branches are identical to the cvs versions. Thanks for your work. I noticed the problem in December but I preferred give some of time to the owners before of report the problem. I was reading yesterday about the available conversion tools cvs - git. The conversion seems a very complex task. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: 'pkg_add -u' question
How often is firmware updated without a maching driver update? fw_update is really just to provide an automated fuction during install or upgrade, the same time when you are getting a new kernel/drier, it would be rare that a new firmware is available for an existing system, although potentially useful given how buggy some of these things are. it has already happened plenty of times before fw_update was created -- as a result, why fw_update was created by halex at my request. in that timeframe since, no new firmwares have shown up in the place where fw_update looks. unfortunately that is not proof that this will not happen in the future. so the answer to your question is: At least once in the future.
Re: locate weirdness
On Fri, Jan 13, 2012 at 1:02 PM, L. V. Lammert l...@omnitec.net wrote: Thanks again to those that actually read the original question, .. I am continuing to try and resolve the issue. Any progress? I see plenty of replies to the people that you *don't* think are helping you but no reply to my question about what user you think locate.updatedb runs as, something which does factor into being able to solve this... Philip Guenther
Re: 'pkg_add -u' question
I have a notebook with a couple of devices which require non-free firmware. When I installed 5.0-release (amd64 from CD) it asked me if I wanted those files downloaded on first boot; when I said YES it proceeded to find and download them and everything 'just worked'. (This was very convenient; my thanks to the developers who made it happen.) But when I upgraded to a 5.0-current snapshot (and later rebuilt from source, most recently as of 9 January 2012) and then ran 'pkg_add -ui' it was unable to update those files: Couldn't find updates for uvideo-firmware-1.2p0, iwn-firmware-5.6p0. I'd expect that making 'pkg_add -u' able to find these files would be fairly simple (either by giving it access to the same data used by the installer or by recording where it was found with any package added from a source not in PKG_PATH), and it would certainly make life a bit more convenient when upgrading. Am I missing something important, is this on someone's TODO list, do the installer and pkg_add developers not talk to each other, or what? It is not simple. While pkg_add has a PATH that it will look at, last time I tried this it only uses the first component of the path that is successful. It does not want to mix contents. Anyways, the result is that this does not work. Until it does, use fw_update.
Re: locate weirdness
On Sat, 14 Jan 2012, Philip Guenther wrote: Any progress? I see plenty of replies to the people that you *don't* think are helping you but no reply to my question about what user you think locate.updatedb runs as, something which does factor into being able to solve this... The answer was already posted, .. perhaps you missed it? Lee
