Re: Can't boot current under bhyve on current
Ok, if I run the bhyve commands manually, then I get a serial console. So something is just borked with vm-bhyve and its use of tmux. Whew. (Now I don't know *what*, but that's at least progress in my diagnosis!) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't boot current under bhyve on current
Ok, with debug=yes I see that it *is* running the VM -- but I have no serial console? This may be operator error here, which is a big relief. An update after I get back from the vet :). Thanks! Sean. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't boot current under bhyve on current
>Could you test with larger memory setup - instead of 512M, 1-2G? I tried multiple vcpus and 1G of RAM; it made no difference (to either my attempting to boot the system I built, or the ISO; just confirmed the ISO with 1G). Sean. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't boot current under bhyve on current
>I think vm-bhyve hides stderr output from bhyve by default, but there might >be a flag to make it display the stderr output. Can you try doing that to see >if bhyve is reporting an error? Alternatively, can you see if the bhyve >process is still running? The log file from it is below. bhyve was still running, looping on vm ioctls, until I killed it. starting bhyve (run 1) bhyve exited with status 1 destroying network device tap1 stopped initialising [loader: bhyveload] [cpu: 1] [memory: 512M] [hostbridge: standard] [com ports: com1] [uuid: ad7532de-bec1-11e9-8a55-d05099c38c95] [utctime: yes] [debug mode: no] [primary disk: disk0.img] [primary disk dev: file] initialising network device tap0 failed to find virtual switch 'public' booting bhyveload -m 512M -e autoboot_delay=3 -d /VMs/VM-TEST/../.iso/FreeBSD-13.0-CURRENT-amd64-20190725-r350322-disc1.iso VM-TEST [bhyve options: -c 1 -m 512M -AHP -U ad7532de-bec1-11e9-8a55-d05099c38c95 -u] [bhyve devices: -s 0,hostbridge -s 31,lpc -s 4:0,virtio-blk,/VMs/VM-TEST/disk0.img -s 5:0,virtio-net,tap0,mac=58:9c:fc:04:34:69] [bhyve console: -l com1,stdio] [bhyve iso device: -s 3:0,ahci-cd,/VMs/VM-TEST/../.iso/FreeBSD-13.0-CURRENT-amd64-20190725-r350322-disc1.iso,ro] starting bhyve (run 1) bhyve exited with status 1 destroying network device tap0 stopped Alan was trying to help me debug this yesterday, and I manually ran bhyve, but had no errors, and it still didn't work. Thanks, Sean. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Can't boot current under bhyve on current
I get: Loading kernel... /boot/kernel/kernel text=0x16c493c data=0x1c8b38+0x819238 syms=[0x8+0x180c18+0x8+0x19df0b] Loading configured modules... can't find '/boot/entropy' \ Note that I am using vm-bhyve as a management & control wrapper, so that was done by doing vm create VM-TEST ; vm install VM-TEST 13.0.iso Sean. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: wd driver will be retired!
In article <[EMAIL PROTECTED]> PHK writes: > >Maybe we should put a special marker in -currents sendmail and >reject all email to the current list if they don't originate >from such a system. > >I'll tell you in case you can't figure out the answer to that rather >simple question: You're annoying people and wasting developer >time. That's what. And further evidence that FreeBSD is turning into PHKBSD: what PHK wants, despite objections from other people, PHK does, and damn any consequences, whether they be social, political, or technical. Several people have raised valid objections to PHK's actions (again -- at least he bothered warning people this time), and have proposed an alternate solution, which PHK has ignored (again -- at least this time he bothered saying so). And, once again, PHK's response is: shut up and go away. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH for testing
In article <[EMAIL PROTECTED]> you write: >The p_args.patch patch implements a cache of the commandline arguments >in the process structure and makes ps(1) pick it up from there with >sysctl rather than by groping around in the target process memory. I don't think this should go in at all. It increases the size of the proc structure (thereby affecting _all_ processes) gratuitously. While I'm generally in favour of having the process arguments kept around, the "BSD way" has been to only examine them in user memory, despite that being unreliable and just annoying. The benefits are fairly minimal, and I don't believe justify the cost incurred. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CSS authentication for DVD-ROMs
>Given the recent posting of DVD movie decryption code (see Slashdot >for details), I was wondering if there was interest for code that >does CSS authentication for DVD-ROM drives. I looked at the slashdot posts, and was surprised (I guess) to see that nobody seems to know about the Digital Millennium Copyright Act. Part of which makes it a copyright violation (at $2500/copy distributed) to "manufacture or distribute technology" which can be used to bypass encryption of digital works. E.g., DVDs. I'm reasonably sure that parts of this will be struck down for constitutional reasons, but until it is... it's a very risky thing to do. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: People getting automatically unsub'ed from -arch
In article <[EMAIL PROTECTED]> you write: >You have no way of knowing whether inbound mail to you has bounced, or >not. Why are you so adamant that mail has not bounced? Becuse I get lots of email, because I check it constantly, because any of a half dozen sources for it bouncing would result in my being notified on another system, because my secondary MX server has better network connectivity than the freebsd systems, because the only one who has ever made any accusations about bouncing mail has been jmb and he hasn't been able to provide any proof? >To those who _have_ experienced problems, remember this is a volunteer >effort. Would you flame someone on a public list if you found a bug >in the code they had contributed? If, after *FIVE YEARS* it hadn't been fixed, yes. That's how long this has been going on. Five years of people finding themselves mysteriously removed from lists, with no response other than, "Oh, I just remove people automatically without warning if I get too many bounces, and, no, I don't have any bounces from you but that must have been what happened." Except for one time when he admitted that he accidentally removed a bunch of people when editing a file by hand. Whatever method he is using is not working very well, and it has not worked very well for a very long time. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: People getting automatically unsub'ed from -arch
In article <[EMAIL PROTECTED]> you write: > only one comment. i remove people from the lists whenever >their email bounces. the threshhold is approximately 30 messages in a >24 hour period. mail may bounce due to DNS problems, mail box full, >MTA misconfiguration. i also remove people that send vacation >messages to the list. oh, and spammers. My mail _has not bounced_. And yet I have been removed. > several people with recurring email delivery problems have >written a script to monitor their subscriptions for them. Goody for them. Since I do not have recurring email delivery problems, there is no reason why I should go out of my way. And, interestingly enough, I'm not the only person this has happened to, and all you can do is blame every single one of them for having "recurring email delivery problems." When are you going to realize there is a problem and admit it? When are you going to get it _fixed_? Or is your life easier if there is nobody on any of the lists? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: People getting automatically unsub'ed from -arch
In article <[EMAIL PROTECTED]> Nate writes: >I note that David is no longer on the list ([EMAIL PROTECTED] was >'unsubscribed, either accidentally or intentionally). Justin is gone, >and many other folks I would have considered to be folks interested that >were once subscribed... "Accidental" removals from the lists are so common that I give up. I no longer even try to get back on them -- it's been happening for _years_ now, and I have made multiple complaints about it, and if it's not a problem for whoever runs the mailing lists, then I just don't care that much. I have a hard enough time remembering which lists I subscribed to that I do get traffic on to check every day to see which ones have removed me without informing me. And, yip, I was apparently removed from [EMAIL PROTECTED], despite being subscribed to it within a few hours of it having been initially created. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: nice little kernel task for somebody
>> Here's a thing I've missed a couple of times: I'd like to be >> able to see the limits for a process in /proc. At some point, I want to add an ioctl to get various process information (well, multiple ioctl's, I think); SysVr4 has a bunch, and that's what I'd model it on. >I'd like to be able to open processes file discriptors too (so >you can still get files back if all the filsystem references to >it have gone, but a process still has it open). I might have a >go at doing both - if it isn't too Linuxesque. Ugh. I don't particularly like that one. It's fairly rare, and very invasive, and gives me the willies. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: adding DHCP client to src/contrib/
In article you write: >What impact will this have on the rc files? How will it affect >rc.conf, seeing as it overrides several values therein? PAO already has some support for this; it works, and is what I've been using. >What happens >if your lease expires and doesn't get renewed, or gets renewed with a >different IP address? That's always a problem -- I know some people at uSoft who have that happen (in Windows), and it kills their telnet sessions. It's not something we're going to be able to solve, and there really isn't one. >Having seen the complete mess that DHCP client support made of >Solaris' init files (and they were bad to start with!), I'm keen to >not see the same convolution made here. Fortunately, it shouldn't be that difficult. There's a freebsd shell script that comes with isc-dhcp that does the brunt of the work, and dhclient invokes that itself. So all the rc scripts have to do is notice that the IP address is being set by DHCP, and start dhclient, instead of running ifconfig. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: adding DHCP client to src/contrib/
In article <19990209091330.18608.qmail.kithrup.freebsd.curr...@rucus.ru.ac.za> you write: >I would still >be very reticent to see BPF in a generic kernel because of the security >implications. I'm sorry, but that's a complete non-issue: 1. /dev/bpf0 is mode 400, root.wheel -- to read it, you need to break root. 2. If you can break root, you can rebuild a kernel with BPF *anyway*. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: adding DHCP client to src/contrib/
In article <19990209082922.17759.qmail.kithrup.freebsd.curr...@rucus.ru.ac.za> you write: >- DHCP-WIDE requires you to have bpf configured into your kernel > for a GENERIC kernel, this is VERY BAD - is there a more elegant > way to handle this? I certainly would not like to see the > generic kernel in the distribution going out into the world with > bpf enabled. So does isc-dhcp. There's really no other way to do it: you need the ability to grab packets that come from an unidentified machine, which doesn't have an IP address. You could write some other method of doing this -- and then put it into every single ethernet (et al) device driver -- or you could just use BPF, which really isn't all that large. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: adding DHCP client to src/contrib/
In article you write: >Hmmm.. This annoyed me actually.. >There is NO config file which means its damn annoying for you to tweak how it >works.. Would you please settle on a set of misinformation and stick with it? isc-dhcp's client *does* have a very extensive configuration file. Same parser as the server. In 99.9% of cases, it needs to be a 0-length file. In some other cases, it needs to be configured. Due to a bug in the version of isc-dhcpd at work, for example, I needed to have a /etc/dhclient.conf file that looked like: send dhcp-client-identifier "sef-laptop"; There are a bunch of things I could specify. Interestingly enough, they're documented in dhclient.conf(5), which comes with the isc-dhcp package. So: not only does isc-dhcp have extensive configuration options, but, in the common case, it's not needed at all. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: adding DHCP client to src/contrib/
In article <19990209074440.15845.qmail.kithrup.freebsd.curr...@rucus.ru.ac.za> you write: >Is DHCP core functionality? As much as an editor and PPP are, yes -- without it, some people simply *cannot* get on the net. >Anyone putting any DHCP functionality in should look >very seriously at any possibilities of combining the functionality, >rather than creating what amounts to a degree of redundancy. I think isc-dhcp can do both; however, it may only be the server that has that functionality. >I personally would prefer to see DHCP left a port. How would someone on a network and without a CD-ROM install it? (I recently had the joy of doing this, incidently... I ended up unplugging one of the other computers and using is IP address until the installation was complete.) That, I believe, is the reason that it's time to consider putting it in. (I've only used the ISC code, and, for several reasons, am biased in its favour, but I don't think it really matters.) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: "JAIL" code headed for -current.
>But then we're still having an API change that doesn't have to be there.
No, it's not.
If you change suser() to:
int
suser(uc, ac)
struct ucred *uc;
u_short *ac; {
return JAILsuser(0, uc, ac);
}
then suser() continues to have the same semantics and calling convention; you
can speed this up a bit by having:
#define suser(a,b) JAILsuser(0, a, b)
in (where suser's prototype is).
Then you can simply change the calls from suser() to JAILsuser() as needed.
(Actually, JAILsuser is a bad name, really, since this could also be used to
move to a more-capability-based mechanism, with the "jail" being simply one
set of resources to compare the requested capability against. But that's just
a thought that has occurred to me, and I haven't spent any time making it
coherent ;).)
Doing it this way should result in a superset, and minimal source code
changes; doing it with just the stub routine would result in minimal binary
impact as well.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: "JAIL" code headed for -current.
In article <199901271944.laa15317.kithrup.freebsd.curr...@kithrup.com> you write: >>all over the kernel: >> >> suser(NOJAIL, bla, bla); >>or >> suser(0, bla, bla); >Oh, goody, more gratuitious incomaptibilities with everyone else. And to followup to my own message, since nobody else has: This is stupid. While I don't object to the concept (and even know people who have requested it), that particular implementation sucks. It breaks an existing API *and* ABI. I would suggest using a different routine name than suser(); suser() can be made into a macro or stub routine that calls the new routine with a first argument of 0 (or, of course, both a macro *and* a stub routine). Any time there's a change, "all over the kernel," THIS SHOULD RAISE WARNING FLAGS, PEOPLE! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: "JAIL" code headed for -current.
In article <29763.917434096.kithrup.freebsd.curr...@critter.freebsd.dk> you write: >The biggest impact of this is a new argument to the suser() call >all over the kernel: > > suser(NOJAIL, bla, bla); >or > suser(0, bla, bla); Oh, goody, more gratuitious incomaptibilities with everyone else. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: PATCH for testing
In article <[EMAIL PROTECTED]> you write: >I am all for removing -e, but I don't really like the idea of making >it optional nor do I like the idea of trying to maintain the capability >for the user's own processes - that simply makes the code even more >complex then it already is. The danger is that the option exists in >the first place. I both do and do not want it to be removed. The code _does not_ need to be more complex, as procfs already implements the correct restrictions. (Simply dropping the SGID bit off of ps(1), and teaching it to use procfs only, will do it; dropping the SGID bit, and having it use /proc//mem instead of /dev/kmem, will do the same thing. I believe; I don't know ps well enough to figure this all out yet, but that was certainly one of my goals when I wrote the bloody thing.) P.S. You see that Reply-To: line in the header? It's there for a reason. If you must override it, don't send it to both me and the list. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
