portupgrade forget package options
Hi, I run "/usr/local/sbin/portupgrade -arR" in cron job to update packages. Today I found the CPU is drained up by 5 instances of "script" and "dialog", because everyday when portupgrade updates python, it tried to display a menu in text mode and ask for a few options (such as whether python should support IPv6 etc), which of course hangs in cron job. Isn't it nice for portupgrade to have an option to remember the previous installation options of each package installed? It is an "upgrade" of port anyway. Or did I miss something? Thank you! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: binary upgrade issues
"freebsd-update IDS" found the following. Do I need to grab the kernel files for 6.1? If so, how? I did not find them in ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/6.1-RELEASE/kernels/ Thank you, The following files, which are distributed as part of the binary release, have been modified locally: /boot/beastie.4th /boot/boot /boot/boot2 /boot/cdboot /boot/defaults/loader.conf /boot/kernel/aic.ko /boot/kernel/aio.ko /boot/kernel/alpm.ko /boot/kernel/amd.ko /boot/kernel/amdpm.ko /boot/kernel/amr.ko /boot/kernel/amr_linux.ko /boot/kernel/aout.ko /boot/kernel/apm.ko /boot/kernel/apm_saver.ko /boot/kernel/arcmsr.ko /boot/kernel/arcnet.ko /boot/kernel/asr.ko /boot/kernel/ata.ko /boot/kernel/atacard.ko /boot/kernel/atadisk.ko /boot/kernel/ataisa.ko /boot/kernel/atapicam.ko /boot/kernel/atapicd.ko /boot/kernel/atapifd.ko /boot/kernel/atapist.ko /boot/kernel/ataraid.ko /boot/kernel/ath_rate.ko /boot/kernel/bktr_mem.ko /boot/kernel/blank_saver.ko /boot/kernel/bridge.ko /boot/kernel/cardbus.ko /boot/kernel/cbb.ko /boot/kernel/cd9660.ko /boot/kernel/cd9660_iconv.ko /boot/kernel/ciss.ko /boot/kernel/coda.ko /boot/kernel/coda5.ko /boot/kernel/cpufreq.ko /boot/kernel/cryptodev.ko /boot/kernel/daemon_saver.ko /boot/kernel/dcons.ko /boot/kernel/dcons_crom.ko /boot/kernel/digi.ko /boot/kernel/digi_CX.ko /boot/kernel/digi_CX_PCI.ko /boot/kernel/digi_EPCX.ko /boot/kernel/digi_EPCX_PCI.ko /boot/kernel/digi_Xe.ko /boot/kernel/digi_Xem.ko /boot/kernel/digi_Xr.ko /boot/kernel/dpt.ko /boot/kernel/dragon_saver.ko /boot/kernel/dummynet.ko /boot/kernel/elink.ko /boot/kernel/exca.ko /boot/kernel/ext2fs.ko /boot/kernel/fade_saver.ko /boot/kernel/fdescfs.ko /boot/kernel/fire_saver.ko /boot/kernel/firmware.ko /boot/kernel/g_md.ko /boot/kernel/geom_apple.ko /boot/kernel/geom_bde.ko /boot/kernel/geom_bsd.ko /boot/kernel/green_saver.ko /boot/kernel/if_sl.ko /boot/kernel/if_tap.ko /boot/kernel/linker.hints /boot/kernel/sis.ko /boot/kernel/smb.ko /boot/kernel/smbios.ko /boot/kernel/smbus.ko /boot/kernel/snd_ad1816.ko /boot/kernel/snd_als4000.ko /boot/kernel/snd_atiixp.ko /boot/kernel/snd_cmi.ko /boot/kernel/snd_cs4281.ko /boot/kernel/snd_csa.ko /boot/kernel/snd_driver.ko /boot/kernel/snd_ds1.ko /boot/kernel/snd_emu10k1.ko /boot/kernel/snd_es137x.ko /boot/kernel/snd_ess.ko /boot/kernel/snd_fm801.ko /boot/kernel/snd_ich.ko /boot/kernel/snd_maestro.ko /boot/kernel/snd_maestro3.ko /boot/kernel/snd_mss.ko /boot/kernel/snd_neomagic.ko /boot/kernel/snd_sb16.ko /boot/kernel/snd_sb8.ko /boot/kernel/snd_sbc.ko /boot/kernel/snd_solo.ko /boot/kernel/snd_t4dwave.ko /boot/kernel/snd_uaudio.ko /boot/kernel/snd_via8233.ko /boot/kernel/snd_via82c686.ko /boot/kernel/snd_vibes.ko /boot/kernel/snp.ko /boot/kernel/sound.ko /boot/kernel/speaker.ko /boot/kernel/splash_bmp.ko /boot/kernel/splash_pcx.ko /boot/kernel/sppp.ko /boot/kernel/star_saver.ko /boot/kernel/stg.ko /boot/kernel/streams.ko /boot/kernel/sym.ko /boot/kernel/sysvmsg.ko /boot/kernel/sysvsem.ko /boot/kernel/sysvshm.ko /boot/kernel/tdfx.ko /boot/kernel/trm.ko /boot/kernel/twa.ko /boot/kernel/twe.ko /boot/kernel/uart.ko /boot/kernel/ubsa.ko /boot/kernel/ubsec.ko /boot/kernel/ubser.ko /boot/kernel/ubtbcmfw.ko /boot/kernel/ucom.ko /boot/kernel/ucycom.ko /boot/kernel/udbp.ko /boot/kernel/udf.ko /boot/kernel/udf_iconv.ko /boot/kernel/ufm.ko /boot/kernel/uftdi.ko /boot/kernel/ugen.ko /boot/kernel/uhid.ko /boot/kernel/ukbd.ko /boot/kernel/ulpt.ko /boot/kernel/umass.ko /boot/kernel/umct.ko /boot/kernel/umodem.ko /boot/kernel/ums.ko /boot/kernel/unionfs.ko /boot/kernel/uplcom.ko /boot/kernel/urio.ko /boot/kernel/uscanner.ko /boot/kernel/utopia.ko /boot/kernel/uvisor.ko /boot/kernel/uvscom.ko /boot/kernel/vesa.ko /boot/kernel/viapm.ko /boot/kernel/vkbd.ko /boot/kernel/vpd.ko /boot/kernel/vpo.ko /boot/kernel/warp_saver.ko /boot/kernel/wlan.ko /boot/kernel/wlan_acl.ko /boot/kernel/wlan_ccmp.ko /boot/kernel/wlan_tkip.ko /boot/kernel/wlan_wep.ko /boot/kernel/zlib.ko /boot/loader /boot/loader.help /boot/loader.rc /boot/pxeboot /etc/group /etc/hosts /etc/mail/aliases /etc/mail/mailer.conf /etc/manpath.config /etc/master.passwd /etc/motd /etc/newsyslog.conf /etc/passwd /etc/pf.conf /etc/pwd.db /etc/shells /etc/spwd.db /etc/sysctl.conf /usr/bin/flex /usr/sbin/watchdog On 8/5/06, Colin Percival <[EMAIL PROTECTED]> wrote: John Rogers wrote: > Before I saw your reply, I just manually created those old-index etc > by following upgrade.sh, and ran the rest of the upgrade.sh from the > "Removing schg flag from existing files..." part. After that I have > ran portupgrade, portsnap etc, and so far don't see problem. Do I > still need to go back to 6.0 and run upgrade.sh? You're probably ok, but there's a chance that you managed to not upgrade all the binaries on the system. I recommend running `freebsd-update IDS`; this will tell you which files, if any, don't match the versions shipped with the release. Colin Percival
Re: binary upgrade issues
Hi, you are right - there was indeed the following messages: kernel: ad0: FAILURE - READ_DMA status=51 error=40 And this message appeared starting from the date I ran CFS, an encrypted filesystem. It's a half year old WesternDigital250GB disk. I now disabled dma (was UDMA100 actually) by adding "hw.ata.ata_dma=0" to /boot/loader.conf . Before I saw your reply, I just manually created those old-index etc by following upgrade.sh, and ran the rest of the upgrade.sh from the "Removing schg flag from existing files..." part. After that I have ran portupgrade, portsnap etc, and so far don't see problem. Do I still need to go back to 6.0 and run upgrade.sh? Thanks. On 8/4/06, Colin Percival <[EMAIL PROTECTED]> wrote: John Rogers wrote: > Installing new kernel into /boot/GENERIC... done. > Moving /boot/kernel to /boot/kernel.old... done. > Moving /boot/GENERIC to /boot/kernel... done. > Removing schg flag from existing files... > > Then my connection to the server froze and I found the server rebooted > itself. After login I found it was 6.1-RELEASE FreeBSD 6.1-RELEASE > #0: Sun May 7 04:32:43 UTC 2006. > > Don't know why it rebooted, and my concern it: had it finished > upgrading? Probably not. > I looked into the upgrade.sh and found it should continue > working on files referred in old-index, new-index-nonkern, new-index. > However none of these files were found in the directory. Also I am > worried whether the schg flags were recovered. How can I check these? Sounds like a generic case of 'system crashed and recently created files weren't written to disk yet'. I'm really suspicious of the hardware here, but I'd suggest 1. mv /boot/kernel /boot/kernel.new 2. mv /boot/kernel.old /boot/kernel 3. reboot (back into 6.0-RELEASE) 4. Run the script again and hope that it manages to finish installing everything this time. Colin Percival ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: binary upgrade issues
Wow, I did not expect Colin's direct reply - and so prompt! Thanks, and great to know binary updates will be foreseeable. I actually already did it again, since it doesn't make sense to binary upgrade all those source files, I renamed /usr/src to something else, and this greatly reduced the number of files for fetching to 435 ones. The old error message is gone (it's a fairly new and high quality server). It was eventless until to the following: Installing new kernel into /boot/GENERIC... done. Moving /boot/kernel to /boot/kernel.old... done. Moving /boot/GENERIC to /boot/kernel... done. Removing schg flag from existing files... Then my connection to the server froze and I found the server rebooted itself. After login I found it was 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 04:32:43 UTC 2006. Don't know why it rebooted, and my concern it: had it finished upgrading? I looked into the upgrade.sh and found it should continue working on files referred in old-index, new-index-nonkern, new-index. However none of these files were found in the directory. Also I am worried whether the schg flags were recovered. How can I check these? Thank you. Colin Percival wrote: > John Rogers wrote: > Hi, I was upgrading following Colin's "FreeBSD 6.0 to FreeBSD 6.1 > binary upgrade" > > http://www.daemonology.net/freebsd-upgrade-6.0-to-6.1/ > > but it failed. I installed freebsd 6.0 release and only used Colin's > freebsd-update to updae before. There is plenty of free space on that > partition. What do you advise me to do to finish the upgrade? Based on what you pasted below, I suggest 1. Figure out why /usr/bin/gdbtui can't be read. In particular, make sure your hard drive isn't dying. 2. The error which made the script terminate is either due to a dying hard drive or a network problem which made it impossible to fetch some files. Re-run the script; it won't bother fetching files which it already has. Note that at this point all the script has done is to examine your system and download files; it won't start actually upgrading anything until it makes sure that it has all the files it needs. :-) > I also wonder why these binary update and upgrade are not legitimized > in the freebsd core distribution. An important reason why linux is > used by more is its easy update solution similar to Microsoft's > Windows Update. Sure "make world" is fun especially to developers. > But providing easy update and upgrade tools in addition will attract a > large user base who just need a stable and easy to use operation > system - and many of them can be companies who can be potential donors > to the freebsd project. So the effort to this path will be well > rewarded. We're moving in that direction. Everything starts out by being experimental before becoming officially supported and endorsed. Colin Percival ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
binary upgrade issues
Hi, I was upgrading following Colin's "FreeBSD 6.0 to FreeBSD 6.1 binary upgrade" http://www.daemonology.net/freebsd-upgrade-6.0-to-6.1/ but it failed. I installed freebsd 6.0 release and only used Colin's freebsd-update to updae before. There is plenty of free space on that partition. What do you advise me to do to finish the upgrade? I also wonder why these binary update and upgrade are not legitimized in the freebsd core distribution. An important reason why linux is used by more is its easy update solution similar to Microsoft's Windows Update. Sure "make world" is fun especially to developers. But providing easy update and upgrade tools in addition will attract a large user base who just need a stable and easy to use operation system - and many of them can be companies who can be potential donors to the freebsd project. So the effort to this path will be well rewarded. Thank you very much! Tony # ./upgrade.sh Examining system... done. The following components of FreeBSD seem to be installed: kernel|generic src|base src|bin src|contrib src|crypto src|etc src|gnu src|include src|krb5 src|libexec src|lib src|release src|rescue src|sbin src|secure src|share src|sys src|tools src|ubin src|usbin world|base world|catpages world|dict world|doc world|info world|manpages The following components of FreeBSD do not seem to be installed: kernel|smp src|games world|games world|proflibs Does this look reasonable (y/n)? y Examining system (this will take a bit longer)...sha256: /usr/bin/gdbtui: Input/output error done. The following files from FreeBSD 6.0 have been modified since they were installed, but will be deleted or overwritten by new versions: /usr/bin/gdbtui The following files from FreeBSD 6.0 have been modified since they were installed, and will not be touched: /etc/hosts /etc/mail/aliases /etc/mail/mailer.conf /etc/manpath.config /etc/master.passwd /etc/motd /etc/newsyslog.conf /etc/passwd /etc/pwd.db /etc/shells /etc/spwd.db /etc/sysctl.conf The following files from FreeBSD 6.0 have been modified since they were installed, and the changes in FreeBSD 6.1 will be merged into the existing files: /etc/group /etc/pf.conf Does this look reasonable (y/n)? y Preparing to fetch files... done. Fetching 186 patches102030405060708090100110120130140150160170180... done. Applying patches... done. Fetching 41824 files10203040506070809010011012013014015016017018019020021022023024025026027028029030031032033034035036037038039040041042043044045046047048049050051052053054055056057058059060061062063064065066067068069070071072073074075076077078079080081082083084085086087088089090091092093094095096097098099010001010102010301040105010601070108010901100111011201130114011501160117011801190120012101220123012401250126012701280129013001310132013301340135013601370138013901400141014201430144014501460147014801490150015101520153015401550156015701580159016001610162016301640165016601670168016901700171017201730174017501760177017801790180018101820183018401850186018701880189019001910192019301940195019601970198019902000201020202030204020502060207020802090210021102120213021402150216021702180219022002210222022302240225022602270228022902300231023202330234023502360237023802390240024102420243024402450246024702480249025002510252025302540255025602570258025902600261026202630264026502660267026802690270027102720273027402750276027702780279028002810282028302840285028602870288028902900291029202930294029502960297029802990300030103020303030403050306030703080309031003110312031303140315031603170318031903200321032203230324032503260327032803290330033103320333