Unable to boot 5.x on a Tyan S1836 Dual 333Mhz
I have been unable to boot 5 on this on particular system for several months and I'm at a loss as to what's causing the problem. The problems started right after I updated the BIOS to 1.18.02 from Tyan. Previously I believe it was running 1.16b. Note, that before the BIOS update, the system was able to boot 5-CURRENT w/o a problem. Now, I guess a solution would be to go back to 1.16b (I assume, haven't tried), but I don't understand why this new BIOS isn't working. The thing is, I have an almost identical machine with the same BIOS revision running -CURRENT w/o problems. The biggest difference is that the other machine has an older, ATI Mach64 PCI video card, whereas this one uses an All-In-Wonder Pro. Also, this machine has Windows XP on a separate disk and if I switch to boot from that disk, it boots and runs w/o a problem. Machine specs: Processor: Intel Pentium II 333 Mhz (dual) MP table spec. set to 1.1 motherboard: Tyan Thunder 100 S1836 (onboard ethernet, sound, ATA and SCSI) RAM: two 128 MB PC-100 DIMMs, for a total of 256 MB of RAM Disk: two SCSI drives, each on separate SCSI channels, attached to the motheboards internal AIC-7895 SCSI. One disk is a Wide/40, on channel B and a Fast 20 on Channel A. Also, on channel A there is a Sony DDS3 tape drive. There was a copy of 6 month old -CURRENT on the Fast/20 drive, but through all the experimentation, I am unable to boot from it any longer. Video: ATI All-In-Wonder Pro (Rage2 chipset) 8MB VRAM. Besides the All-In-Wonder, there are no other PCI slots being used. On the motherboard there is built in sound (SB Vibra 16) and ethernet (Intel 82559). I'm using PS/2 kb and mouse. I've tried countless BIOS settings. I've even reset the CMOS to be sure I haven't changed anything. I've tried both the optimal and fail safe AMI BIOS profiles, to no avail. I've tried enabling/disabling ACPI, PnP, APM, SCSI, ATA (normally disabled, since this machine is all-SCSI) USB and Parallel ports. I've changed the scan order of the PCI slots to last-first. None of it makes a difference.. always leading to the boot seen below: Here is a detailed boot log taken from a Serial terminal after using the 5.1-R boot disks (kern and mfsroot) to boot the system. I had to use a serial console, as when it crashes, it scrolls so fast I can't see where it stops. Also, it never hits the kernel debugger. Though, when booting from diskettes is DDB included? Here it goes: OK boot -v SMAP type=01 base= len=0009fc00 SMAP type=02 base=0009fc00 len=0400 SMAP type=02 base=000e len=0002 SMAP type=01 base=0010 len=0ff0 SMAP type=02 base=fec0 len=1000 SMAP type=02 base=fee0 len=1000 SMAP type=02 base=fffc len=0004 Copyright (c) 1992-2003 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 5.1-RELEASE #0: Thu Jun 5 03:08:07 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BOOTMFS Preloaded elf kernel /kernel at 0xc07ec000. Preloaded mfs_root /mfsroot at 0xc07ec1dc. Calibrating clock(s) ... i8254 clock: 1193079 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz Calibrating TSC clock ... TSC clock: 133636927 Hz Timecounter TSC frequency 133636927 Hz CPU: Pentium II/Pentium II Xeon/Celeron (133.64-MHz 686-class CPU) Origin = GenuineIntel Id = 0x633 Stepping = 3 Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,M CA,CMOV,MMX real memory = 268435456 (256 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00813000 - 0x0fb59fff, 255094784 bytes (62279 pages) avail memory = 252334080 (240 MB) bios32: Found BIOS32 Service Directory header at 0xc00fdb40 bios32: Entry = 0xfdb50 (c00fdb50) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xdb71 pnpbios: Found PnP BIOS data at 0xc00f72c0 pnpbios: Entry = f:6964 Rev = 1.0 Other BIOS signatures found: null: null device, zero device mem: memory I/O Pentium Pro MTRR support enabled md0: Preloaded image /mfsroot 4423680 bytes at 0xc03b2cdc npx0: math processor on motherboard npx0: INT 16 interface pci_open(1):mode 1 addr port (0x0cf8) is 0x805c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71a08086) pcibios: BIOS version 2.10 pcib0: Intel 82443GX host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base f800, size 26, enabled found- vendor=0x8086, dev=0x71a0, revid=0x00 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2210, cachelnsz=0 (dwords)
installing kernel with securelevel set to 2
FreeBSD-current@ I just tried installing a kernel after compiling May 31st source and figured I would have to reboot to a lower securelevel, as I'm running with kern.securelevel set to 2. However, it slipped my mind and i've noticed it installed anyhow. Has this behavior changed? I thought that the kernel file (/boot/kernel/kernel) and its modules could not be replaced at that securelevel? Note: I'm currently running an April 6th -CURRENT. Also, all filesystems are UFS1, currently. As you can see, it installed kernel just fine for some reason. In the past, if the machine was running in secure mode it would stop at this point: [...] cd /usr/obj/usr/src/sys/TSERVER; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE=i686 GROFF_BIN_PATH=/usr/obj/usr/src/i386/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/legacy/usr/share/tmac PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/usr/obj/usr/src/i386/ legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games:/usr/obj/usr/src/ i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/ games:/sbin:/bin:/usr/sbin:/usr/bin make KERNEL=kernel install thiskernel=`sysctl -n kern.bootfile` ; if [ $thiskernel = /boot/kernel.old/kernel ] ; then chflags -R noschg /boot/kernel ; rm -rf /boot/kernel ; else if [ -d /boot/kernel.old ] ; then chflags -R noschg /boot/kernel.old ; rm -rf /boot/kernel.old ; fi ; mv /boot/kernel /boot/kernel.old ; if [ $thiskernel = /boot/kernel/kernel ] ; then sysctl kern.bootfile=/boot/kernel.old/kernel ; fi; fi kern.bootfile: /boot/kernel/kernel - /boot/kernel.old/kernel mkdir -p /boot/kernel install -p -m 555 -o root -g wheel kernel /boot/kernel cd /usr/src/sys/modules; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/TSERVER/modules KMODDIR=/boot/kernel MACHINE=i386 make install [...] Looks like it was able to remove the immutable flag w/o a problem, which isn't supposed to be allowed at securelevel 1 or 2. From securelevel(8): 1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted file systems, /dev/mem, and /dev/kmem may not be opened for writing; kernel modules (see kld(4)) may not be loaded or unloaded. 2 Highly secure mode - same as secure mode, plus disks may not be opened for writing (except by mount(2)) whether mounted or not. This level precludes tampering with file systems by unmounting them, but also inhibits running newfs(8) while the system is multi- user. Here's how I checked the securelevel: # sysctl kern.securelevel kern.securelevel: 2 # Also, checking the flags on /boot/kernel/kernel after the make -j2 kernelinstall there appears to be no flags set on the kernel file or any of its modules: # ls -lo /boot/kernel/kernel -r-xr-xr-x 1 root wheel - 3553557 Jun 1 16:24 /boot/kernel/kernel # Odd, no? Is there a new sysctl(8) directive that I'm missing? Maybe its a bug that's been fixed since Apr. 6th. Thanks, -rory ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: installing kernel with securelevel set to 2
I think I answered my own question. The kernel isn't installed with immutable flags to begin with -- So, my question is, why is this? I thought the advantage of making the kernel immutable was to better protect the system if root was compromised? I searched the archives regarding this, but found nothing that related to it. -rory From: Rory Arms [EMAIL PROTECTED] Date: Sun Jun 1, 2003 17:07:53 US/Eastern To: [EMAIL PROTECTED] Subject: installing kernel with securelevel set to 2 X-Mailer: Apple Mail (2.552) FreeBSD-current@ I just tried installing a kernel after compiling May 31st source and figured I would have to reboot to a lower securelevel, as I'm running with kern.securelevel set to 2. However, it slipped my mind and i've noticed it installed anyhow. Has this behavior changed? I thought that the kernel file (/boot/kernel/kernel) and its modules could not be replaced at that securelevel? Note: I'm currently running an April 6th -CURRENT. Also, all filesystems are UFS1, currently. As you can see, it installed kernel just fine for some reason. In the past, if the machine was running in secure mode it would stop at this point: [...] cd /usr/obj/usr/src/sys/TSERVER; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE=i686 GROFF_BIN_PATH=/usr/obj/usr/src/i386/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/legacy/usr/share/tmac PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/usr/obj/usr/src/i386/ legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games:/usr/obj/usr/ src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/ usr/games:/sbin:/bin:/usr/sbin:/usr/bin make KERNEL=kernel install thiskernel=`sysctl -n kern.bootfile` ; if [ $thiskernel = /boot/kernel.old/kernel ] ; then chflags -R noschg /boot/kernel ; rm -rf /boot/kernel ; else if [ -d /boot/kernel.old ] ; then chflags -R noschg /boot/kernel.old ; rm -rf /boot/kernel.old ; fi ; mv /boot/kernel /boot/kernel.old ; if [ $thiskernel = /boot/kernel/kernel ] ; then sysctl kern.bootfile=/boot/kernel.old/kernel ; fi; fi kern.bootfile: /boot/kernel/kernel - /boot/kernel.old/kernel mkdir -p /boot/kernel install -p -m 555 -o root -g wheel kernel /boot/kernel cd /usr/src/sys/modules; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/TSERVER/modules KMODDIR=/boot/kernel MACHINE=i386 make install [...] Looks like it was able to remove the immutable flag w/o a problem, which isn't supposed to be allowed at securelevel 1 or 2. From securelevel(8): 1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted file systems, /dev/mem, and /dev/kmem may not be opened for writing; kernel modules (see kld(4)) may not be loaded or unloaded. 2 Highly secure mode - same as secure mode, plus disks may not be opened for writing (except by mount(2)) whether mounted or not. This level precludes tampering with file systems by unmounting them, but also inhibits running newfs(8) while the system is multi- user. Here's how I checked the securelevel: # sysctl kern.securelevel kern.securelevel: 2 # Also, checking the flags on /boot/kernel/kernel after the make -j2 kernelinstall there appears to be no flags set on the kernel file or any of its modules: # ls -lo /boot/kernel/kernel -r-xr-xr-x 1 root wheel - 3553557 Jun 1 16:24 /boot/kernel/kernel # Odd, no? Is there a new sysctl(8) directive that I'm missing? Maybe its a bug that's been fixed since Apr. 6th. Thanks, -rory ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
