Re: Failure to build FreeBSD 9.2
On Sat, 5 Oct 2013 09:40:31 +0300, Juris Kaminskis wrote: > i recompiled my kernel with more verbose output and I see following errors > before it stops: > > procfs registered > panic: No usable event timer found! > cpuid=0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > panic() at panic+0x1d8/frame > initclocks() > mi_startup() > btext() ... > KDB: enter: panic > [thread pid 0 tid 10] > Stopped at kdb_enter+0x3b: moxq > > can someone help me to explain what this means and what to do next? In many cases, this indicates a problem introduced by the computer's BIOS settings or ACPI. Make sure ACPI is enabled and the BIOS is configured properly (e. g. no timer settings modified or features deactivated). You could also check if a newer version of the BIOS is available. In addition, there's the suggestion to add the line debug.acpi.disabled="hostres" to /boot/loader.conf and reboot. Source: http://www.freebsd.org/releases/9.0R/errata.html -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Failure to build FreeBSD 9.2
i recompiled my kernel with more verbose output and I see following errors before it stops: procfs registered panic: No usable event timer found! cpuid=0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x1d8/frame initclocks() mi_startup() btext() ... KDB: enter: panic [thread pid 0 tid 10] Stopped at kdb_enter+0x3b: moxq can someone help me to explain what this means and what to do next? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: 9.1 - 9.2 upgrade
On Fri, 4 Oct 2013 21:49:18 -0700, Doug Hardie wrote: > > On 4 October 2013, at 20:03, Polytropon wrote: > > > On Fri, 4 Oct 2013 19:42:15 -0700, Doug Hardie wrote: > >> > >> On 4 October 2013, at 19:08, Polytropon wrote: > >> > >>> On Fri, 4 Oct 2013 18:58:52 -0700, Doug Hardie wrote: > The exact sequence was: > > Step 1: freebsd-update from 9.1 to 9.2 > >>> > >>> Have you verified in /etc/freebsd-update.conf that "src" > >>> is definitely part of what should be updated? > >> > >> System is not bootable - can't verify anything… > > > > Does the system (or better, its "enclosure", software-wise) > > allow booting a rescue system or an emergency media, such > > as a FreeBSD v9 live system? > > Yes - but there is no one there who can successfully be told > how to run it. Not even inserting a USB stick (with the FreeBSD memstick data) or a CD? > We have serious communications issues - they want to use back > slashes and have no idea what a slash is. Maybe that is the result of many years of "administration" on "Windows" PCs. :-) > Even if you tell them which key to use, they know better and > use a back slash cause thats what Windoze uses. Uh... "knowing better" would disqualify them as maintainers of a server installation. The inability to learn (or even to read and follow instructions) is a dangerous thing. > The disk should be in the mail to me now. I will be able to > work with it when it arrives. Okay, that's also a possible alternative. To be honest, that's the first time I hear about this procedure. But doable. > > The file /etc/freebsd-update.conf should contain the line > > > > Components src world kernel > > > > if you want to make sure the source is properly updated, > > along with the world and kernel (GENERIC). > > As indicated before, I don't think all the source got updated. > The kernel showed 9.2 after recompilation. However UPDATING > was not updated. Thats as much as I could check before. I assume that this could be possible by inconsistently updated sources. It would be a good start to remove /usr/src and download the sources of the correct version via SVN _or_ freebsd-update again. Before the next installation attempt, /usr/obj should be removed as well, just to be sure. > Step 5: reboot > >>> > >>> Attention: Into single-user mode. > >> > >> Not possible since the system is located over 100 miles away. > >> Everything has to be done via remote console. > > > > Does this mean "SSH only" or do you have a _real_ console > > transmission by which you can access the system _prior_ to > > the OS providing the SSH access? I'm mentioning this because > > the traditional approach requires (few) steps done in the > > single-user mode where no SSH connectivity is provided in > > the "normal" way… > > I have a telnet box that has serial connections to the console > ports. That approach has been used without any issues since > FreeBSD 2.5. I do disable all ports during the process via an > reduced rc.conf file. A serial console should also work, but even though I've been using serial consoles (and _real_ serial terminals), one thing I'm not sure about: Is it possible to interrupt (!) the boot process at an early stage to get to the loader prompt and boot into single user mode from there? Ok boot -s If not, do you have the "beastie menu" (or whatever it is called today) enabled to go to SUM to perform the "make installworld" step? Anyway, if you can install everything is required with the disk at home, and then send it back to that "datacenter" (according to your characterization, the quotes are deserved), that should solve the problems and make sure everything works as intended. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: 9.1 - 9.2 upgrade
On 4 October 2013, at 20:03, Polytropon wrote: > On Fri, 4 Oct 2013 19:42:15 -0700, Doug Hardie wrote: >> >> On 4 October 2013, at 19:08, Polytropon wrote: >> >>> On Fri, 4 Oct 2013 18:58:52 -0700, Doug Hardie wrote: The exact sequence was: Step 1: freebsd-update from 9.1 to 9.2 >>> >>> Have you verified in /etc/freebsd-update.conf that "src" >>> is definitely part of what should be updated? >> >> System is not bootable - can't verify anything… > > Does the system (or better, its "enclosure", software-wise) > allow booting a rescue system or an emergency media, such > as a FreeBSD v9 live system? Yes - but there is no one there who can successfully be told how to run it. We have serious communications issues - they want to use back slashes and have no idea what a slash is. Even if you tell them which key to use, they know better and use a back slash cause thats what Windoze uses. The disk should be in the mail to me now. I will be able to work with it when it arrives. > > The file /etc/freebsd-update.conf should contain the line > > Components src world kernel > > if you want to make sure the source is properly updated, > along with the world and kernel (GENERIC). As indicated before, I don't think all the source got updated. The kernel showed 9.2 after recompilation. However UPDATING was not updated. Thats as much as I could check before. > > > Step 5: reboot >>> >>> Attention: Into single-user mode. >> >> Not possible since the system is located over 100 miles away. >> Everything has to be done via remote console. > > Does this mean "SSH only" or do you have a _real_ console > transmission by which you can access the system _prior_ to > the OS providing the SSH access? I'm mentioning this because > the traditional approach requires (few) steps done in the > single-user mode where no SSH connectivity is provided in > the "normal" way… I have a telnet box that has serial connections to the console ports. That approach has been used without any issues since FreeBSD 2.5. I do disable all ports during the process via an reduced rc.conf file. > > > > > > -- > Polytropon > Magdeburg, Germany > Happy FreeBSD user since 4.0 > Andra moi ennepe, Mousa, ... > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: 9.1 - 9.2 upgrade
On Fri, 4 Oct 2013 19:42:15 -0700, Doug Hardie wrote: > > On 4 October 2013, at 19:08, Polytropon wrote: > > > On Fri, 4 Oct 2013 18:58:52 -0700, Doug Hardie wrote: > >> The exact sequence was: > >> > >> Step 1: freebsd-update from 9.1 to 9.2 > > > > Have you verified in /etc/freebsd-update.conf that "src" > > is definitely part of what should be updated? > > System is not bootable - can't verify anything… Does the system (or better, its "enclosure", software-wise) allow booting a rescue system or an emergency media, such as a FreeBSD v9 live system? The file /etc/freebsd-update.conf should contain the line Components src world kernel if you want to make sure the source is properly updated, along with the world and kernel (GENERIC). > >> Step 5: reboot > > > > Attention: Into single-user mode. > > Not possible since the system is located over 100 miles away. > Everything has to be done via remote console. Does this mean "SSH only" or do you have a _real_ console transmission by which you can access the system _prior_ to the OS providing the SSH access? I'm mentioning this because the traditional approach requires (few) steps done in the single-user mode where no SSH connectivity is provided in the "normal" way... -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: 9.1 - 9.2 upgrade
On 4 October 2013, at 19:08, Polytropon wrote: > On Fri, 4 Oct 2013 18:58:52 -0700, Doug Hardie wrote: >> The exact sequence was: >> >> Step 1: freebsd-update from 9.1 to 9.2 > > Have you verified in /etc/freebsd-update.conf that "src" > is definitely part of what should be updated? System is not bootable - can't verify anything… > > > >> Step 2: make buildworld >> Step 3: make build_kernel KERNCONF=LAFN >> Step 4: make install_kernel KERNCONF=LAFN > > I assume the correct targets "buildkernel" and "installkernel" > have been used. ;-) > Yes > > >> Step 5: reboot > > Attention: Into single-user mode. Not possible since the system is located over 100 miles away. Everything has to be done via remote console. > > > >> Step 6: mergemaster -p >> Step 7: make installworld >> Step 8: mergemaster -i >> Step 9: make delete-old >> Step 10: reboot > > Into multi-user mode again. > > > >> oops, something went wrong.. >> >> After step 5, uname -a still showed 9.2 but now it listed the >> kernel I built rather than generic. > > Again, verify your configuration. Compare your steps with the > comment header of /usr/src/Makefile which illustrates the > exact procedure; from a (dated) 8-STABLE installation: > > 1. `cd /usr/src' (or to the directory containing your source tree). > 2. `make buildworld' > 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). > 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). > [steps 3. & 4. can be combined by using the "kernel" target] > 5. `reboot'(in single user mode: boot -s from the loader prompt). > 6. `mergemaster -p' > 7. `make installworld' > 8. `make delete-old' > 9. `mergemaster'(you may wish to use -i, along with -U or -F). > 10. `reboot' > 11. `make delete-old-libs' (in case no 3rd party program uses them anymore) > > > -- > Polytropon > Magdeburg, Germany > Happy FreeBSD user since 4.0 > Andra moi ennepe, Mousa, ... > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: 9.1 - 9.2 upgrade
On Fri, 4 Oct 2013 18:58:52 -0700, Doug Hardie wrote: > The exact sequence was: > > Step 1: freebsd-update from 9.1 to 9.2 Have you verified in /etc/freebsd-update.conf that "src" is definitely part of what should be updated? > Step 2: make buildworld > Step 3: make build_kernel KERNCONF=LAFN > Step 4: make install_kernel KERNCONF=LAFN I assume the correct targets "buildkernel" and "installkernel" have been used. ;-) > Step 5: reboot Attention: Into single-user mode. > Step 6: mergemaster -p > Step 7: make installworld > Step 8: mergemaster -i > Step 9: make delete-old > Step 10: reboot Into multi-user mode again. > oops, something went wrong.. > > After step 5, uname -a still showed 9.2 but now it listed the > kernel I built rather than generic. Again, verify your configuration. Compare your steps with the comment header of /usr/src/Makefile which illustrates the exact procedure; from a (dated) 8-STABLE installation: 1. `cd /usr/src' (or to the directory containing your source tree). 2. `make buildworld' 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). [steps 3. & 4. can be combined by using the "kernel" target] 5. `reboot'(in single user mode: boot -s from the loader prompt). 6. `mergemaster -p' 7. `make installworld' 8. `make delete-old' 9. `mergemaster'(you may wish to use -i, along with -U or -F). 10. `reboot' 11. `make delete-old-libs' (in case no 3rd party program uses them anymore) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: 9.1 - 9.2 upgrade
On 4 October 2013, at 09:22, dweimer wrote: > On 10/04/2013 1:36 am, Doug Hardie wrote: >> On 3 October 2013, at 11:48, Doug Hardie wrote: >>> On 3 October 2013, at 10:49, Doug Hardie wrote: I just did an upgrade using freebsd-update to 9.2. This system uses a custom kernel so I am rebuilding everything after the update completed. However, I noticed that /usr/src/UPDATING has not been updated. The first entry still says: 9.1-RELEASE. Is this correct? >>> Well, it just got worse - The last reboot now fails: I am using a remote >>> console and it shows: >>> --> Press a key on the console to reboot <-- >>> Rebooting... >>> Consoles: internal video/keyboard serial port >>> BIOS drive A: is disk0 >>> BIOS drive C: is disk1 >>> BIOS 639kB/2087360kB available memory >>> FreeBSD/x86 bootstrap loader, Revision 1.1 >>> (d...@zool.lafn.org, Thu Oct 3 04:23:13 PDT 2013) >>> Can't work out which disk we are booting from. >>> Guessed BIOS device 0x not found by probes, defaulting to disk0: >>> panic: free: guard1 fail @ 0x7f481ed0 from >>> /usr/src/sys/boot/i386/loader/../../common/module.c:1004 >>> --> Press a key on the console to reboot <-- >>> I can enter a string as it doesn't try to reboot again till the return is >>> entered. I've tried b disk1, but it still only tries disk0. The system >>> rebooted fine after the reboot after make kernel. Mergemaster didn't seem >>> to affect anything dealing with boot. Don't know what make delete-old does >>> but the descriptions lead me to not believe it could cause this. This >>> system is on the other side of LA from me so its a major trip timewise. >>> Any ideas how this can be recovered remotely? >> Booting off the live CD didn't find anything obviously wrong. I >> replaced the kernel with the old one and still the same error. I am >> having the drive mailed to me and will work with it here. However, it >> appears a new install is going to be required. The old sysinstall had >> the capability to skip over the formatting of the disk by just >> entering quit. It would then just replace the system components and >> leave everything else alone. I don't see any obvious way to do the >> same thing with bsdinstall. Is there a way to do that. I don't want >> to have to completely rebuild the drive, but just replace the system. >> ___ >> freebsd-questions@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >> To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" > > Just want to clarify the steps that started this > > if I read everything right: > > Step 1: freebsd-update from 9.1 to 9.2 > Step 2: compile from source ? Was this world, or just the custom kernel?? > Step 3: make delete-old > Step 4: mergemaster > Step 5: reboot > oops, something went wrong.. > > If my suspicions are correct, the source was still 9.1 patch 7, but the > system was running 9.2 from the binary update. This may have caused the make > delete-old to delete things it shouldn't have > > The very first thing I would do is bring the disk up in another system and > make a backup copy of the data. > > I have never tried this process, I am basically just taking the steps I use > for updating a zfs system using boot environments, and applying them in order > to build a new kernel and world to an alternate directory, as a method of > recovering the system. > > The next step I would take is to then mount the file systems in an alternate > location, /mnt for example > > make MAKEOBJDIRPREFIX /mnt/usr/obj > make DESTDIR /mnt > cd /mnt/usr/src > rm -r * .svn > rm -r /usr/obj/* > svn co https://svn0.us-west.freebsd.org/base/releng/9.2 > make buildwolrd > make buildkernel > make installkernel > make installworld > make -DBATCH_DELETE_OLD_FILES delete-old > make -DBATCH_DELETE_OLD_FILES delete-old-libs > mergemaster -Ui /mnt/usr/src -D /mnt > > With some luck the file system will now contain a boot-able FreeBSD install, > that will still have all the settings in place, except it will be the generic > kernel. You should then just be able to build and install the custom kernel, > from the booted system as you normally would. > The exact sequence was: Step 1: freebsd-update from 9.1 to 9.2 Step 2: make buildworld Step 3: make build_kernel KERNCONF=LAFN Step 4: make install_kernel KERNCONF=LAFN Step 5: reboot Step 6: mergemaster -p Step 7: make installworld Step 8: mergemaster -i Step 9: make delete-old Step 10: reboot oops, something went wrong.. After step 5, uname -a still showed 9.2 but now it listed the kernel I built rather than generic. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Failure to build FreeBSD 9.2
Hello, I am desperate trying to build FreeBSD 9.2. The same happens with FreeBSD-Current. When I build 9.1 kernel without building world everything is ok. My svn info Path: . Working Copy Root Path: /usr/src URL: http://svn0.eu.freebsd.org/base/release/9.2.0 Repository Root: http://svn0.eu.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 255954 Node Kind: directory Schedule: normal Last Changed Author: gjb Last Changed Rev: 255898 Last Changed Date: 2013-09-26 21:28:11 +0300 (Thu, 26 Sep 2013) When I do standard process: make buildworld make buildkernel make installkernel reboot my kernel hangs up and does not respond. I have tried a lot of things but nothing works. my new kernel hangs right after: pci1: on pcib1 my uname -a FreeBSD station 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 and my dmesg output: Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2211.11-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40fb2 Family = f Model = 4b Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f real memory = 2147483648 (2048 MB) avail memory = 2045505536 (1950 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) unknown: memory range not supported unknown: memory range not supported unknown: memory range not supported acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 7ff0 (3) failed cpu0: on acpi0 cpu1: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 3.0 on pci0 pcib1: failed to allocate initial memory window: 0xffb0-0xffbf pci1: on pcib1 vgapci0: port 0x9800-0x98ff mem 0xc000-0xcfff irq 19 at device 0.0 on pci1 hdac0: irq 16 at device 0.1 on pci1 pcib2: at device 6.0 on pci0 pci2: on pcib2 re0: port 0xa800-0xa8ff mem 0xffcff000-0xffcf irq 18 at device 0.0 on pci2 re0: Using 1 MSI message re0: Chip rev. 0x3800 re0: MAC rev. 0x miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 00:19:db:f6:72:d0 ahci0: port 0xe800-0xe807,0xe400-0xe403,0xe000-0xe007,0xdc00-0xdc03,0xd800-0xd80f mem 0xffeffc00-0xffef irq 22 at device 18.0 on pci0 ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ohci0: mem 0xffefe000-0xffefefff irq 16 at device 19.0 on pci0 usbus0 on ohci0 ohci1: mem 0xffefd000-0xffefdfff irq 17 at device 19.1 on pci0 usbus1 on ohci1 ohci2: mem 0xffefc000-0xffefcfff irq 18 at device 19.2 on pci0 usbus2 on ohci2 ohci3: mem 0xffefb000-0xffefbfff irq 17 at device 19.3 on pci0 usbus3 on ohci3 ohci4: mem 0xffefa000-0xffefafff irq 18 at device 19.4 on pci0 usbus4 on ohci4 ehci0: mem 0xffeff800-0xffeff8ff irq 19 at device 19.5 on pci0 ehci0: AMD SB600/700 quirk applied usbus5: EHCI version 1.0 usbus5 on ehci0 pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: at channel 0 on atapci0 hdac1: mem 0xffef4000-0xffef7fff irq 16 at device 20.2 on pci0 isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pci3: on pcib3 fwohci0: port 0xbc00-0xbc7f mem 0xffdff800-0xffdf irq 20 at device 2.0 on pci3 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:dc:10:00:01:2d:cc:8b fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 byt
Re: # portmaster -r pixman fails with !#/bin/sh list too long
On Fri, Oct 4, 2013 at 12:09 PM, Warren Block wrote: > On Thu, 3 Oct 2013, Antonio Olivares wrote: > >> Have tried that, but it rebuilds pixman, but then X bombs out blurting >> out messages that libpixman.so is missing :( >> >> I have tried to remove print/texlive-scheme-full; removed it, but then >> run portmaster -R pixman, and portmaster -r pixman and the running of >> it stops with message that !#/bin/sh .. argument too long and comes up >> with texlive-?-?-_1 or similar. Have not been successful in >> fixing this issue. I have 2 machines working and 2 not working >> because of this. I am running out of ideas. Is there another way to >> fix this issue manually, i.e, going to /usr/ports/x11/pixman and >> rebuilding it there or have to go one by one? > > > Careful: -R has a different meaning with portmaster than it does with > portupgrade. It does not mean "recursive" like lowercase "-r". > > pkg_libchk from sysutils/bsdadminscripts can be used to detect installed > ports that depend on missing libraries. From that, it may be possible to > just give a list of all the ones that are missing pixman to portmaster. Dear all, It appears that using # portmaster -d -r pixman -x 'texlive-*-*' is doing the job :) I am keeping my fingers crossed and hope it comes through and succeeds! It stopped with libexo, but got that sorted out. Then stopped with mplayer*, but I am skipping it at this time. -x 'mplayer-*' and hope it succeeds, I'll then rebuild mplayer later if needed. Best Regards, Antonio ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: gptid's in fstab while installing FreeBSD using ISO
On Fri, 4 Oct 2013 20:04:09 +0530, varanasi sainath wrote: > Hi All, > > How do I get gptid's as default in fstab while installing using FreeBSD iso > file (Virtual,machine installation) ? > Is this possible currently? As far as I know, the installer "bsdinstall" currently does not have this option included, but it already offers labeling the partitions as desired, so you could change the content of /etc/fstab manually to use labels instead of those device names. You could do this as a post-installation task while leaving the installer for the command shell and using an editor to do this. > if not how do I achieve this? > I use guided partitioning while installing - If I were to tweak in to the > source code which files or drivers I should be focusing on? I haven't looked into the source yet, but I assume you should concentrate on the component doing the partitioning tasks as explained here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/bsdinstall-partitioning.html > which drivers write the contents of fstab? The corresponding installer's component itself which creates the file according to the partitioning layout at installation time. I assume the required data will actually be written when the installer performs the _real_ installation steps (committing to the installation). > PS: any reason why we use device names in the place of gptid's as default > in fstab. Because it's not always wanted or intended. Next to GPT partitioning with GPT labels, UFS partitioning is possible (both MBR and dedicated style), which _may_ have cases where it needs to be applied. Maybe this can happen when you have a very strange combination of striping, mirroring, encryption and other things that require metadata here and there... The different methods have different capabilities regarding labels (UFS labels, UFSIDs to be mentioned). You can find out more about them here: http://www.freebsd.org/doc/handbook/geom-glabel.html And read about the different methods of partitioning itself: http://www.wonkity.com/~wblock/docs/html/disksetup.html Even "hardcoded" device names could also be required, though I can't imagine such a situation at the moment. :-) It highly depends on the toolset you're using (the bsdinstall program, gpart, fdisk & disklabel, newfs only). PS. I've trimmed the CC list to the freebsd-questions@ list for my reply, hope that's okay. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: # portmaster -r pixman fails with !#/bin/sh list too long
On Thu, 3 Oct 2013, Antonio Olivares wrote: Have tried that, but it rebuilds pixman, but then X bombs out blurting out messages that libpixman.so is missing :( I have tried to remove print/texlive-scheme-full; removed it, but then run portmaster -R pixman, and portmaster -r pixman and the running of it stops with message that !#/bin/sh .. argument too long and comes up with texlive-?-?-_1 or similar. Have not been successful in fixing this issue. I have 2 machines working and 2 not working because of this. I am running out of ideas. Is there another way to fix this issue manually, i.e, going to /usr/ports/x11/pixman and rebuilding it there or have to go one by one? Careful: -R has a different meaning with portmaster than it does with portupgrade. It does not mean "recursive" like lowercase "-r". pkg_libchk from sysutils/bsdadminscripts can be used to detect installed ports that depend on missing libraries. From that, it may be possible to just give a list of all the ones that are missing pixman to portmaster. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: 9.1 - 9.2 upgrade
On 10/04/2013 1:36 am, Doug Hardie wrote: On 3 October 2013, at 11:48, Doug Hardie wrote: On 3 October 2013, at 10:49, Doug Hardie wrote: I just did an upgrade using freebsd-update to 9.2. This system uses a custom kernel so I am rebuilding everything after the update completed. However, I noticed that /usr/src/UPDATING has not been updated. The first entry still says: 9.1-RELEASE. Is this correct? Well, it just got worse - The last reboot now fails: I am using a remote console and it shows: --> Press a key on the console to reboot <-- Rebooting... Consoles: internal video/keyboard serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 639kB/2087360kB available memory FreeBSD/x86 bootstrap loader, Revision 1.1 (d...@zool.lafn.org, Thu Oct 3 04:23:13 PDT 2013) Can't work out which disk we are booting from. Guessed BIOS device 0x not found by probes, defaulting to disk0: panic: free: guard1 fail @ 0x7f481ed0 from /usr/src/sys/boot/i386/loader/../../common/module.c:1004 --> Press a key on the console to reboot <-- I can enter a string as it doesn't try to reboot again till the return is entered. I've tried b disk1, but it still only tries disk0. The system rebooted fine after the reboot after make kernel. Mergemaster didn't seem to affect anything dealing with boot. Don't know what make delete-old does but the descriptions lead me to not believe it could cause this. This system is on the other side of LA from me so its a major trip timewise. Any ideas how this can be recovered remotely? Booting off the live CD didn't find anything obviously wrong. I replaced the kernel with the old one and still the same error. I am having the drive mailed to me and will work with it here. However, it appears a new install is going to be required. The old sysinstall had the capability to skip over the formatting of the disk by just entering quit. It would then just replace the system components and leave everything else alone. I don't see any obvious way to do the same thing with bsdinstall. Is there a way to do that. I don't want to have to completely rebuild the drive, but just replace the system. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" Just want to clarify the steps that started this if I read everything right: Step 1: freebsd-update from 9.1 to 9.2 Step 2: compile from source ? Was this world, or just the custom kernel?? Step 3: make delete-old Step 4: mergemaster Step 5: reboot oops, something went wrong.. If my suspicions are correct, the source was still 9.1 patch 7, but the system was running 9.2 from the binary update. This may have caused the make delete-old to delete things it shouldn't have The very first thing I would do is bring the disk up in another system and make a backup copy of the data. I have never tried this process, I am basically just taking the steps I use for updating a zfs system using boot environments, and applying them in order to build a new kernel and world to an alternate directory, as a method of recovering the system. The next step I would take is to then mount the file systems in an alternate location, /mnt for example make MAKEOBJDIRPREFIX /mnt/usr/obj make DESTDIR /mnt cd /mnt/usr/src rm -r * .svn rm -r /usr/obj/* svn co https://svn0.us-west.freebsd.org/base/releng/9.2 make buildwolrd make buildkernel make installkernel make installworld make -DBATCH_DELETE_OLD_FILES delete-old make -DBATCH_DELETE_OLD_FILES delete-old-libs mergemaster -Ui /mnt/usr/src -D /mnt With some luck the file system will now contain a boot-able FreeBSD install, that will still have all the settings in place, except it will be the generic kernel. You should then just be able to build and install the custom kernel, from the booted system as you normally would. -- Thanks, Dean E. Weimer http://www.dweimer.net/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
gptid's in fstab while installing FreeBSD using ISO
Hi All, How do I get gptid's as default in fstab while installing using FreeBSD iso file (Virtual,machine installation) ? Is this possible currently? if not how do I achieve this? I use guided partitioning while installing - If I were to tweak in to the source code which files or drivers I should be focusing on? which drivers write the contents of fstab? PS: any reason why we use device names in the place of gptid's as default in fstab. Thanks, Sainath. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Soekris for a Trac server
On 01/10/2013 08:22, Michael wrote: > Also I am bit unsure about the setup I should pick: we are a hand of > users for the service and I would like to know if a 64-MB Ram and a > 166Mhz setup could do, or if I definitely should consider a faster CPU > or more RAM. Given my actual jail based setup, is there an easy way to Definitely aim for a much faster CPU and more RAM. Trac is written in Python, and is pretty slow (unless you are not bothered by pages being generated over a few seconds...). signature.asc Description: OpenPGP digital signature
