Re: System hanging during dump
Sorry for the late reply.
On 2008-Oct-19 11:39:02 +0300, Kostik Belousov <[EMAIL PROTECTED]> wrote:
>> I have built myself a looping 'ps -axl' which should let me gather more
>> information if it does re-appear. (In the process, I've found that ps
>> leaks memory, though that's not a problem until you wrap it in a loop).
>
>What memory ? Kernel one ? How did you noted this ? Could you add
>vmstat -z and vmstat -m to the loop and watch what allocation grows ?
ps(1) malloc's memory and doesn't free it. This isn't an issue in
normal operation because it's a once-through program. I hacked ps to
turn the guts of main() into a while(1){} loop and this showed the
process was growing. There were a couple of superfluous strdup()
calls that could be removed but I don't think it's worth making it
exhaustively clean up after itself (my hacking included hard-wiring
the options so I'm not sure my cleanup code is complete in the general
case). As a low priority, I'll create a PR covering the strdup's.
--
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
pgpDJgpu89NBs.pgp
Description: PGP signature
Re: FreeBSD 6.5-prerelease and if_re - patches needed?
On Sun, 02 Nov 2008 14:09:15 +0900 Pyun YongHyeon <[EMAIL PROTECTED]> wrote: > http://people.freebsd.org/~yongari/re/6.x/README > > Hope this helps. Yes it does, thanks! On boot, trherer is a noticable delay (tens of seconds) after printing these lines: re0: port 0xee00-0xeeff mem 0xfdfff000-0xfdff irq 19 at device 0.0 on pci2 re0: turning off MSI enable bit. re0: Chip rev. 0x3800 re0: MAC rev. 0x The original didn't have that delay. Otrher than that it works much better. Details: [EMAIL PROTECTED] uname -a FreeBSD kg-vm.kg4.no 6.4-PRERELEASE FreeBSD 6.4-PRERELEASE #3: Sun Nov 2 10:44:32 CET 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP amd64 [EMAIL PROTECTED] pciconf -lv | grep re0 -A 4 [EMAIL PROTECTED]:0:0: class=0x02 card=0x81aa1043 chip=0x816810ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet Note: I haven't testet if_rl, so I don't know how this patch affects that. I'll get back with a note on stability sometime next week (after I have done losts of data transfers to and from this box). -- Regards, Torfinn Ingolfsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: System hanging during dump
On Sun, Nov 02, 2008 at 07:37:05PM +1100, Peter Jeremy wrote:
> Sorry for the late reply.
>
> On 2008-Oct-19 11:39:02 +0300, Kostik Belousov <[EMAIL PROTECTED]> wrote:
> >> I have built myself a looping 'ps -axl' which should let me gather more
> >> information if it does re-appear. (In the process, I've found that ps
> >> leaks memory, though that's not a problem until you wrap it in a loop).
> >
> >What memory ? Kernel one ? How did you noted this ? Could you add
> >vmstat -z and vmstat -m to the loop and watch what allocation grows ?
>
> ps(1) malloc's memory and doesn't free it. This isn't an issue in
> normal operation because it's a once-through program. I hacked ps to
> turn the guts of main() into a while(1){} loop and this showed the
> process was growing. There were a couple of superfluous strdup()
> calls that could be removed but I don't think it's worth making it
> exhaustively clean up after itself (my hacking included hard-wiring
> the options so I'm not sure my cleanup code is complete in the general
> case). As a low priority, I'll create a PR covering the strdup's.
Thank you for clarification. Please, Cc: me with a PR, I will look at it.
pgpnNUoWAEnkk.pgp
Description: PGP signature
Re: Install issues with 7.x
On Wed, 29 Oct 2008, Ryan wrote: Hello, I purchased a new Clevo M860TU on the account that it ran linux very well and was hoping it would fair the same on FreeBSD. Not so much, little help? I posted this in mobile originally but though stable would be a better choice. Don't know if it is more appropriate here or ACPI. I'm giving you as much information as I know how to get. as I cannot get sysinstall to load I am having to type all these dmesg. The boot process is hanging. This is all with 7.x, I can give 6.x if needed. xpt_config is the CAM configuration wait, so basically the system is waiting for a storage device to report back on whether it could be used as a root file system. I recently saw a similar report of problems involving a firewire controller on an nvidia motherboard following an upgrade to 7.x, and I wonder if you might try the following: see if 6.4 will install, and if so, install it. Then cvsup 7.x, and do a buildworld but not an installworld. This will let you build and experiment with 7.x kernels from a known-working environment. Make sure to keep a working 6.x kernel around -- I suggest something like "cp -r /boot/kernel /boot/kernel.good" before starting so you can always fall back to a good kernel. Now try building a 7.x kernel without USB or firewire support, and booting that? Also, it's worth checking there are no BIOS upgrades available for the motherboard... Robert N M Watson Computer Laboratory University of Cambridge Hardware: Intel P9500 4gb DDR3-1066 Nvidia 9800M GT Atheros AR5006e FreeBSD 7.1-BETA2 These snippets of dmesg happen around the end where it hangs. 1. Default ... cpu0: on acpi0 ACPI Error (dsopcode-0350): No pointer back to NS node in buffer obj 0xc6a02d40 [20070320] ACPI Exception (dswexec-0556): AE_AML_INTERNAL, While resolving operands for [OpcodeName unavailable] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\_PR_.CPU0._OSC] (Node 0xc68556e0), AE_AML_INTERNAL est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 ACPI Error (dsopcode-0350): No pointer back to NS node in buffer obj 0xc6a0e300 [20070320] ACPI Exception (dswexec-0556): AE_AML_INTERNAL, While resolving operands for [OpcodeName unavailable] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\_PR_.CPU1._OSC] (Node 0xc685560), AE_AML_INTERNAL est1: on cpu1 p4tcc1: on cpu1 ... cpu0: Cx states changed cpu1: Cx states changed unknown: timeout waiting for read DRQ unknown: timeout waiting for read DRQ acd0: DVDR at ata3-master UDMA33 GEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_Install run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config Then just stalls 2. No ACPI ... unknown: timeout waiting for read DRQ unknown: timeout waiting for read DRQ acd0: DVDR at ata3-master UDMA33 GEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_Install run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config Then just stalls 3. Safe Mode I can only tell you a little because console is spammed. It is the same as no ACPI, but with an interrupt storm. ... unknown: timeout waiting for read DRQ unknown: timeout waiting for read DRQ acd0: DVDR at ata3-master UDMA33 GEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_Install run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config When it gets to the unknowns, this is spammed. interrupt storm detected on "irq10:"; throttling interrupt source Other than the interrupt storm spam, it is halted like the others. 4. Single User Mode Same as 1, Default 5. Verbose All I can tell you is what is spammed at the end. acpi: bad write to port 0x080 (32), val hex Where hex is ever increasing and loops when it hits 0xff01. I can also see run_interrupt_driven_hooks message in all the spam. Using some googling if you add the sysctl before boot debug.acpi.block_bad_io=1 it might be of some help. This just leads to a never ending loop of acpi errors - the scroll very fast and difficult to record might I add! ... acpi: bad write to port 0x080 (32),
/stand/sysinstall freezed on FreeBSD 7.1 install
Dear Friends, I try to install FreeBSD 7.1 AMD64 beta 2 in an Intel Core 2 Duo and motherboard MSI 975X Platinum V.2m, but when /stand/sysinstall try to start from the installation CD, the system freezed and don't continue the install process. Anyone know how to solved this problem to install it Thanks and regards, Julian Bolivar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.5-prerelease and if_re - patches needed?
On Sun, Nov 02, 2008 at 12:29:06PM +0100, Torfinn Ingolfsen wrote: > On Sun, 02 Nov 2008 14:09:15 +0900 > Pyun YongHyeon <[EMAIL PROTECTED]> wrote: > > > http://people.freebsd.org/~yongari/re/6.x/README > > > > Hope this helps. > > Yes it does, thanks! > > On boot, trherer is a noticable delay (tens of seconds) after printing > these lines: > re0: Ethernet> port 0xee00-0xeeff mem 0xfdfff000-0xfdff irq 19 at device 0.0 > on pci2 > re0: turning off MSI enable bit. > re0: Chip rev. 0x3800 > re0: MAC rev. 0x > > The original didn't have that delay. I've changed to have re(4) wait the completion of DMAable memory allocation during bus_dma cleanups. The delay you've seen may be related with that change. Previously it just failed to load the driver if there is no available memory at the time of driver loading. However I guess that delay wouldn't happen if the driver is statically linked into kernel. Did you use kernel module? In theory PCIe variants of RealTek controllers would work with DAC so I could alleviate memory allocation restrictions imposed by bus_dma by allowing 64bits DMA addressing. Since I don't have PCIe based RealTek controllers and no datasheets are available for PCIe based controllers it's somewaht difficult to chage current allocation restrictions. > Otrher than that it works much better. Details: > [EMAIL PROTECTED] uname -a > FreeBSD kg-vm.kg4.no 6.4-PRERELEASE FreeBSD 6.4-PRERELEASE #3: Sun Nov 2 > 10:44:32 CET 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP amd64 > [EMAIL PROTECTED] pciconf -lv | grep re0 -A 4 > [EMAIL PROTECTED]:0:0: class=0x02 card=0x81aa1043 chip=0x816810ec > rev=0x01 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > > Note: I haven't testet if_rl, so I don't know how this patch affects that. rl(4) has a single change to build with updated if_rlreg.h and I don't think that would affect any stability of rl(4). > I'll get back with a note on stability sometime next week (after I have done > losts of data transfers to and from this box). Ok. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can not wake on lan after halt -p (or shutdown -p now) on releng_7 and releng_7_0
On Tue, Oct 14, 2008 at 03:44:56PM +0900, To Georgi Iovchev wrote: > On Fri, Oct 10, 2008 at 11:43:26AM +0300, Georgi Iovchev wrote: > > > > > > -- > > Friday, October 10, 2008, 4:20:58 AM: > > > > > On Mon, Oct 06, 2008 at 06:13:34PM +0300, Georgi Iovchev wrote: > > >> Hello list > > >> > > >> I have a shutdown problem. I have a machine with gigabyte GA-G33M-DS2R > > >> motherboard. Integrated network card is Realtek 8111B. > > >> I can not wake the computer after I shutdown it from FreeBSD. > > >> It is a dualboot system - windows xp and freebsd. If I shutdown the > > >> computer from windows - later I can wake it up with magic packet. Even > > >> if i shutdown the machine on the boot menu with the power button - > than > > >> later I can wake on lan. The only situation where I CANNOT wake it is > > >> when I shutdown the machine from freebsd (halt -p). > > >> > > >> First I tested with 7.0-RELEASE-p5 amd64 (RELENG_7_0) and than I > > >> upgraded to 7.1 PRERELASE amd64 (RELENG_7). I also tested with two > > >> network cards - the integrated one Realtek 8111B and another one Intel > > >> PRO1000PT PCI-E with WOL enabled. > > >> > > > > > Don't know WOL issue of em(4) but re(4) should respond to WOL. > > > 7.0-RELEASE had no support for WOL so RELENG_7 or 7.1-PRERELEASE > > > should be used to experiment WOL. > > Now I am using 7.1-prerelase > > > > >> With both nics and both freebsd versions the situation is the same - > > >> after shutdown from bsd the computer is not able to wake on lan. The > > > > > Because you can wake up your sytem from Windows shutdown I think > > > your BIOS is already configured to allow wakeup from WOL. Would > > > you compare ethernet address of re(4) to Winwods? Have you tried to > > > send Magic packets to FreeBSD box? > > I have tried sending magic packets from another bsd machine. I am > > using net/wol. I also tried to send magic packets from windows machine > > using 3 different programs. > > > > > You may also try suspend your box with acpiconf and resume from WOL. > > I cant. > > > > [EMAIL PROTECTED] ~]# acpiconf -s 5 > > acpiconf: invalid sleep type (5) > > > > Actually I cant enter in any sleep state > > [EMAIL PROTECTED] ~]# acpiconf -s 4 > > acpiconf: request sleep type (4) failed: Operation not supported > > [EMAIL PROTECTED] ~]# acpiconf -s 3 > > acpiconf: request sleep type (3) failed: Operation not supported > > [EMAIL PROTECTED] ~]# acpiconf -s 2 > > acpiconf: request sleep type (2) failed: Operation not supported > > [EMAIL PROTECTED] ~]# acpiconf -s 1 > > acpiconf: request sleep type (1) failed: Operation not supported > > > > I am using generic kernel with little modifications, (generally i have > > commented many unused drivers - raid, if_) Acpi is in generic > > kernel now. > > > > I even tried to wake the machine with magic packet after shutdown -h. > > But still no luck. > > > > > > >> indication on the switch port says that after shut down there is > > >> active link. > > >> > > > > > That indicates the controller is alive so it shall respond to WOL > > > if it was correctly configured to receive WOL packets. Have you > > > tried to send Magic packets to FreeBSD box? > > > > >> Here is some information after last update: > > >> > > >> [EMAIL PROTECTED] ~]# uname -a > > >> FreeBSD backup.pulsar.bg 7.1-PRERELEASE FreeBSD > > >> 7.1-PRERELEASE #1: Mon Oct 6 17:01:26 EEST 2008 > > >> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYCONF amd64 > > >> > > >> [EMAIL PROTECTED] ~]# pciconf -lv > > >> ... > > >> [EMAIL PROTECTED]:3:0:0: class=0x02 card=0xe0001458 > > >> chip=0x816810ec rev=0x01 hdr=0x00 > > >> vendor = 'Realtek Semiconductor' > > >> device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > > >> class = network > > >> subclass = ethernet > > >> ... > > > > > Show me dmesg output pertinent to re(4). > > > > re0: Ethernet> port 0xd000-0xd0ff mem 0xf200-0xf2000fff irq 17 at device 0.0 > on pci3 > > re0: turning off MSI enable bit. > > re0: Chip rev. 0x3800 > > re0: MAC rev. 0x > > miibus0: on re0 > > rgephy0: PHY 1 on miibus0 > > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > > re0: Ethernet address: 00:1f:d0:24:19:e9 > > re0: [FILTER] > > > > It looks like your chip is RTL8168B and I don't see any errors in > WOL related code of re(4). :-( > Can you check the resolved link speed/duplex of FreeBSD box after > shutdown?(You can enter to your switch menu and see the port > status.) > How about sending WOL packets over direct-connected UTP cable > without using switch? > Here is WOL patch which may fix the issye. Would you try the following patch and let me know whether WOL works o
installworld chflags failures
i386, fresh cvsup FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #14: Sun Nov 2 12:13:46 GMT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PSG i386 single luser mode over serial console :/usr/src# time make installworld 2>&1 > installworld.log install: /usr/lib/libkse.so.3: chflags: Operation not supported install: /usr/lib/librt.so.1: chflags: Operation not supported chflags: /usr/bin/chpass: Operation not supported install: /usr/bin/login: chflags: Operation not supported install: /usr/bin/opieinfo: chflags: Operation not supported install: /usr/bin/opiepasswd: chflags: Operation not supported chflags: /usr/bin/passwd: Operation not supported install: /usr/bin/rlogin: chflags: Operation not supported install: /usr/bin/rsh: chflags: Operation not supported install: /usr/bin/su: chflags: Operation not supported install: /usr/bin/crontab: chflags: Operation not supported install: /usr/sbin/sliplogin: chflags: Operation not supported this is new and different, and i am worried. no clue in UPDATING. no clue in head. randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: installworld chflags failures
On Mon, Nov 03, 2008 at 03:46:07PM +0900, Randy Bush wrote: > i386, fresh cvsup > > FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #14: Sun Nov 2 12:13:46 > GMT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PSG i386 > > single luser mode over serial console > > :/usr/src# time make installworld 2>&1 > installworld.log > install: /usr/lib/libkse.so.3: chflags: Operation not supported > install: /usr/lib/librt.so.1: chflags: Operation not supported > chflags: /usr/bin/chpass: Operation not supported > install: /usr/bin/login: chflags: Operation not supported > install: /usr/bin/opieinfo: chflags: Operation not supported > install: /usr/bin/opiepasswd: chflags: Operation not supported > chflags: /usr/bin/passwd: Operation not supported > install: /usr/bin/rlogin: chflags: Operation not supported > install: /usr/bin/rsh: chflags: Operation not supported > install: /usr/bin/su: chflags: Operation not supported > install: /usr/bin/crontab: chflags: Operation not supported > install: /usr/sbin/sliplogin: chflags: Operation not supported > > this is new and different, and i am worried. no clue in UPDATING. no > clue in head. Sounds like kern.securelevel is biting you, or possibly some very odd filesystem mounting flags. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: installworld chflags failures
Jeremy Chadwick wrote: > On Mon, Nov 03, 2008 at 03:46:07PM +0900, Randy Bush wrote: >> i386, fresh cvsup >> >> FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #14: Sun Nov 2 12:13:46 >> GMT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PSG i386 >> >> single luser mode over serial console >> >> :/usr/src# time make installworld 2>&1 > installworld.log >> install: /usr/lib/libkse.so.3: chflags: Operation not supported >> install: /usr/lib/librt.so.1: chflags: Operation not supported >> chflags: /usr/bin/chpass: Operation not supported >> install: /usr/bin/login: chflags: Operation not supported >> install: /usr/bin/opieinfo: chflags: Operation not supported >> install: /usr/bin/opiepasswd: chflags: Operation not supported >> chflags: /usr/bin/passwd: Operation not supported >> install: /usr/bin/rlogin: chflags: Operation not supported >> install: /usr/bin/rsh: chflags: Operation not supported >> install: /usr/bin/su: chflags: Operation not supported >> install: /usr/bin/crontab: chflags: Operation not supported >> install: /usr/sbin/sliplogin: chflags: Operation not supported >> >> this is new and different, and i am worried. no clue in UPDATING. no >> clue in head. > > Sounds like kern.securelevel is biting you, exactly. but in single user root? i thought that was not supposed to happen. certainly did not use to happen. randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: installworld chflags failures
On Mon, Nov 03, 2008 at 04:00:01PM +0900, Randy Bush wrote: > Jeremy Chadwick wrote: > > On Mon, Nov 03, 2008 at 03:46:07PM +0900, Randy Bush wrote: > >> i386, fresh cvsup > >> > >> FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #14: Sun Nov 2 12:13:46 > >> GMT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PSG i386 > >> > >> single luser mode over serial console > >> > >> :/usr/src# time make installworld 2>&1 > installworld.log > >> install: /usr/lib/libkse.so.3: chflags: Operation not supported > >> install: /usr/lib/librt.so.1: chflags: Operation not supported > >> chflags: /usr/bin/chpass: Operation not supported > >> install: /usr/bin/login: chflags: Operation not supported > >> install: /usr/bin/opieinfo: chflags: Operation not supported > >> install: /usr/bin/opiepasswd: chflags: Operation not supported > >> chflags: /usr/bin/passwd: Operation not supported > >> install: /usr/bin/rlogin: chflags: Operation not supported > >> install: /usr/bin/rsh: chflags: Operation not supported > >> install: /usr/bin/su: chflags: Operation not supported > >> install: /usr/bin/crontab: chflags: Operation not supported > >> install: /usr/sbin/sliplogin: chflags: Operation not supported > >> > >> this is new and different, and i am worried. no clue in UPDATING. no > >> clue in head. > > > > Sounds like kern.securelevel is biting you, > > exactly. but in single user root? i thought that was not supposed to > happen. certainly did not use to happen. Did you reboot into single-user, or did you simply drop from multi-user into single-user by killing init? And what does "sysctl kern.securelevel" show you while in single-user mode? -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: installworld chflags failures
> Did you reboot into single-user, or did you simply drop from > multi-user into single-user by killing init? rebooted and was in out of band on serial console > And what does "sysctl kern.securelevel" show you while in single-user > mode? doh. i shoulda looked, eh? Enter full pathname of shell or RETURN for /bin/sh: id: not found grep: not found :/> sysctl kern.securelevel kern.securelevel: -1 :/> /etc/rc.d/hostid start Setting hostuuid: 6b70e4ac-874d-11dc-873e-003048293754. Setting hostid: 0x5ef5842d. :/> /etc/rc.d/zfs start :/> sysctl kern.securelevel kern.securelevel: -1 :/> cd /usr/src :/usr/src> bash :/usr/src# time make installworld 2>&1 > installworld.log install: /usr/lib/libkse.so.3: chflags: Operation not supported install: /usr/lib/librt.so.1: chflags: Operation not supported chflags: /usr/bin/chpass: Operation not supported install: /usr/bin/login: chflags: Operation not supported install: /usr/bin/opieinfo: chflags: Operation not supported install: /usr/bin/opiepasswd: chflags: Operation not supported chflags: /usr/bin/passwd: Operation not supported install: /usr/bin/rlogin: chflags: Operation not supported install: /usr/bin/rsh: chflags: Operation not supported install: /usr/bin/su: chflags: Operation not supported install: /usr/bin/crontab: chflags: Operation not supported install: /usr/sbin/sliplogin: chflags: Operation not supported real2m7.290s user0m30.610s sys 0m40.766s :/usr/src# sysctl kern.securelevel kern.securelevel: -1 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: installworld chflags failures
On Mon, Nov 03, 2008 at 04:18:47PM +0900, Randy Bush wrote: > > Did you reboot into single-user, or did you simply drop from > > multi-user into single-user by killing init? > > rebooted and was in out of band on serial console > > > And what does "sysctl kern.securelevel" show you while in single-user > > mode? > > doh. i shoulda looked, eh? > > > > Enter full pathname of shell or RETURN for /bin/sh: > id: not found > grep: not found > :/> sysctl kern.securelevel > kern.securelevel: -1 > :/> /etc/rc.d/hostid start > Setting hostuuid: 6b70e4ac-874d-11dc-873e-003048293754. > Setting hostid: 0x5ef5842d. > :/> /etc/rc.d/zfs start > :/> sysctl kern.securelevel > kern.securelevel: -1 > :/> cd /usr/src > :/usr/src> bash > :/usr/src# time make installworld 2>&1 > installworld.log > install: /usr/lib/libkse.so.3: chflags: Operation not supported > install: /usr/lib/librt.so.1: chflags: Operation not supported > chflags: /usr/bin/chpass: Operation not supported > install: /usr/bin/login: chflags: Operation not supported > install: /usr/bin/opieinfo: chflags: Operation not supported > install: /usr/bin/opiepasswd: chflags: Operation not supported > chflags: /usr/bin/passwd: Operation not supported > install: /usr/bin/rlogin: chflags: Operation not supported > install: /usr/bin/rsh: chflags: Operation not supported > install: /usr/bin/su: chflags: Operation not supported > install: /usr/bin/crontab: chflags: Operation not supported > install: /usr/sbin/sliplogin: chflags: Operation not supported Is /usr a ZFS filesystem or part of a zpool? If so, possibly you have some ZFS settings on your pool or filesystem which are inhibiting the ability to use chflags in some way? "zfs get all" will help. Otherwise, I don't have any immediate ideas. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
