|
OpenBSD General Other questions regarding OpenBSD which do not fit in any of the categories below. |
|
Thread Tools | Display Modes |
|
|||
preventing /tmp from getting cleaned on reboot
Hi Everyone !
I've dedicated 19g for /tmp which is a loss if I can't keep data (ie. iso images) there in. Is there a way to change the system's boot behavior so that data in /tmp is not cleaned on reboot ? Thank you :-) |
|
|||
Quote:
As pointed out by the hier(7) manpage, by definition /tmp is designed for temporary file usage. Why are you wanting to store files there? Is it because you created such a large partition for /tmp? Or have you fallen into a usage pattern which you want to perpetuate by redesigning Unix to fit the practice? |
|
|||
It seems like a really bad idea to change /tmp into permanent storage for random crap. An easy fix would be to just nuke that partition, make a smaller /tmp and then a new partition for storage.
|
|
|||
jgimmi,ocicat,denta, thank you very much !!!
Quote:
next_part "Removing scratch and junk files:" ........ ........ |
|
|||
daemonfowl, I suspect you are seeing in the responses received thus far that a series of poor decisions are being made, and continuing down this path is going to lead to even larger problems.
You need to take a step back, & consider better alternatives. You also need to identify the core problem. I have no idea how big this hard drive is, but allocating 19GB to a partition for /tmp seems inordinately large. Maybe this comes from the automatic partitioning the installer chose, or maybe this comes from choices you manually made. Section 4.6.4 of the FAQ will give some ideas to how much space should be allocated, however, there can be a huge debate over what size any particular partition needs to be. The true answer comes with identifying usage patterns & adjust sizes in the next fresh install to fit the use of the system, but a recommendation jggimi frequently makes is to just make one large partition for the entire system until you have a better idea as to how much space needs to be allocated for multiple partitions. /tmp should not be used for storage. Yes, the eradication of /tmp at each boot-up can be changed, but the use case this addresses is situations where either erasing consumes too much time, or erasing adversely affects the lifetime of the media. I can only guess that you don't have space elsewhere for whatever you are storing, & so you have starting using /tmp as a poor, but expedient substitute. The simple fact is that you need to back up your files & do a fresh install, changing the partition sizes to either one huge partition, or adjust the sizes to better values until you have a better perspective as to that the new adjustment needs to be. Don't think you are going to get this right in one pass. You won't. Nobody does. But you should be developing practices where you can back up & start again with lessening pain. As an anecdote, I have spent weekends where I have done nothing but reinstall again & again, but usually this has been to tweak install.site scripts which addresses both partition sizes & disaster plans. As a final comment & suggestion, if you don't like the idea of simply creating one huge partition, another alternative is to not allocate all space -- especially is the drive is large in size. As denta is suggesting, leaving free space available gives you the ability to add partitions later. If all the space on a drive is allocated, there is no room for growth. |
|
|||
Quote:
|
|
|||
Quote:
|
|
|||
Quote:
From my experience, the size of /usr/ports/pobj is far more important when it comes to building packages. Quote:
|
|
||||
I'll stand by my earlier statement. You are asking the
wrong question. Ask, instead, what knowledge and skill sets you will need in order to reconfigure your partitions without reinstalling. I recommend attempting it, because you may learn something. |
|
||||
An imaginary converstaion between daemonfowl and jggimi
Friend daemonfowl, you often ask wonderful, insightful questions, but then you drop the discussion and do not seem interested in pursuing the details.
Since you haven't asked, I don't expect you to. So, rather than going through the cycle again on yet another general question, I imagined what it might be like if you had actually asked, this time. ................................................. Quote:
A: Of course. There are special considerations for the root partition, "/", and the /usr partition. For other partitions, it's easy enough to back up, reconfigure, and restore. Q: What procedure do you recommend for backup/restore and reconfiguration? A: I prefer dump(8) and restore(8) to other backup/restore tools with FFS partitions, because there are no restrictions on file types or file name lengths as can happen with tar(1), cpio(1), and tools like pax(1) which use them. There are backup and restore tools in the ports tree, but they require a re-installed, fully functional system to restore to, and I prefer the simplicity of being able to use a tool in the RAMDISK kernel for bare-metal restores. The restore(8) program is included in the RAMDISK kernel though I do need to mount a small /tmp in order to use it. As for reconfiguration, I just use disklabel(8). On a few rare occasions I've been able to take advantage of growfs(8) to increase the size of an FFS partition. Q: I've never used dump, it looks pretty complicated from the man page. A: It can be a little complex, because it is so versatile. There are examples of the dump and restore commands when used with tape in FAQ 14.10. I've only used these tools when dumping directly to disk or being piped to other tools -- gzip(1) for compression, ssh(1) or nc(1) for network dumps, or some combination. I often use dump/restore piped together when replicating directories or filesystems. For example, "cd /new/location; dump -0af - /old/location | restore -rf -" will replicate the files hierarchy /old/location to /new/location. The "-" file is standard output for dump, and standard input for restore. Q: Tell me about the partitions with special considerations? A: The /usr partition contains applications and libraries -- /usr/bin and /usr/lib. Your /usr/local hierarchy might be in its own filesystem, but it too has the same considerations. You don't want to be dependent on anything in those directories while you are moving them, which might include times when they are not available. You are limited, therefore, to using tools within the root filesystem: /bin, /sbin. You need to boot into single user mode, so that no applications dependent on /usr (or /usr/local) are running. How you get there varies by architecture (e.g.: "-s" at the boot> prompt for i386 and amd64). You can also signal init(8) to enter single user mode. Manipulating the root filesystem is more complicated still. Q: What would I need to do for the root filesystem? A: You would need to use the shell from the RAMDISK kernel, as the root directory must be unmounted to be manipulated. The tools there are fewer -- growfs isn't included in the RAMDISK image. But newfs(8) and restore(8) are, though as I mentioned above, you'll need to mount a partition to be used as /tmp to use restore(8). In addition, you will need to reinstall boot blocks, and that too will vary depending upon the architecture. The i386, amd64, and sparc architectures (at least) have an installboot(8) program. Q: Any recommendations before I begin? A: Yes. Back up your system before beginning. Really. Even if you have sufficient disk space on your currently attached drive(s) to move things around, it's easy to make a mistake. If you don't have a backup, you won't have anything to restore. ................................................. Thank you for tuning in for this week's episode of ... The Twilight Zone. Last edited by jggimi; 4th May 2012 at 05:46 PM. Reason: 1 typo, some clarity |
|
|||
@jgimmi ,thank you very much !! I was about to ask the *right question* but found your anticipated *Tasogare* Post .. :-)
Quote:
Quote:
Quote:
|
|
||||
Our continued imaginary conversation
Quote:
Q: I've been practicing backups and I'm confused by the "dump levels". I know level 0 is a full backup but I do not understand the various other levels. |
|
|||
Quoting shakespeare :
@ jgimmi .. a worthy gentlemen ... as bountiful as mines of India so is @ocicat .. thank you gentlemen !! Accept this please , hoping you like New Age Piano , thanksgiving by George Winston : http://www.youtube.com/watch?v=LA05a...eature=related Interesting hint : Quote:
|
|
||||
Quote:
Code:
# sh /etc/daily Code:
$ man cron Code:
$ man 1 crontab $ man 5 crontab Code:
# crontab -l | less Code:
# crontab -e |
|
|||
I appreciate your help, @jgimmi !! thanks and sorry if my neurones are as fast as this:
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
preventing connections from being cut? | daemonfowl | OpenBSD Security | 6 | 24th January 2012 11:43 PM |
reboot FreeBSD box with crontab | mfaridi | FreeBSD General | 1 | 15th October 2011 02:37 AM |
hello, how BSD reboot but keep memory | misssir | FreeBSD General | 8 | 11th October 2011 02:43 PM |
reboot freebsd periodically | semarmendemx | FreeBSD General | 3 | 27th October 2010 04:23 AM |
Apply TTYS changes with out reboot | jjjustjjjay | OpenBSD General | 1 | 6th May 2010 09:24 PM |