Date: Thu, 12 Jul 2001 12:19:24 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: obrien@FreeBSD.ORG Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD Mall now BSDCentral Message-ID: <3B4DF83C.939061AD@mindspring.com> References: <20010707002340.B16071@widomaker.com> <20010707004731V.jkh@osd.bsdi.com> <3B49F8D5.2C9BFA73@mindspring.com> <3B4A0124.26025FB5@iowna.com> <3B4A1423.E8E365E@mindspring.com> <20010709144801.A38630@dragon.nuxi.com> <3B4B26FE.6660FE5C@mindspring.com> <20010710091352.F48544@dragon.nuxi.com> <3B4B3A58.A6CFC592@mindspring.com> <3B4DDF30.9CEAAAFB@mindspring.com> <20010712105801.B13401@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David O'Brien wrote: > > 1) Soft Updates enabled on a root partition. > > > > This comes back to the old "you can't turn SU > > on or off, except via tunefs". So even if you > > boot via CDROM, it's too late, if the CDROM > > kernel supports SU, since it's already on, and > > you can't substitute an async mount. > > Why not? The install kernel does not have SOFTUPDATES enabled. > Can one not mount a parition aync if the softupdates flag was set via > tunefs in the past [and the running kernel does not support them]? No. The tunefs flag takes precedence. Look at the FFS code. I've submitted patches once in the past, which basically converted the "update" of mounts into an unmount+remount, but that was shot down as a "bad idea". The problem is that you have to wait for the clock to drain, since the device you use might be something like a vn, also on a soft updates partition. It gets messy. The initial mount, even if taken care of, will not get me where I need to be, as upgrades are more frequent than initial installs. I expect that the rest of the FreeBSD community has this experience as well (this bodes ill for the growth of FreeBSD adoption, but that is a -advocacy topic). > > 2) Most of my upgrades are over a network, not > > booting off of CDROM. > > How are you running sysinstall? I do not know what you > mean by "over the network". To me that means you have > made the two boot floppy set and used that -- the "network" > part is where you are getting your distribution sets from. > In this case, you *are* running sysinstal as init. Perhaps > I do not fully understand how you are doing this. I have no floppy. I have no CDROM. I have no video card or keyboard, so I can't invoke the Intel FXP BIOS etherboot code. I have only a serial console, a network connection, and a hard disk. -------------------------------------------------------- Terry's magic embedded system upgrade procedure, Mark I To be run at the console, logged in as root ... -------------------------------------------------------- echo "This crap should be accessible on the CD, but isn't" ftp machine.installed.from.cdrom cd /stand lcd /tmp get sysinstall cd /dev get MAKEDEV get MAKEDEV.local quit mount nfs.server.with.cdrom:/cdrom /mnt cd /tmp echo "Must use a fricking matching sysinstall..." chmod 755 sysinstall ./sysinstall upgrade local disk = /mnt force the S.O.B. to install /src... exit echo "non-boot sysinstall 'can't be bothered' with this..." cp MAKEDEV /dev cp MAKEDEV.local /dev cp sysinstall /stand/sysinstall cd /dev sh MAKEDEV all echo "What were they thinking when they changes this?!?" cd /etc cat >> pam.conf # this is crap for ssh because ssh won't work otherwise sshd ... sshd ... sshd ... ^D sync sync sync reboot -------------------------------------------------------- Make sense now? It even works for "downgrading" your -CURRENT system to -STABLE, if you want to not crash all the time, and realize the errors of your ways in having installed -CURRENT... > > 3) The default in 4.3-RELEASE is to have the IDE > > write caching off. > > If you submit a patch to add the proper entries to > /boot/loader.conf in the MFSROOT image, I'd commit it. > This would ensure the installation process always runs > with write cashing on. I wasn't sure that this was processed correctly from the MFS image. I will look at doing a patch; but it won't help my own situation, since I don't really boot the thing in order to upgrade. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B4DF83C.939061AD>