Re: [SOLVED] Re: labelling root file system (RELENG_8)
On Wed, Jun 8, 2011 at 10:05 AM, Jeremy Chadwick wrote: > Interestingly enough, the long procedure I originally described is > probably what was causing the problem. Not sure how to phrase it. > I don't have a reference for this, but I'm pretty sure it was on one of the mailing lists at some point. The kernel reads the super-block into memory and uses that copy when the file system is mounted. If you have the it mounted rw, then at unmount it is written back out to the disk. If it's mounted ro, the in-memory copy is thrown out and the disk isn't changed. If you upgrade a file system from ro to rw, it does not re-read the on disk copy. tunefs directly modifies on the on-disk copy regardless of mount status, so when you unmount a rw file system, anything it has done is overwritten. The only way to modify / (without alternate boot media) is what you've described below: boot single user, leave it ro, tunefs, then reboot while still ro. Also, I've seen the sysctl kern.geom.debugflags=16 thing in zfs tutorials and such, but haven't seen where it's actually necessary. I think this is outdated and changed circa 8.0. -- Rob Farmer > The exact procedure which worked was: > > - Start system > - Boot into single-user > - Hit enter at prompt (choose /bin/sh) > - mount --- shows root filesystem mounted read-only (normal) > - tunefs -t enable /dev/ada0s1a --- says it enabled TRIM support > - tunefs -p /dev/ada0s1a --- shows TRIM support enabled > - reboot > - After system starts, as root: tunefs -p /dev/ada0s1a --- shows TRIM > enabled > > So the extra rigmarole I was doing somehow caused the problem. > > -- > | Jeremy Chadwick j...@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, US | > | 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" > ___ 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: installworld: check your date/time - Installworld NOT possible...
On Thu, Dec 30, 2010 at 16:06, Chris H wrote: > Greetings, > I've spent the morning grooming a fresh kernel on a freshly installed > 8.1 amd64, from the DVD. I cvsup'd src && ports last night. > Build world && kernel && installkernel went as anticipated. > HOWEVER, a reboot to single user, followed by a mergemaster -p, followed by > cd /usr/src && make installworld, returned: > "/usr/src/Makefile", line 177: check your date/time: here> > > WTF? Should I simply comment lines 174-178? > Why does make(1) refuse to installworld? My date and time are correct (in > sync). > Any insight into this error would be GREATLY appreciated. > Did you run "adjkerntz -i" to set your timezone in single user? It starts up with the assumption that your hardware clock is UTC - depending on where you are (east/west of that), this can lead to files created in the "future," which confuses make. -- Rob Farmer ___ 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: Kernel/World Upgrade causes Hang
On Mon, Dec 27, 2010 at 17:05, Troy wrote: > # Workarounds for some known-to-be-broken chipsets (nVidia nForce3-Pro150) > device atpic # 8259A compatability > What is this? Do you actually need it? nforce 3 is pretty old - maybe it got broken somewhere along the way? It is, IMHO, the strangest thing in your kernel vs. GENERIC, which you said works. -- Rob Farmer ___ 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: /sbin/reboot
On Thu, Dec 9, 2010 at 22:46, Adam Vande More wrote: > shutdown also give operator more possibilities than a clean shutdown some > which could be very bad. > I haven't thought about the situation in any detail, but nothing jumps out at me from the manpage. You could do a denial of service thing by kicking people off or endlessly rebooting the system, but intervention to stop that should be easy enough. With reboot, you could require fsck of the filesystem, plus any fallout from databases not stopping properly, etc. Of course, this is all (or should be) academic, since people in "limited" admin groups like operator should be presumed able to escalate to root. I think operator is allowed to run dump, among other things. A big Windows security flaw is adding people to "Power Users," as if that stops anything beyond clumsy mistakes. -- Rob Farmer ___ 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: /sbin/reboot
On Thu, Dec 9, 2010 at 21:35, Adam Vande More wrote: > On Thu, Dec 9, 2010 at 11:10 PM, Mark Andrews wrote: > >> Why would you want it to be? One really shouldn't be running /sbin/reboot >> directly as part of normal operations. shutdown does a graceful reboot if >> and when operators need to perform reboot. >> > > AFAIK, the only functional difference between the two is shutdown(8) > notifies other logged in users of the impending shutdown. I've used > reboot(8) for a long time with no ill effects so I'd be interested to hear > what you meant there. Since an operator can use shutdown(8) to initiate the > same shutdown sequence reboot(8) uses, it wouldn't seems to be a security > based decision. Shutdown runs rc.shutdown (stops all rc.d scripts). Also, halt/reboot have options like -n and -q which can disrupt things worse than an unintended clean reboot. -- Rob Farmer ___ 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: TTY task group scheduling
On Thu, Nov 18, 2010 at 10:39, Chuck Swiger wrote: > Frankly, I'm also turned off by the attempt to popup a full page ad in > addition to the rest of the advertising content which surrounds what is > nominally supposed to be the real content. That doesn't mean there is > anything wrong with the patch or the notion of adjusting the scheduler, but I > don't see any value added from these phoronix.com links. Most stuff on Phoronix is of dubious value, and they have outright lied about stuff in the past, in order to drum up advertising business (such as Steam on Linux, which Value has consistently said isn't happening). -- Rob Farmer ___ 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: Cross-build failure on sparc64 for TARGET=amd64
On Fri, Oct 29, 2010 at 12:38, Nathaniel W Filardo wrote: > Running >> sudo make TARGET_ARCH=amd64 TARGET=amd64 DESTDIR=/usr/x86_64 -j4 buildworld > on >> FreeBSD sparcslave.priv.oc.ietfng.org 8.1-STABLE FreeBSD 8.1-STABLE #2 >> r214092=9050e7b-dirty: Thu Oct 21 01:25:54 UTC 2010 >> r...@t@sparcslave.priv.oc.ietfng.org:/usr/obj/usr/src/sys/SLAVKERN sparc64 I tried this about a year ago - it didn't work then and I suspect it never has. I'm not sure what the cause is. In any case, sparc's are almost always a lot slower than just building natively on amd64 hardware, so you probably aren't going to get people too excited about fixing it without tracking down the exact problem and/or sending a patch. -- Rob Farmer ___ 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"
