using sysinstall upgrade as a repair solution
Hello all! I was running 5.1 release till pretty much last week when I believe the machine experienced an unplanned powercycle. since then i get an error about libedit.so.4 being missing, and being required by sh, please input path to sh or hit enter. ok, so i know about /rescue/sh, and the fixit option on sysinstall, but i don't know if libraries are anywhere to be found on the live cd fixit toolkit (i doubt it, i looked in all the places that made sense to me). So i figure I might as well reinstall the OS, as that is why i made separate partitions for user data and system files (so i think, this is my first unix based system built by me) to apparently facilitate os reinstallation. So here is my understanding of how a reinsall is supposed to go, with the aim of preserving my user stuff. I set the system up with a 150 meg partition (more than reccomended in the handbook at the time, and still to my knowledge) on which I put a, a b swap part, 256 meg d /tmp, 256 meg e /var, and 200odd gig f /usr. the system was oringinally intended to be an anonymous ftp repository for me and my friends, but due to school req's i had to change it to the sftp backengine(?) of sshd, and it was in /usr/share/public that i put pretty much everything. when my friends added tons of crap I eventually added another 160 gig drive, put a swap part on that too for kicks, and moved the /home dir to it too. as of last week i only have 10 gigs remaining on that drive, and oddly enough i am at 106% capcity for the 250 gig drive according to df, go figure. So now I figure id open up sysinstall off a cd and use the upgrade feature first, for either 5.1 or 6.2. I set / to mount to a, /tmp to d, /var to e. and i leave f alone, since i dont want that modified at all. well, eventually the tool tells me that the filesystem is full and quits. Then I try doing a custom install and choose only the required base files, or a minimal install, and the same thing happens. Then I figured that in the worst case i could choose to mount /usr on the 2nd harddrive on the partition where there are 10 gigs free in the fdisk-like utility step that the upgrade feature brings one too, and then i get kernel panics. So i figure im not doing something right, or im not understanding something, but it was my intent to separate the / from /usr(or wherever id put stuff) in order to make the upgrading(or repairing) of the os easier. If this topic has already been discussed on the list then please tell me so I can go look in this lists archives wherever they may be stored. I am also not adverse to reading and note that I've looked through the handbooks for 5.1 and 6.2 as well as their install.txts. 5.5 disks are burning now, and im going to give those a try and see what happens. Thanks! Josh ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: using sysinstall upgrade as a repair solution
Disclaimer: IANAE. Joshua Kordani wrote: Hello all! I was running 5.1 release till pretty much last week when I believe the machine experienced an unplanned powercycle. since then i get an error about libedit.so.4 being missing, and being required by sh, please input path to sh or hit enter. ok, so i know about /rescue/sh, and the fixit option on sysinstall, but i don't know if libraries are anywhere to be found on the live cd fixit toolkit (i doubt it, i looked in all the places that made sense to me). It should live in /lib. Did you look there? It might get by (barely) with libedit.so.3 or libedit.so5, also, if they are there. Of course, the executables in /rescue are statically linked, so you So i figure I might as well reinstall the OS, as that is why i made separate partitions for user data and system files (so i think, this is my first unix based system built by me) to apparently facilitate os reinstallation. It's traditional in BSD unix to have separate partitions; the logic is lost to me (being shrouded in the mists of time), but it's proved sane here a few times. For example, when one partition gets full, there's still some room to move stuff and salvage things without a reinstall ;-) So here is my understanding of how a reinsall is supposed to go, with the aim of preserving my user stuff. I set the system up with a 150 meg partition (more than reccomended in the handbook at the time, and still to my knowledge) on which I put a, a b swap part, 256 meg d /tmp, 256 meg e /var, and 200odd gig f /usr. the system was oringinally intended to be an anonymous ftp repository for me and my friends, but due to school req's i had to change it to the sftp backengine(?) of sshd, and it was in /usr/share/public that i put pretty much everything. when my friends added tons of crap I eventually added another 160 gig drive, put a swap part on that too for kicks, and moved the /home dir to it too. as of last week i only have 10 gigs remaining on that drive, and oddly enough i am at 106% capcity for the 250 gig drive according to df, go figure. Not hard to figure. The disk is full, including the space reserved for accidental overflow. Take some stuff off --- log files, disk hogging sound or video files, etc. Incidentally, 150MB doesn't seem very large for a root partition IMHO. I've not read the handbook recently, but I generally use a gig for /. Had a situation similar to what you describe recently with a system that had been running Desktop BSD. The default setup there is apparently 128M or so for / with a separate /tmp of approximately equal size. Figuring that /rescue would save me in the event of problems, I moved /stand to another partition (one that had *space* though, mind you) and linked it to /. Then my upgrade succeeded, although I was using the standard cvsup/make buildworld cycle. So now I figure id open up sysinstall off a cd and use the upgrade feature first, for either 5.1 or 6.2. I set / to mount to a, /tmp to d, /var to e. and i leave f alone, since i dont want that modified at all. well, eventually the tool tells me that the filesystem is full and quits. Then I try doing a custom install and choose only the required base files, or a minimal install, and the same thing happens. Then I figured that in the worst case i could choose to mount /usr on the 2nd harddrive on the partition where there are 10 gigs free in the fdisk-like utility step that the upgrade feature brings one too, and then i get kernel panics. Any indication as to why? I'd assume that it wasn't finding things as it expected, filesystem wise. Of course, a lot has changed since 5.1, so it could be anything. Most recent panic I've seen that bears any resemblance was on a 5.3 system with a devfs statement in /etc/rc.conf that was no longer valid, so when it was upgraded to 6.2 (quite a bit more recent), devfs panicked on boot. Removing the config statement from said file fixed that. YMMV, of course. So i figure im not doing something right, or im not understanding something, but it was my intent to separate the / from /usr(or wherever id put stuff) in order to make the upgrading(or repairing) of the os easier. If this topic has already been discussed on the list then please tell me so I can go look in this lists archives wherever they may be stored. I am also not adverse to reading and note that I've looked through the handbooks for 5.1 and 6.2 as well as their install.txts. 5.5 disks are burning now, and im going to give those a try and see what happens. Thanks! Josh You need space on the disk. Read up on find and du and see what's taking the space. Then use rm and get rid of it. After that you should be able to do an upgrade. Although if you do like to read docs, I'd recommend the standard procedure instead of the sysinstall binary upgrade; however, that could be just a user pref, I guess. KDK -- Envy, n: Wishing you'd been born
Re: using sysinstall upgrade as a repair solution
On Tue, Mar 06, 2007 at 11:58:24AM -0600, Kevin Kinsey wrote: Disclaimer: IANAE. Joshua Kordani wrote: Hello all! ..libedit.so stuff deleted.. So i figure I might as well reinstall the OS, as that is why i made separate partitions for user data and system files (so i think, this is my first unix based system built by me) to apparently facilitate os reinstallation. It's traditional in BSD unix to have separate partitions; the logic is lost to me (being shrouded in the mists of time), but it's proved sane here a few times. For example, when one partition gets full, there's still some room to move stuff and salvage things without a reinstall ;-) The long ago origins of making things in many partitions was when disks were much much smaller. So were backup media. It was common to have each piece on a separate disk. Then disks got big enough to put more than one part on and so on. Now, there are a couple of good reasons to still divide a disk in to partitions. One is mentioned, sort of, above. You want to isolate areas that may grow unexpectedly from critical disk space. So, /var which contains logs and database stuff and spools gets its own partition to keep it from over-filling root. /tmp and user home directory space are also such disk areas whose growth might not be predictable. Another reason is for convenience with backups. You may want to reduce the size of partitions that are being backed up, either to fit media or to be more convenient. If only stuff in the partition with users' home directories changes, then you only have to make regular backups of that. The other parts you only backup when you make a new install or whatever. Some things like /tmp you don't bother to ever back up.It also can be less to have to restore if one partition goes belly up, though that is less true nowdays when the users' space (not necessarily /usr - that is an old convention. Now it is common to use /home for users' home directories, since /usr really contains installed software) may be by far the largest space on a system, depending on how the system is used. Another reason to break things up is to have to load the least amount possible when there are problems. You have to have / to boot in to single user mode to work on things. But you don't have to have the rest of the stuff. The smaller you make root the less likely some disk problem will show up in the root partition, making it more likely you can get at least some of the system up to work on the problem. The fourth reason to have separate partitions is to make it easier to isolate things. You may want to make a certain amount of space available for users to write in, but want to keep them out of other space. There are various ways to do it. Having things grouped conveniently in some defined area makes it a little easier. So here is my understanding of how a reinsall is supposed to go, with the aim of preserving my user stuff. I set the system up with a 150 meg partition (more than reccomended in the handbook at the time, and still to my knowledge) on which I put a, a b swap part, 256 meg d /tmp, 256 meg e /var, and 200odd gig f /usr. the system was oringinally intended to be an anonymous ftp repository for me and my friends, but due to school req's i had to change it to the sftp backengine(?) of sshd, and it was in /usr/share/public that i put pretty much everything. when my friends added tons of crap I eventually added another 160 gig drive, put a swap part on that too for kicks, and moved the /home dir to it too. as of last week i only have 10 gigs remaining on that drive, and oddly enough i am at 106% capcity for the 250 gig drive according to df, go figure. Not hard to figure. The disk is full, including the space reserved for accidental overflow. Take some stuff off --- log files, disk hogging sound or video files, etc. Incidentally, 150MB doesn't seem very large for a root partition IMHO. I've not read the handbook recently, but I generally use a gig for /. If you divide out /var and /usr and /tmp and /home, then 150 MB is plenty for root. I am currently using about 120 MB on this machine which is due a good cleanup. Use du(1) to track down where disk is being used unexpectedly. CD to a directory and do du -sk * and look at the list. Go in to whichever directory that shows up in the list as surprisingly large and do another du, etc, etc until you isolate where the junk is. rm the stuff and find out how it is getting there and close that hole off. You can use other flags such as -h or -m on the du command. I like the -k because it makes a consistent display down the list that makes it easy to visually scan and see differences in those cases where I don't care so much about the actual size as about seeing those that stick out. Note, by the way, that upgrading can use up a chunk of space on a temporary basis. jerry ..other stuff
Re: using sysinstall upgrade as a repair solution
Jerry McAllister wrote: The long ago origins of making things in many partitions was when disks were much much smaller. So were backup media. It was common to have each piece on a separate disk. Then disks got big enough to put more than one part on and so on. Now, there are a couple of good reasons to still divide a disk in to partitions. One is mentioned, sort of, above. You want to isolate areas that may grow unexpectedly from critical disk space. So, /var which contains logs and database stuff and spools gets its own partition to keep it from over-filling root. /tmp and user home directory space are also such disk areas whose growth might not be predictable. Another reason is for convenience with backups. You may want to reduce the size of partitions that are being backed up, either to fit media or to be more convenient. If only stuff in the partition with users' home directories changes, then you only have to make regular backups of that. The other parts you only backup when you make a new install or whatever. Some things like /tmp you don't bother to ever back up.It also can be less to have to restore if one partition goes belly up, though that is less true nowdays when the users' space (not necessarily /usr - that is an old convention. Now it is common to use /home for users' home directories, since /usr really contains installed software) may be by far the largest space on a system, depending on how the system is used. Another reason to break things up is to have to load the least amount possible when there are problems. You have to have / to boot in to single user mode to work on things. But you don't have to have the rest of the stuff. The smaller you make root the less likely some disk problem will show up in the root partition, making it more likely you can get at least some of the system up to work on the problem. The fourth reason to have separate partitions is to make it easier to isolate things. You may want to make a certain amount of space available for users to write in, but want to keep them out of other space. There are various ways to do it. Having things grouped conveniently in some defined area makes it a little easier. What Jerry said ;-). Thanks for expressing what I couldn't OTTOMH. Incidentally, 150MB doesn't seem very large for a root partition IMHO. I've not read the handbook recently, but I generally use a gig for /. If you divide out /var and /usr and /tmp and /home, then 150 MB is plenty for root. I am currently using about 120 MB on this machine which is due a good cleanup. I only partition /, /var/, and /usr/, so /tmp stays in the root slice; I make mention of this fact (150M being small) because of the previously-mentioned case in which installworld puked because / was full (this *was* with a separate /tmp) and there was nothing really there except default stuff (had been a DesktopBSD system, maybe someone with more experience there could comment). The box was going from 5.3 under an (older) DesktopBSD test install to FBSD 6.2; I worked 'round the issue by moving /stand, but ended up re-installing 6.2 from CD to give a slightly more junior guy more experience with sysinstall (AAMOF I've made him do it on two boxen today, heh heh heh) Kevin Kinsey -- Life is what happens to you while you're busy making other plans. -- John Lennon, Beautiful Boy ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: using sysinstall upgrade as a repair solution
The fourth reason to have separate partitions is to make it easier to isolate things. You may want to make a certain amount of space available for users to write in, but want to keep them out of other space. There are various ways to do it. Having things grouped conveniently in some defined area makes it a little easier. What Jerry said ;-). Thanks for expressing what I couldn't OTTOMH. Incidentally, 150MB doesn't seem very large for a root partition IMHO. I've not read the handbook recently, but I generally use a gig for /. If you divide out /var and /usr and /tmp and /home, then 150 MB is plenty for root. I am currently using about 120 MB on this machine which is due a good cleanup. I only partition /, /var/, and /usr/, so /tmp stays in the root slice; I make mention of this fact (150M being small) because of the previously-mentioned case in which installworld puked because / was full (this *was* with a separate /tmp) and there was nothing really there except default stuff (had been a DesktopBSD system, maybe someone with more experience there could comment). The box was going from 5.3 under an (older) DesktopBSD test install to FBSD 6.2; I worked 'round the issue by moving /stand, but ended up re-installing 6.2 from CD to give a slightly more junior guy more experience with sysinstall (AAMOF I've made him do it on two boxen today, heh heh heh) Hmmm. /tmp is definitely one thing I would take out of / and put in its own partition - or at least in some other big scratch space. It can easily get filled with stuff which then goes away. But if it overfills /, it can bring the system to its knees. If it overfills its own system, it can make things slow to a standstill, but usually you can still get in with root and nuke enough to continue and at least shut things down gracefully. jerry Kevin Kinsey -- Life is what happens to you while you're busy making other plans. -- John Lennon, Beautiful Boy ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
