Re: 6.5 auto_install fails due to custom /var/tmp?
On Tue, 30 Apr 2019 13:29:47 -0700 Lyndon Nerenberg wrote: > > But I should be able to accomplish what I need using rc.firsttime > > and a tiny bit of hackery. > > Sadly, no :-( How about partition as /var/temp/ & autoinstall Lyndon? Then in rc.firsttime:- *) umount /var/temp/ *) check /var/tmp is a symlink && *) rm it *) mv /var/temp /var/tmp *) chmod/own /var/tmp as req'd *) mount /var/tmp Cheers, -- Craig Skinner | http://linkd.in/yGqkv7
Re: 6.5 auto_install fails due to custom /var/tmp?
On 2019-04-30, Lyndon Nerenberg wrote: >> Sadly, no :-( >> >> But I should be able to accomplish what I need using rc.firsttime and >> a tiny bit of hackery. > > Sadly, no :-( > > What I was aiming for was to have the newly installed machines come > up with a 2GB MFS /tmp and a ~20GB /var/tmp. But MFS /tmp really > needs help in the system boot scripts. > > The critical part for us is that /var/tmp not overwhelm /var, and > we can get that with the current scheme by sizing /tmp accordingly. > > --lyndon > > My "workaround" when I've run into this during upgrades has been to ditch the MFS /tmp and mount my previous /var/tmp partition there instead. If MFS was actually fast then doing this would make me sad, but it isn't really, and sd0 is often on SSD these days...
Re: 6.5 auto_install fails due to custom /var/tmp?
Paul de Weerd wrote: > On Tue, Apr 30, 2019 at 01:29:47PM -0700, Lyndon Nerenberg wrote: > | > Sadly, no :-( > | > > | > But I should be able to accomplish what I need using rc.firsttime and > | > a tiny bit of hackery. > | > | Sadly, no :-( > | > | What I was aiming for was to have the newly installed machines come > | up with a 2GB MFS /tmp and a ~20GB /var/tmp. But MFS /tmp really > | needs help in the system boot scripts. > > Why? I've been running with MFS /tmp for *years* on several machines. > > This indeed required some changes when /var/tmp was changed into a > symlink to /tmp, but that was really no issue at all. > > There's very little difference between a /tmp on disk and a /tmp in > RAM (through mfs): both get mounted during boot at the same time. > > [weerd@pom] $ grep /tmp /etc/fstab > swap /tmp mfs rw,nodev,noatime,async,nosuid,-s=8388608 > [weerd@pom] $ df -h /tmp > Filesystem SizeUsed Avail Capacity Mounted on > mfs:12547 3.9G227M3.5G 6%/tmp > > | The critical part for us is that /var/tmp not overwhelm /var, and > | we can get that with the current scheme by sizing /tmp accordingly. > > Having /var/tmp not overwhelm /var is accomplished by having /var/tmp > symlink to /tmp (assuming /var and /tmp are on separate filesystems). > If you need more room in /var/tmp then you want to assign to your MFS > /tmp, then you need a different solution - but that's probably > something that can also be solved in a different way (don't use > /var/tmp for temporary storage, but another (dedicated) location for > whatever needs to write so much there). What hasn't been mentioned is why /var/tmp was made into a symbolic link to /tmp. Is your /var/tmp a seperate filesystem? Can I have a temporary account to demonstrate the consequences of filling /var?
Re: 6.5 auto_install fails due to custom /var/tmp?
On Tue, Apr 30, 2019 at 01:29:47PM -0700, Lyndon Nerenberg wrote: | > Sadly, no :-( | > | > But I should be able to accomplish what I need using rc.firsttime and | > a tiny bit of hackery. | | Sadly, no :-( | | What I was aiming for was to have the newly installed machines come | up with a 2GB MFS /tmp and a ~20GB /var/tmp. But MFS /tmp really | needs help in the system boot scripts. Why? I've been running with MFS /tmp for *years* on several machines. This indeed required some changes when /var/tmp was changed into a symlink to /tmp, but that was really no issue at all. There's very little difference between a /tmp on disk and a /tmp in RAM (through mfs): both get mounted during boot at the same time. [weerd@pom] $ grep /tmp /etc/fstab swap /tmp mfs rw,nodev,noatime,async,nosuid,-s=8388608 [weerd@pom] $ df -h /tmp Filesystem SizeUsed Avail Capacity Mounted on mfs:12547 3.9G227M3.5G 6%/tmp | The critical part for us is that /var/tmp not overwhelm /var, and | we can get that with the current scheme by sizing /tmp accordingly. Having /var/tmp not overwhelm /var is accomplished by having /var/tmp symlink to /tmp (assuming /var and /tmp are on separate filesystems). If you need more room in /var/tmp then you want to assign to your MFS /tmp, then you need a different solution - but that's probably something that can also be solved in a different way (don't use /var/tmp for temporary storage, but another (dedicated) location for whatever needs to write so much there). Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: 6.5 auto_install fails due to custom /var/tmp?
> Sadly, no :-( > > But I should be able to accomplish what I need using rc.firsttime and > a tiny bit of hackery. Sadly, no :-( What I was aiming for was to have the newly installed machines come up with a 2GB MFS /tmp and a ~20GB /var/tmp. But MFS /tmp really needs help in the system boot scripts. The critical part for us is that /var/tmp not overwhelm /var, and we can get that with the current scheme by sizing /tmp accordingly. --lyndon
Re: 6.5 auto_install fails due to custom /var/tmp?
Nick Holland writes: > normally, /var/tmp is a symlink to /tmp. > It can't make the link. No surprise. > Answer "Yes" to the "Continue anyway?" prompt, and all will be fine, I > believe. Sadly, no :-( But I should be able to accomplish what I need using rc.firsttime and a tiny bit of hackery. --lyndon
Re: 6.5 auto_install fails due to custom /var/tmp?
On Mon, 29 Apr 2019 21:18:04 -0400 Nick Holland wrote: > normally, /var/tmp is a symlink to /tmp. > It can't make the link. No surprise. Since 5.7: http://openbsd-archive.7691.n7.nabble.com/5-7-installer-tar-Unable-to-remove-directory-td277040.html Cheers, -- Craig Skinner | http://linkd.in/yGqkv7
Re: 6.5 auto_install fails due to custom /var/tmp?
On 4/29/19 6:09 PM, Lyndon Nerenberg wrote: > While trying to PXE install a 6.5 machine I was hit with this failure: > > Installing bsd 100% |**| 15163 KB00:00 > > Installing bsd.mp 100% |**| 15248 KB00:00 > > Installing bsd.rd 100% |**| 9984 KB00:00 > > Installing base65.tgz99% |* | 189 MB00:00 > ETAtar: Unable to remove directory ./var/tmp: Device busy > Installing base65.tgz 100% |**| 190 MB00:14 > > Installation of base65.tgz failed. Continue anyway? [no] no > > which I suspect is related to this: > > / 1G > swap4G-16G 10% > /tmp2G > /usr4G > /usr/local 2-6G 10% > /var10-20G 20% > /var/tmp10-20G 15% > /var/log20-40G 30% > /u 1G-* yeah. > I've never run into this until today, when I tried to carve out an explicit > /var/tmp. Autopartitioning be able to handle /var/tmp, no? normally, /var/tmp is a symlink to /tmp. It can't make the link. No surprise. Answer "Yes" to the "Continue anyway?" prompt, and all will be fine, I believe. Nick.
6.5 auto_install fails due to custom /var/tmp?
While trying to PXE install a 6.5 machine I was hit with this failure: Installing bsd 100% |**| 15163 KB00:00 Installing bsd.mp 100% |**| 15248 KB00:00 Installing bsd.rd 100% |**| 9984 KB00:00 Installing base65.tgz99% |* | 189 MB00:00 ETAtar: Unable to remove directory ./var/tmp: Device busy Installing base65.tgz 100% |**| 190 MB00:14 Installation of base65.tgz failed. Continue anyway? [no] no which I suspect is related to this: / 1G swap4G-16G 10% /tmp2G /usr4G /usr/local 2-6G 10% /var10-20G 20% /var/tmp10-20G 15% /var/log20-40G 30% /u 1G-* I've never run into this until today, when I tried to carve out an explicit /var/tmp. Autopartitioning be able to handle /var/tmp, no? --lyndon
