Freebsd failure to boot from CD on HO Pavillion ze4600
Greetings, I've got an HP Pavillion ze4610us laptop. I've burned a number of FreeBSD 5 (and FreeSBIE 1.1) images to cd, and have had no luck getting this system to boot from them. The same images boot on other systems, and the laptop in question boots WinXP CDs just fine. I'm stumped, and nearly ready to punt the whole deal, but thought I'd ask if anyone has seen similar behavior and figured out what to do about it. Behavior is that after the boot rom splash (the hp/invent logo), the cdrom spins mightily, the cdrom light emits the barest of flickers, and the system proceeds to attempt PXE. Cheers! -sam ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HOWTO write udf (on cd/dvd/hd wherever)
Date:Tue, 29 Nov 2005 08:49:15 +0100 From:arden [EMAIL PROTECTED] im confused do you want to mount a udf cd in a drive or want to make a udf iso ? Neither. I want to write a UDF filesystem on a hard drive at the end of a USB so that I can backup files on one system into an archive file ( tar, dump, cpio, whatever) and store them away on another system. Date:Tue, 29 Nov 2005 00:45:00 +0100 From:Roland Smith [EMAIL PROTECTED] Using dvd+rw-tools for burning backups on single-layer (4GB) disks works fine. You don't really need UDF for that. These archives can get rather large. Compressed, even, they are running about 35-45 GBytes. This is too big for FAT32, and ISO9660 (I think). Neither ext2fs, ufs, ntfs or hfs+ has a solid implementation on much other than its native platform. And I don't know where they will end up. So, a filesystem that is supported by many systems is needed. UDF was designed for that, and seems to work. I just need to be able to write the format from my main server, and I wanted to use FreeBSD for that, as its USB auto- magic seems to be better than most other unixen. Date:Tue, 29 Nov 2005 00:45:00 +0100 From:Roland Smith [EMAIL PROTECTED] I couldn't find a newfs_udf on 6.0, although there is a userspace implementation called UDFclient: http://www.13thmonkey.org/udfclient/ As I understand it, UDF is an extension of ISO9660. An explanation of UDF can be found here: http://homepage.mac.com/wenguangwang/myhome/udf.html Dvd+rw-tools uses ISO9660, not UDF. Using dvd+rw-tools for burning backups on single-layer (4GB) disks works fine. You don't really need UDF for that. Date:Tue, 29 Nov 2005 00:48:24 +0100 From:Wojciech Puchar [EMAIL PROTECTED] thats what i used. RS As I understand it, UDF is an extension of ISO9660. An explanation of no it is not an extension. RS UDF can be found here: http://homepage.mac.com/wenguangwang/myhome/udf.html RS RS Dvd+rw-tools uses ISO9660, not UDF. dvd+rw-tools do't use any filesystem! they just write to device. Date:Tue, 29 Nov 2005 01:14:56 +0100 From:Roland Smith [EMAIL PROTECTED] WP no it is not an extension. http://en.wikipedia.org/wiki/Universal_Disk_Format It [UDF] is an implementation of the ISO/IEC 13346 standard (also known as ECMA-167), and an extension of ISO 9660. And (somewhat paraphrased): A variable-length 'packet-written' CD-R(W) can be closed to a ISO9660 format by writing just by writing a table of contents on the CD. WP dvd+rw-tools do't use any filesystem! they just write to device. I beg to differ. Growisofs is a front-end for mkisofs, combined with a DVD recording program. See the growisofs manual page. Date:Tue, 29 Nov 2005 11:42:38 +0100 From:Wojciech Puchar [EMAIL PROTECTED] RS It [UDF] is an implementation of the ISO/IEC 13346 standard (also known as RS ECMA-167), and an extension of ISO 9660. not true. RS A variable-length 'packet-written' CD-R(W) can be closed to a ISO9660 RS format by writing just by writing a table of contents on the CD. you can just add ISO9660 filesystem metadata, getting two different filesystems of which both's metadata puts to the same place so data is shared, getting more portable disc. and getting faster access to files as UDF isn't as efficient. but UDF is NOT an ISO9660 extension. UDF can live without ISO9660 filesystem at all. if you used UDF programs in windoze, they all have option to add ISO9660 filesystem (just generate metadata) and fixate - after whole disc is filled with data. Well, ISC/IEC 13346 is an extension of ISO 9660 in that is does more. It even has some of the same data structures and nomenclature. It's even reasonable to use the same program to master RO versions of 13346. And UDF is a subset of ISO/IEC 13346. But UDF is a subset with meaning above and beyond ISO/IEC 13346. It's designed to be used as a real filesystem. see: http://www.osta.org/technology/di.htm At any rate, mkisofs will not suffice, as it makes a static filesystem. I need to create a filesystem in the UNIX sense, an empty one that I can then write in. And moreover, from the mkisofs man page: -udf Include UDF support in the generated filesystem image. UDF sup- port is currently in alpha status and for this reason, it is not possible to create UDF only images. UDF data structures are currently coupled to the Joliet structures, so there are many pitfalls with the current implementation. There is no UID/GID support, there is no POSIX permission support, there is no sup- port for symlinks. Note that UDF wastes the space from sector ~20 to sector 256 at the beginning of the disk in addition to the spcae needed for real UDF data structures. In summary, FreeBSD doesn't seem to have a mechanism to create an empty UDF on a medium, though it can probably read one. I'll do some
HOWTO write udf (on cd/dvd/hd wherever)
I see mount_udf(8), and I see many mentions of dvd+rw-tools, and growisofs. Bud I don't see any mention of a method of writing a UDF? Am I missing something? Ultimately, I want to write UDF to a hard drive at the end of a USB so that I can mount it elsewhere. Clues? pointers? slaps in the face for not looking in the right place first? Cheers! -sam ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HOWTO write udf (on cd/dvd/hd wherever)
Date: Mon, 28 Nov 2005 21:46:50 +0100 (CET) From: Wojciech Puchar [EMAIL PROTECTED] I see mount_udf(8), and I see many mentions of dvd+rw-tools, and growisofs. tried to use mount_udf - no success. can't even mount dvd+rw that was treated with newfs_udf (which works) I don't see newfs_udf on my 5.3 system. Searching the manpages turns up only mount_udf. http://www.freebsd.org/search/ finds only relnotes and those are hitting on newfs and udf (apparently ignoring the _ in the newfs_udf, and making that two words). My Solaris 10 system has newfs_udf and mount_udf. I'll see if freebsd can mount the udf created by Solaris, and report back. Cheers! -sam ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
reading fdisk partitioned drives ct from Sparc64
Greetings, I'm trying to read data from a USB/Firewire drive. The drive was formatted on a WinXP system with an NTFS. I'm having numerous difficulties, and am wondering if I should just go and buy a cheap PC chassis before continuing. Problem one: Though (with usbd running) the kernel is aware of my USB card: ohci0: NEC uPD 9210 USB controller mem 0x4000-0x4fff at device 3.0 on pci2 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0 usb0: NEC uPD 9210 USB controller on ohci0 usb0: USB revision 1.0 uhub0: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: NEC uPD 9210 USB controller mem 0x6000-0x6fff at device 3.1 on pci2 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0 usb1: NEC uPD 9210 USB controller on ohci1 usb1: USB revision 1.0 uhub1: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ehci0: NEC uPD 720100 USB 2.0 controller mem 0x8000-0x80ff at device 3.2 on pci2 ehci0: [GIANT-LOCKED] ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 usb2: EHCI version 0.95 usb2: companion controllers, 3 ports each: usb0 usb1 usb2: NEC uPD 720100 USB 2.0 controller on ehci0 usb2: USB revision 2.0 uhub2: NEC EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 5 ports with 5 removable, self powered uhub2: device problem, disabling port 3 umass isn't firing up. umass will load (manually), but is not autoloaded, and no umass instance pops up in dmesg. # kldstat Id Refs AddressSize Name 15 0xc000 4923e8 kernel 22 0xc090 14 usb.ko 31 0xc0a4a000 10a000 umass.ko 41 0xc0b54000 10e000 ntfs.ko So, yank the usb cable, and install the firewire. This moves along... fwohci0: BUS reset fwohci0: node_id=0xc800ffc1, gen=2, CYCLEMASTER mode firewire0: 2 nodes, maxhop = 1, cable IRM = 1 (me) firewire0: bus manager 1 (me) fwohci0: BUS reset fwohci0: node_id=0xc800ffc1, gen=3, CYCLEMASTER mode fwohci0: txd err= 0 No stat firewire0: 2 nodes, maxhop = 1, cable IRM = 1 (me) firewire0: bus manager 1 (me) firewire0: New S400 device ID:0010b92100603efb da0 at sbp0 bus 0 target 0 lun 0 da0: Maxtor OneTouch II 030d Fixed Direct Access SCSI-4 device da0: 50.000MB/s transfers da0: 194481MB (398297088 512 byte sectors: 255H 63S/T 24792C) Cool, so now I've a disk. But that doesn't really help... # ls /dev/da* /dev/da0 Nothing that would look like something to mount. And indeed, # mount_ntfs -o ro /dev/da0 /mnt mount_ntfs: /dev/da0: Invalid argument Am I just barking up the wrong tree, here. Does the endian issue preclude the da driver from seeing fdisk-style partitions on Sparc64? If not, what might help mount_ntfs see a device. Then again, do endian issues preclude ntfs from operating on Sparc64? And lastly, referring to all of those USB devices referenced at: http://www.freebsd.org/releases/5.3R/hardware-i386.html#USB and their absence at: http://www.freebsd.org/releases/5.3R/hardware-sparc64.html#USB Do they really not work on Sparc64, or just haven't been tested? Cheers! -sam ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
gbde on gmirror supported?
Greetings, I have two drives (3 parts each) mirrored with gmirror. System performs as advertized. dna# gmirror label -v -b load hgsa da2 da3 Metadata value stored on da2. Metadata value stored on da3. Done. dna# ls /dev/mirror hgsahgsaa hgsac hgsas1 hgsas1c hgsas1d hgsas1e hgsas1f dna# newfs /dev/mirror/hgsas1d /dev/mirror/hgsas1d: 36864.0MB (75497472 sectors) block size 16384, fragment size 2048 using 201 cylinder groups of 183.77MB, 11761 blks, 23552 inodes. super-block backups (for fsck -b #) at: 160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976, 3387328, 3763680, ... Great, so now I'd like to use gbde on hgas1f. dna# gbde init /dev/mirror/hgsas1f -L /etc/hgsas1f.lock Enter new passphrase: Reenter new passphrase: dna# gbde attach mirror/hgsas1f -l /etc/hgsas1f.lock Enter passphrase: dna# So everything *seems* cool, but... dna# ls /dev/mirror/hgsas1f /dev/mirror/hgsas1f dna# ls /dev/mirror/hgsas1f.bde ls: /dev/mirror/hgsas1f.bde: No such file or directory dna# ls /dev/mirror hgsahgsas1 hgsas1c hgsas1d hgsas1e hgsas1f dna# ls /dev/*bde zsh: no matches found: /dev/*bde Should this have worked? Did I miss something obvious? obscure? Thanks, -sam ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel: Panic problem with TCPDUMP
From: Guthemberg Silvestre [EMAIL PROTECTED] Date: Tue, 30 Mar 2004 13:46:06 -0300 Hi everyone, I'm using the FreeBSD 5.2(FreeBSD 5.2-RELEASE #0: Sun Jan 11 04:21:45 GMT 2004),default installation, to collect packets with TCPDUMP. The computer has: - CPU: AMD Athlon(tm) XP 2400+ (2004.56-MHz 686-class CPU) - real memory = 536805376 (511 MB) - rl0: RealTek 8139 10/100BaseTX port 0xd400-0xd4ff mem 0xdfffbf00-0xdfffbfff irq 18 at device 8.0 on pci0, etc. The problem is when I start the program TCPDUMP to collect the packets from a 32Mb/s link (at the rl0 interface). After some time, the following log error messages appear: Mar 30 11:29:22 p2p kernel: panic: vm_fault: fault on nofault entry, addr: e0aae000 Mar 30 11:29:22 p2p kernel: cpuid = 0; Mar 30 11:29:22 p2p kernel: Mar 30 11:29:22 p2p kernel: syncing disks, buffers remaining... 3842 3842 3842 3842 3842 3842 3842 3842 3842 3842 3842 3842 3842 3842 3842 38 42 3842 3842 3842 3842 You don't by any chance have a Shuttle Xpc do you? Those are very similar dmesg lines to my Xpc. I have found that the memory boards are woefully undercooled in this box. I experimented with many coverings of the vent holes to increase the pressures near the front where the memory resides. Eventually I wedged a fan inside and aimed it along the two dimms. Runs fine now. Before that I had the *same* results as you whenever I ran software that exercised dma to disk, net, whatever. Which meant that the system often crashed the first time I read mail... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: about Ultra-sparc and alpha: what makes the difference?
Date: Wed, 31 Mar 2004 01:27:51 +0800 From: Zhang Weiwu [EMAIL PROTECTED] Hello. The question sounds really silly, but google with compare sparc i386 alpha / benchmark sparc i386 alpha doesn't give meaningful result in several pages. Please suggest me a better keyword compilation:) How about this instead: Sparc (UltraSparc) A 32(64) bit processor designed by Sun Microsystems to advance beyond the Motorola 68040. Chips made by TI, Fujitsu, and perhaps others. www.sparcinternational.com Alpha, A 64 bit processor designed by Digital to advance beyond the VAX architecture. Digital, bought by Compaq, merged into HP. Chips made by Samsung (only, I think) www.alpha-processor.com (which may no longer work) FreeBSD runs on them all, multi-processor. They are more expensive primarily due to their lower volumes and the desire of their manufacturers to not enter low-margin markets. As a result, there is more money per computer to manufacture hi-quality enclosures. But this can be done with x86 systems, of course. -sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BGP On Host
It's a reasonable way to perform certain kinds of replication. DDNS can often converge faster than BGP, but this *requires* that clients observe TTLs. Many do not. I don't know about current browsers, but not too long ago browsers would keep the results of a DNS lookup until they died. We offer a replication service (as a special) based on BGP. We do not recommend it unless the DDNS approach will not meet requirements. And then we work to find alternatives! To do it yourself is rather simple (Catbert's grin here.) First. Find a collection of ISPs that will agree to accept your BGP4 announcements of this foreign (to all save perhaps one ISP) AS. Oh, get an AS #. Then get someone to assign you some address space that can be so advertised. If you're lucky you have a spare /19 in your back pocket. :) After that it's *easy*. OK, I'm being cute. Some large ISPs will work with you to do this wholly in their diverse facilities with private AS numbers and address space they have reserved for this. AFAIK, the last free version of gated will work for IPv4 versions of this approach. And that runs on FreeBSD. -sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Installing FreeBSD 5.2 on a COMPAQ Proliant Server
From: Gennady Levine [EMAIL PROTECTED] Date: Thu, 18 Mar 2004 10:45:13 +1300 I'm trying to install FreeBSD 5.2 on a compaq proliant dual P-Pro-200MHz server but can't even get the install cd to boot properly, it hangs during the boot with the following error: ida0: Compaq SMART-2/E array controller... panic: vm_fault: fault on nofault entry, addr: c327f000 cpuid=0 Just had a similar problem. I'm not at all sure that we have the same problem, as I don't have the smartarray controller. But I was advised (on this list, check recent archives to and from me) to use the SmartStart CD and reset the OS to linux. Not having a SmartStart CD, I d/led the sys config util from HP and used that to reset the bios. *Then* I had to use the same kit to say the next thing I'm going to do after a reboot is install a new OS. Else, no matter how I held my head or which creative invectives I used, the system would hang/panic just after probing the internal SCSI controllers. -sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Booting Compaq 1850R WasRe: 5.2.1 miniinst cd panic during 3rd phase boot (kernel start).
From: [EMAIL PROTECTED] Date: Fri, 12 Mar 2004 13:29:51 -0500 Date: Thu, 11 Mar 2004 15:47:32 +0100 From: kybu [EMAIL PROTECTED] SCN I haven't seen anything in the PR list or -questions just like this. SCN My Compaq 1850 (2x PII-450, 1GByte Ram) boots up the 5.2.1-release SCN miniinst cdrom just fine, loads the kenel, and just after waiting SCN for SCSI devices to settle, panics. SCN It does this with or without devices on the scsi bus. SCN Anyone else have one of these critters working with 5.x? Otherwise, SCN anyone else have the same/a similar symptom? Yeah, I got similar problem on Compaq 1650. I just change the OS system type with SmartStart CD to Linux and then it works fine. Thanks, it almost worked...At least I got past discovering disks. Now, when booting, it goes past discovering disks, and indicates /stand/sysinstall is starting on vty0. After that no joy. I'm thinking that the vga or keyboard isn't jiving with the vty system, and that it is running fine, but not where I can see it. Well, the config utility was indeed the key. Turned out that after I booted from the utility partition, which is created with the config utility http://h18023.www1.hp.com/support/files/server/us/download/13227.html, and selected the install OS - other the system stopped, then the freebsd install completed without a hitch. -sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing (scsi) drives at particular /dev locations
Date: Sun, 7 Mar 2004 11:59:43 + From: Matthew Seaman [EMAIL PROTECTED] hint.da.0.at=ahc1 Close, but no cigar. See the section on SCSI DEVICE CONFIGURATION in /usr/src/sys/conf/NOTES. What you want is: hint.scbus.0.at=ahc1 hint.scbus.1.at=ahc0 hint.da.0.at=scbus0 hint.da.0.target=0 hint.da.0.unit=0 which swaps the ordering of the SCSI busses, and wires down da0 to bus 0, target 0, LUN 0. You could probably get away with just the first two lines, as the rest should be the default anyhow. I went looking in /usr/src/sys/i386/conf instead, oops! What threw me though was there was no scbus identified in the boot messages. Boot output goes like this: ... da0 at ahc0 bus 0 target 0 lun 0 ... da1 at ahc0 bus 0 target 1 lun 0 ... But I tried what the Good Doctor ordered, and now I feel fine! Thanks!!! -sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Fixing (scsi) drives at particular /dev locations
FreeBSD 5.2.1; Sun/Cobalt LX50; GENERIC kernel Greetings, The darned LX50 is wired with the first SCSI bus out the back, and the second toward the builtin drives. So, upon adding an external drive, the internal drives all renumber with the generic kernel+device hints. I thought adding a line to /boot/device.hints might work, so reading /usr/src/sys/i386/conf/gethints.awk for clues, I added: hint.da.0.at=ahc1 But that didn't have a noticeable effect. Looking again, I probably asked too much from that interface, as I see no examples with ctlr name+numbers to the right of the =. So, how to fix device 0 lun 0 on ahc 1 to be da0? Alternatively how to get /devfs to incorporate the ctlr number in the /dev entry, like: dac1s1a? Thanks, -sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
