Re: Boot hangs in single-user mode
I have tracked down the issue. Not sure whether this is a PR issue or not... On 2013-06-06, at 11:18 AM, Polytropon wrote: On Thu, 6 Jun 2013 10:24:52 -0300, Andrew Hamilton-Wright wrote: Strangely, it seems that I cannot boot single user, either using boot -s from the boot loader, or using the boot menu. When I get to the point where the root filesystem is mounted, it hangs right after printing the message: Trying to mount root from ufs:/dev/ada0s1a Have you tried hitting the RETURN key several times? [ ... ] It's important to identify if the system is _really_ hanging, or if the message just isn't visible... This is indeed the crux of the issue. While hammering on the RETURN key did not produce a prompt, it turns out that there was a prompt... At some time in the relatively distant past, I had configured this machine to allow display to a serial console (long since disconnected) by adding these lines to /boot/loader.conf boot_multicons=YES boot_serial=YES comconsole_speed=19200 console=comconsole,vidconsole My notes say These came from the serial console setup page, and do work for vt100, however I did not note exactly which man page they came from, unfortunately. I do not see these lines on syscons(4), sio(4) or dcons(4). Similar lines are mentioned in the handbook regarding setting up a serial console (there is no mention of single-user mode here): http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html The issue, as it relates to single-user mode, is essentially this: if the system is configured to boot with multi-console options, then when the single user prompt is printed, it is only printed on the second console (which is also the only valid source of keyboard input) -- in this case, the configured but unattached serial port. I'm not sure what the best strategy is here. Having only one console that is accepting input for the single-user shell certainly makes sense. The question is, which of potentially several consoles should it be? IMO, it would be better/clearer if (for i386/amd64 anyway) the console was the one associated with the motherboard-based keyboard and video card. An argument here would be that the [CTRL]-[ALT]-[DEL] sequence is still valid when associated with this keyboard, so it does seem odd that other input on that device is ignored. I can see arguments for other setups, also, mostly revolving around the why would you _have_ another console configured if you didn't need it, so the configured console must therefore be the important one -- though the FreeBSD user base is certainly willing enough to experiment that I am sure I am not the only person who set up multi-console for a fun project. Perhaps the best strategy would be to add a message printed on all consoles (as the rest of the boot information is) just before the prompt is printed (singly) to let people know that this is happening? I'm not sure if a way to 100% predict the desired console is possible. Thoughts? If figure I will put a PR in, so that at least this is tracked, even if we don't change anything. I will reference this thread in the PR, but if anyone has input as to what to suggest, I would appreciate it. At the very least, the handbook should get updated to indicate that this may happen. Andrew. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Boot hangs in single-user mode
Hi Everyone, On Thu, 6 Jun 2013 10:24:52 -0300, Andrew Hamilton-Wright wrote: Strangely, it seems that I cannot boot single user, either using boot -s from the boot loader, or using the boot menu. When I get to the point where the root filesystem is mounted, it hangs right after printing the message: Trying to mount root from ufs:/dev/ada0s1a There was a bit of a delay getting back to this, as I needed to move the internals over to a replacement server in a planned upgrade. I have left the boot disk in the machine demonstrating this problem with the intention of coming back to determine what is going on (mount points to now-missing data disks have been removed from /etc/fstab). In the resulting stripped down system, I have the same behaviour as before -- I cannot get to single-user mode, but multi-user is fine. If in multi-user mode, if I issue kill -TERM 1 to go to single-user mode, I would get a single console message: pflog0: promiscuous mode disabled, then nothing. While I would expect pflog to shut down in this case, I have now disabled everything pf related (I cannot imagine that it would interfere with console operation), and now have the situation where kill -TERM 1 simply locks the console. Plugging in a USB device while the console is locked does produce the expected dmesg updates, and the system does respond to [CTRL]-[ALT]-[DEL] I will also add that I can boot to a single-user prompt when booting off of the 9.1 media via DVD and mounting the root filesystem from the disk. (This motherboard+kernel have never gotten along particularly well with the DVD reader/writer in the machine, so mounting the filesystem from the DVD usually fails with various atapi based timeouts). Does anyone have any thoughts on how to further explore this? As the situation was more than mildly annoying, and could certainly have been worse, if this is likely to occur for anyone else, I would like to file a PR. Thanks, Andrew. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Boot hangs in single-user mode
Strangely, it seems that I cannot boot single user, either using boot -s from the boot loader, or using the boot menu. When I get to the point where the root filesystem is mounted, it hangs right after printing the message: Trying to mount root from ufs:/dev/ada0s1a Interestingly, there seems to be a bit of a sequence issue, as I have also seen the mount message appear before the audio system comes up, so occasionally, the last item printed is: pcm0: USB audio on uaudio0 If I boot normally, however, I can consistently reach a login prompt. I suspect that this may be a race condition of some kind, as yesterday I am sure I successfully booted to single-user while trying to solve a separate problem. In case the separate problem (failed disk) is relevant, the general situation is this: - four disk machine: ada0 (/, /usr, /tmp, /var); ada1 (/research -- data only), ada2 (/home), ada3 (/data -- also data only) - the disk ada2 has failed - in preparing to replace ada2, I have commented out all references to it from /etc/fstab I am rebooting the machine at the moment as I wish to ensure that I know which physical disk is ada2, so want to boot the machine without it plugged in. I seem to have trouble booting at all with ada2 missing and ada3 still attached, but can boot to multiuser with no problems in either of these two configuration: - all disks (including the faulty one) plugged in, with ada2 references removed from /etc/fstab - ada2 and ada3 not physically plugged in, and all references to either removed from /etc/fstab Neither combination allows me to boot single-user. While I can clearly go ahead with my disk replacement, this is not only strange and annoying, but potentially problematic. Has anyone else seen anything like this? I notice that there are several messages (dating back to 2004) in the list indicating 'hang after Trying to mount root' or 'hang after sbin_init' (which is the message that will be seen when booting single-user in verbose mode). Thoughts? Ideas? Thanks, Andrew. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Boot hangs in single-user mode
[ Condensation of earlier comments below ] On 2013-06-06, at 11:18 AM, Polytropon wrote: On Thu, 6 Jun 2013 10:24:52 -0300, Andrew Hamilton-Wright wrote: When I get to the point where the root filesystem is mounted, it hangs right after printing the message: Trying to mount root from ufs:/dev/ada0s1a Have you tried hitting the RETURN key several times? ... It's important to identify if the system is _really_ hanging, or if the message just isn't visible... I did try that -- I have seen that behaviour before too. I tried hitting return a half-dozen times, and have additionally tried waiting (up to 20 min) to see if it would come back, to no avail. Interestingly, there seems to be a bit of a sequence issue, as I have also seen the mount message appear before the audio system comes up, so occasionally, the last item printed is: pcm0: USB audio on uaudio0 This seems to indicate that the system is still responding, i. e., the kernel is up and running. Whenever new hardware is detected, the kernel will issue a console message. That is a good point -- I will try plugging in an external USB device at this point, and see what happens then. It certainly appears that the system is generally running to me, as well. I should also mention that the system does respond nicely to [CTRL]-[ALT]-[DEL], which triggers the expected reboot process. I am rebooting the machine at the moment as I wish to ensure that I know which physical disk is ada2, so want to boot the machine without it plugged in. A suggestion: I tend to keep a tendency to use labels instead of device names to identify disks. This is handy in case you're This is an excellent idea. I do follow some variant of this (however work at a high enough level of paranoia that I want to be able to perform the did the right drive disappear when I unplugged it check just to ensure that I wasn't asleep when making up the labels. ;-) Thanks for the suggestions -- I will keep looking at it, and will try adding a USB device once this restore eventually completes. Thanks, Andrew. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Long I/O pauses on same mass storage
Sorry to follow myself up . . . On Wed, 12 May 2010, A. Wright wrote: I just noticed, however, the following two interesting lines that /var/log/messages seems to have acquired: May 12 15:44:00 qemg kernel: ad8: FAILURE - SMART status=51READY,DSC,ERROR error=4ABORTED May 12 16:05:27 qemg kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 294, size: 8192 It turns out that dmesg output has a number of these, scattered over the last day; there were a bunch at 02:30 this morning; which at least indicates that the SMART logging has triggered this behaviour. A. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Long I/O pauses on same mass storage
On Wed, 12 May 2010, Adam Vande More wrote: On Wed, May 12, 2010 at 6:21 PM, A. Wright and...@qemg.orgmailto:and...@qemg.org wrote: As far as I can tell, it is a standard 512 byte sector. The general lack of documentation with this drive (shipped in a plastic coffin -- the only docs supplied with it were the label itself), but on the WD site, they indicate: Formatted Capacity 1500301 MB Used Sectors Per Drive 2930277168 As I understand it, all the 64MB EARS model drive have the WD Advanced Format eg 4k sectors. I don't have one and I'm pulling this (from the depths of memory || out of my ass), but I think those drives also have something funky going on where they report normal 512 sector when in fact they do have 4k ones. Either way, it wouldn't hurt to align on 1MB boundaries. I just got confirmation back from WD, and your nether regions are correct -- this _is_ a 4096 byte sector drive. I have suggested to WD that they may wish to mention this salient fact somewhere. Thanks again, Andrew. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
8.0-RELEASE upgrade -- no files visible
I have a puzzler. After postponing an upgrade from 7.2 to 8.0 for some time, I now am attempting to make the transition. In the 7.2 install, I have one dangerously dedicated disk used only for backup (the accommodation of which is why I postponed the install in the first place), as well as a boot disk that was set up using slices. In addition, I have an external USB mass storage device that I have placed level 0 dumps of all filesystems upon. When I install 8.0 to a fresh disk (which is then set up using sysinstall), I can boot off the fresh disk and see all of the just-installed files perfectly. Here is the puzzler: if I boot 8.0, and mount any filesystem that was created by 7.2 or earlier, I cannot see any files. This includes both the non-DD internal disk (which is the boot disk for 7.2), as well as the external USB mass storage (formatted using UFS, but also not a DD setup). To add to the puzzle, df reports a usage number that reflects the block allocation, but ls does not report any filesystem entries. My primary objective is to make the dump files available under 8.0, so I tried booting 7.2 again, mounting my new (empty) /home partition and placing the files there -- this seemed to work as seen under 7.2, however when I rebooted using 8.0, there are again no files visible in this partition. Does anyone have any ideas on: (a) what the underlying problem could be (noting that although I have a DD disk, it is not involved in this process in any way) -- especially given that it seems to affect the filesystems on the external drive, or (b) what a path might be to getting the dump files to the new system so that I can use it? (I should mention that the dumps are rather huge (~100Gb), so a network based solution is rather unpalatable). Any input appreciated, Andrew. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: USB flash disc
Bernt Hansson wrote: I've got an usb flash disc kingston datatraveler DT150 64GB. That I put pcbsd on to try, and now I can't seem to get it of the stick. [ deletia ] Errors when trying fdisk: fdisk -BI /dev/da0 *** Working on device /dev/da0 *** fdisk: invalid fdisk partition table found fdisk: Geom not found: da0 fdisk: Failed to write sector zero umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR I'm assuming you have checked any readonly status that may be set on this device (in software or hardware), however the above exactly matches the reports I got from a USB desktop drive right before the device completely packed it in. If there are vendor diagnostics to debug data transfer to the device I would verify that it is actually transferring data as your next step. A. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Xdvi with amd64
On Mon, 4 May 2009, Olivier Nicole wrote: Exactly which fonts are you having trouble with? I can tell you whether I can reproduce the issue under 7.1. Nothing exotic at all: cmr10.300.pk The error message is: $ xdvi memo Note: overstrike characters may be incorrect. xdvi: Wrong number of bits stored: char. 68, font cmr10 $ For what it is worth, I don't seem to be able to produce this with any DVI files I create. If you have one in particular you would like me to verify, you can email it to me. What version of xdvi are you running? I have a recent port: $ xdvi -version xdvik version 22.84.10 (@(#)Motif Version 2.2.3, runtime version 2.2) Libraries: kpathsea version 3.5.2, T1lib version 5.1.2 A. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: going from cvs to svnq
[ snippage of question re: svn and cvs ] On Tue, 31 Mar 2009, Chuck Robey wrote: Andrew Wright wrote: The primary advantage of using svn is that the _server_ uses a different protocol to track objects. I think that's unclear, you can't mean that just having the protocol be different, that's not that much of a win. Having svn track extra things, like directories, that I'd think was a win. I chose the word protocol poorly. For protocol read way of doing things, or perhaps algorithm. What I was trying to make clear is that the choice of tool between cvs and svn is made based on server related criteria. What I don't know is, I use cvsup all the time, but when I switch to svn, what does the cvsup job of tracking an archive (not tracking the sources, I mean the archive)? Does svn do it all itself? If so, I can find out how, I just want to know if that's how its done. If not, what's the general tool used to track the freebsd archive, so I can investigate it? If you are asking what is the name of the subversion client, and how can I use it?, then the answer is svn (which is also the executable used for the server, a la cvs with the pserver option). Usage instructions are available via: http://subversion.tigris.org If you are asking what can I type to get a readonly copy of the repo?, then according to the ROADMAP.txt at: http://svn.freebsd.org/viewvc/base/ROADMAP.txt?view=markup the answer appears to be: svn co http://svn.freebsd.org/base/head Strong Caveats: o One of the peculiarities of subversion is that if you leave off the head portion of the URL, you will get _all_ of the nodes in the repository -- that is, the history at every point. o As I mentioned earlier, this will produce a newly checked out working space that is incompatible with cvsup (or cvs in general). o ***Early Adopter Warning***: There has not been (as far as I know) a general call for people to move to this type of repository access except for committers -- therefore expect rough edges until a general announcement is made. A. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: going from cvs to svnq
Sorry to follow-up my own note, but . . . On Wed, 1 Apr 2009, Andrew Wright wrote: [ further snippage of previous note ] Strong Caveats: o ***Early Adopter Warning***: There has not been (as far as I know) a general call for people to move to this type of repository access except for committers -- therefore expect rough edges until a general announcement is made. I would further urge you to read: http://svn.freebsd.org/viewvc/base/projects/GUIDELINES.txt?view=markup for an overview of the information used by the committers, and will further add: Even Stronger Caveat: o The head revision translates to something like current looking around in http://svn.freebsd.org/viewvc/base/ will show you that there are directories other than head from which branching is done. Some perusal of the svn manual and poking around in the repository may help you track current, but there isn't anything in place yet to let you track stable, for instance. A. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Formatting a tape?
On Thu, 19 Mar 2009, Jaime wrote: I have a DLT tape drive in a FreeBSD system. With one of the tapes, I can get tar -cvpf /dev/sa0 -C / . to work. With all the other tapes, I can't. Is there some kind of formatting process that I need to do? I tried mt fsf 1 from this page: I assume that this is a fresh tape? Do other tapes from the same batch work? What happens if you use dd to try and write to the tape? The command dd if=/dev/zero of=/dev/sa0 count=8 should print out: 8+0 records in 8+0 records out If you are getting something else, I might suspect a physical media problem. I have certainly gotten the odd dud tape before. A. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
dump(8) using snapshot + recommended cache
Hi All; I regularly use dump(8) with snapshots to back up my server. While this seems to have been working perfectly well so far, upon (re)reading the man page for dump(8), I have noticed a somewhat scary pair of lines in the paragraph describing the option for -C cachesize (emphasis with stars mine): [Use of this option] will greatly improve performance at the cost of ***dump possibly not noticing changes in the file system*** between passes. ***It is recommended that you always use this option when dumping a snapshot.*** Does anyone know what, exactly, this means? In particular, is the first statement actually trying to say: Use of this option will greatly improve performance; however it may be that changes made to the filesystem made between _dump_ passes will be ignored. ***The resulting dumped filesystem image will be consistent and correct based on a timestamp no later than that of the point at which the dump was started***. Is this a fair statement? Is this guaranteed? Or are we trying to say that: The resulting filesystem will contain images of individual files based on a timestamp no later than that of the point at which the dump was started, however any individual files modified after the dump begins may be stored using any of the version that appeared written to disk during the period of the dump. As far as the second line goes, I am not at all clear on what this is trying to say. Why is the cache recommended? For speed? Stability? Output correctness? In particular, if a snapshot dump is made without a cache option, is it potentially corrupt? In particular, if the second attempt above is more true than the first, it seems to me that we should _not_ recommend the use of a cache with snapshots, as it seems to erode the utility of the snapshot itself. It is for this reason that I am suspecting that there is more here than meets the eye, which is why I am keen to make sure that this is clear. I am very happy to put in an update to the docs if we can make sure that we know exactly what we are trying to say here. Thanks, Andrew. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: dump(8) using snapshot + recommended cache
I regularly use dump(8) with snapshots to back up my server. While this seems to have been working perfectly well so far, Sorry to follow-up my own post; I just realized I hadn't mentioned any version info. The docs I am reading are the ones associated with 7.1-RELEASE; I haven't checked whether this part of the dump documentation got updated with 7.1 or not. Thanks, Andrew. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: dump(8) using snapshot + recommended cache
On Sun, 1 Feb 2009, RW wrote: ***It is recommended that you always use this option when dumping a snapshot.*** When you dump a snapshot there are, by definition, no changes between passes. So it's saying that in that case there in no reason not to cache. Ah, that makes sense. That being the case, perhaps we can update the text to: If dumping from a snapshot, the filesystem is already frozen, therefore using a cache with a snapshot will ensure that consistency is maintained while also providing best performance. If that sounds good, I'll make a doc patch. Out of curiosity, under what circumstances is the improved performance the most likely? I dump from cron when the system usage is low, and haven't noticed any significant difference in time with or without cacheing -- but I haven't done any testing under heavy load, nor with limited RAM, so there are many mbufs available in any case. Thanks for the info, Andrew. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Running with a readonly root partition
As devfs is running by default, it seems to me that it would be relatively easy to run with a readonly root partition, assuming that the directories under which writing is necessary (ie; /tmp, /var, /home) are located in separate, writable partitions. The main advantages are that none of the configuration files or binaries in /etc and /usr (which may still be on a separate readonly partition) are vulnerable to attack (even from a local privilege escalation) without remounting the partition as writable. This used to be a very common setup in the *NIX world, so I am surprised to find little to no mention of it in the archives. I set up my machine this way a couple of months back, and have noticed some minor things (some few things assume a writable /etc, notably including dump(8), and the boot process update to /etc/motd). Once these have been rectified by relocating the files and setting up symlinks, there have been no problems. My questions are: - does anyone else do this? - if not, why not? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dmesg empty after shutdown -r
On Thursday 01 May 2008 01:58:46 A Hamilton-Wright wrote: After shutdown -r now and the subsequent reboot, I have (... no dmesg) On Thu, 1 May 2008, Mel wrote: dmesg -M doesn't show anything either? Wish I'd thought to try that last night. I eventually shut it down again (shutdown -p) until I could come in this morning and take a look at the console while booting -- and now everything is fine. I have now tried a few reboots (shutdown -r) and halts (shutdown -h), and I have a dmesg every time it recovers. I will certainly keep an eye on this and see if I can reproduce this in any fashion. If anyone else sees this phenomena (even transiently), I would love to know about it. Andrew. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
dmesg empty after shutdown -r
This is very strange. After shutdown -r now and the subsequent reboot, I have logged in to my machine FreeBSD qemg.org 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 10:35:36 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 Everything seems to be running normally, except dmesg produces no output, and /var/run/dmesg.boot is zero bytes long. Does anyone have any ideas why this would ever occur? Or even how it could occur? Andrew. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB HD based backup schemes
You haven't mentioned how large a USB drive you have available to use for this scheme, but it sounds to me like your situation can be summed up as follows: - you have two machines to back up, one is remote, but both have consistent network accessibility - you have a (removable) drive upon which you want to place regular backups, based on some use of dump/restore, and presumably this drive is large enough for all backup data, to be managed under some rotation scheme (old -vs- current directories, for example) - the main question is how to collect and organize the data onto this (removable) drive on a machine remote from the one being backed up If the above pretty much fits the bill, I would suggest a simple script to be run out of cron to copy the data. Keep in mind that you can easily transfer the data directly from dump to your remote machine by piping it into an ssh command. On your dobby machine, a command of the form: dump 1nuLf - /my/data | ssh -x kreacher /path/to/some/handler/script will present the dump output to a script run on the backup machine that can presumably ensure sane handling of the incoming data and potentially mount your USB device. Passing the mount point on dobby as an argument to your remote script will help you organize things if you have set up multiple filesystems on dobby that you need to dump separately. Note that I am assuming here that you have made a zero level dump and that it will be perpetually available in some safe place. I'm sure that I could roll my own with dump or such, but I'm sure that I would leave important things out and that this has already been done by people who are smarter and more experienced than I am. So recommendations please. As long as you are dumping whole filesystems, I don't really see how you can leave anything out -- recovery is then simply a case of: - boot off an install/live CD - fdisk, label, newfs - restore dump level 0, restore most recent dump level 1 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB HD based backup schemes
On Sat, 26 Apr 2008, Jeffrey Goldberg wrote: On Apr 26, 2008, at 3:38 PM, David N wrote: We used to use RSnapshot http://www.rsnapshot.org/ to backup to an external disk, its a great tool that also does incremental via hard links which is a plus. Just after I posted, I started thinking about rsync. I hadn't known about rsync's hard link feature. So once I saw that, the trail did lead me to rsnapshot. The only thing I don't like about it is the security hole it demands of remote machines to be able to back up to them. Take a look at rsync's -e feature. You can use it to pipe its output through an ssh tunnel much as I just posted a moment ago: rsync -e ssh -x ... kreacher:path/to/usb/storage Andrew. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
CPU throttling on amd64
Does anyone on this list know the state of any userland control tools for CPU throttling on the amd64 platform? I see in the archives that there was little functionality in this are as of 2004, and then substantial work in 2005 to make cpufreq available through sysctl. At that time there is a thread indicating how nice it would be if someone wrote a daemon to do the control for this a la cpufreqd http://lists.freebsd.org/mailman/htdig/freebsd-amd64/2005-February/003524.html I cannot seem to find anything relating to throttling and or AMD CoolQuiet after that point. Is there such a daemon? Thanks for any pointers, Andrew. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenBSD - FreeBSD migration
The results of my investigation so far are below: Filesystem stuff: - it appears that FreeBSD and OpenBSD use the same partition table format. Is this true? If so, I can potentially avoid rebuilding an entire disk if I am right that ... - FreeBSD can mount and read OpenBSD's version of the 4.2 BSD filesystem implementation Although I strongly suspect that the filesystem itself is probably the same, it is not possible to read an OpenBSD mounted partition, as far as I can tell. After booting using FreeBSD, fdisk correctly reports the information regarding the slice set up by OpenBSD (default 4, not 1, the FreeBSD default), however bsdlabel under FreeBSD cannot interpret any of the data found at the location reported in the table read by fdisk. I do find this somewhat surprising, as it is the same structures that are being recorded. Perhaps there is a magic number issue here that causes bsdlabel to believe that it can't interpret the data as the message returned is that there is no label present in the indicated slice. This makes the filesystem question moot, as without access to the BSD partition results there is no clue as to where to begin access of the filesystem. - even if the above isn't true, it appears that the format used by dump/restore is consistent. I have tried dumping/restoring some small filesystems to test this, but if this is an unsupported way to go, I would like to know now. This seems to work. I was successfully able to dump filesystems under OpenBSD and then restore them under FreeBSD, with general success (albeit a complaint that the dump header is out of date). Cheers, Andrew. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]