8.1-STABLE: zfs and sendfile: problem still exists
Hi! I've noticed that ZFS on 8.1-STABLE still has problems with sendfile. When accessing a file at first time the transfer speed is too low, but on following attempts the transfer speed is normal. How to repeat: $ dd if=/dev/random of=/tmp/test bs=1m count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 5.933945 secs (17670807 bytes/sec) $ sudo env LC_ALL=C /usr/libexec/ftpd -D The first attempt to fetch file: $ fetch -o /dev/null ftp://localhost/tmp/test /dev/null 1% of 100 MB 118 kBps 14m07s^C fetch: transfer interrupted The transfer rate is too low (approx. 120 kBps), but any subsequent attempts are success: $ fetch -o /dev/null ftp://localhost/tmp/test /dev/null 100% of 100 MB 42 MBps $ fetch -o /dev/null ftp://localhost/tmp/test /dev/null 100% of 100 MB 47 MBps ... To repeat it is enough to copy a file and to try again: $ cp /tmp/test /tmp/test1 $ fetch -o /dev/null ftp://localhost/tmp/test1 /dev/null 2% of 100 MB 119 kBps 13m50s^C fetch: transfer interrupted $ fetch -o /dev/null ftp://localhost/tmp/test1 /dev/null 100% of 100 MB 41 MBps $ fetch -o /dev/null ftp://localhost/tmp/test1 /dev/null 100% of 100 MB 47 MBps ...and again: $ cp /tmp/test1 /tmp/test2 $ fetch -o /dev/null ftp://localhost/tmp/test2 /dev/null 1% of 100 MB 118 kBps 14m07s^C fetch: transfer interrupted $ fetch -o /dev/null ftp://localhost/tmp/test2 /dev/null 100% of 100 MB 41 MBps $ fetch -o /dev/null ftp://localhost/tmp/test2 /dev/null 100% of 100 MB 47 MBps I've tried ftpd and nginx with "sendfile on". The behavior is the same. After disabling using sendfile in nginx ("sendfile off") the problem has gone. -- Alexander Zagrebin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Degraded zpool cannot detach old/bad drive
Thanks Artem, I am mainly concerned about fixing this immediate problem first and then if I can provide more information for the developers so that they look into this problem I'd be happy to. I'll try OpenSolaris live CD and see how it goes. Either way I'll report back here. Cheers, Rumen Telbizov On Wed, Oct 27, 2010 at 5:22 PM, Artem Belevich wrote: > Are you interested in what's wrong or in how to fix it? > > If fixing is the priority, I'd boot from OpenSolaris live CD and would > try importing the array there. Just make sure you don't upgrade ZFS to > a version that is newer than the one FreeBSD supports. > > Opensolaris may be able to fix the array. Once it's done, export it, > boot back to FreeBSD and re-import it. > > --Artem > > > > On Wed, Oct 27, 2010 at 4:22 PM, Rumen Telbizov > wrote: > > No ideas whatsoever? > > > > On Tue, Oct 26, 2010 at 1:04 PM, Rumen Telbizov > wrote: > > > >> Hello everyone, > >> > >> After a few days of struggle with my degraded zpool on a backup server I > >> decided to ask for > >> help here or at least get some clues as to what might be wrong with it. > >> Here's the current state of the zpool: > >> > >> # zpool status > >> > >> pool: tank > >> state: DEGRADED > >> status: One or more devices has experienced an error resulting in data > >> corruption. Applications may be affected. > >> action: Restore the file in question if possible. Otherwise restore the > >> entire pool from backup. > >>see: http://www.sun.com/msg/ZFS-8000-8A > >> scrub: none requested > >> config: > >> > >> NAME STATE READ WRITE CKSUM > >> tank DEGRADED 0 0 0 > >> raidz1 DEGRADED 0 0 0 > >> spare DEGRADED 0 0 0 > >> replacing DEGRADED 0 0 0 > >> 17307041822177798519 UNAVAIL 0 299 0 was > >> /dev/gpt/disk-e1:s2 > >> gpt/newdisk-e1:s2 ONLINE 0 0 0 > >> gpt/disk-e2:s10 ONLINE 0 0 0 > >> gpt/disk-e1:s3ONLINE 30 0 0 > >> gpt/disk-e1:s4ONLINE 0 0 0 > >> gpt/disk-e1:s5ONLINE 0 0 0 > >> raidz1 ONLINE 0 0 0 > >> gpt/disk-e1:s6ONLINE 0 0 0 > >> gpt/disk-e1:s7ONLINE 0 0 0 > >> gpt/disk-e1:s8ONLINE 0 0 0 > >> gpt/disk-e1:s9ONLINE 0 0 0 > >> raidz1 ONLINE 0 0 0 > >> gpt/disk-e1:s10 ONLINE 0 0 0 > >> gpt/disk-e1:s11 ONLINE 0 0 0 > >> gpt/disk-e1:s12 ONLINE 0 0 0 > >> gpt/disk-e1:s13 ONLINE 0 0 0 > >> raidz1 DEGRADED 0 0 0 > >> gpt/disk-e1:s14 ONLINE 0 0 0 > >> gpt/disk-e1:s15 ONLINE 0 0 0 > >> gpt/disk-e1:s16 ONLINE 0 0 0 > >> spare DEGRADED 0 0 0 > >> replacing DEGRADED 0 0 0 > >> 15258738282880603331 UNAVAIL 048 0 was > >> /dev/gpt/disk-e1:s17 > >> gpt/newdisk-e1:s17ONLINE 0 0 0 > >> gpt/disk-e2:s11 ONLINE 0 0 0 > >> raidz1 ONLINE 0 0 0 > >> gpt/disk-e1:s18 ONLINE 0 0 0 > >> gpt/disk-e1:s19 ONLINE 0 0 0 > >> gpt/disk-e1:s20 ONLINE 0 0 0 > >> gpt/disk-e1:s21 ONLINE 0 0 0 > >> raidz1 ONLINE 0 0 0 > >> gpt/disk-e1:s22 ONLINE 0 0 0 > >> gpt/disk-e1:s23 ONLINE 0 0 0 > >> gpt/disk-e2:s0ONLINE 0 0 0 > >> gpt/disk-e2:s1ONLINE 0 0 0 > >> raidz1 ONLINE 0 0 0 > >> gpt/disk-e2:s2ONLINE 0 0 0 > >> gpt/disk-e2:s3ONLINE 0 0 0 > >> gpt/disk-e2:s4ONLINE 0 0 0 > >> gpt/disk-e2:s5ONLINE 0 0 0 > >> raidz1 ONLINE 0 0 0 > >> gpt/disk-e2:s6ONLINE 0 0 0 > >> gpt/disk-e2:s7ONLINE 0 0 0 > >>
Re: Degraded zpool cannot detach old/bad drive
Are you interested in what's wrong or in how to fix it? If fixing is the priority, I'd boot from OpenSolaris live CD and would try importing the array there. Just make sure you don't upgrade ZFS to a version that is newer than the one FreeBSD supports. Opensolaris may be able to fix the array. Once it's done, export it, boot back to FreeBSD and re-import it. --Artem On Wed, Oct 27, 2010 at 4:22 PM, Rumen Telbizov wrote: > No ideas whatsoever? > > On Tue, Oct 26, 2010 at 1:04 PM, Rumen Telbizov wrote: > >> Hello everyone, >> >> After a few days of struggle with my degraded zpool on a backup server I >> decided to ask for >> help here or at least get some clues as to what might be wrong with it. >> Here's the current state of the zpool: >> >> # zpool status >> >> pool: tank >> state: DEGRADED >> status: One or more devices has experienced an error resulting in data >> corruption. Applications may be affected. >> action: Restore the file in question if possible. Otherwise restore the >> entire pool from backup. >> see: http://www.sun.com/msg/ZFS-8000-8A >> scrub: none requested >> config: >> >> NAME STATE READ WRITE CKSUM >> tank DEGRADED 0 0 0 >> raidz1 DEGRADED 0 0 0 >> spare DEGRADED 0 0 0 >> replacing DEGRADED 0 0 0 >> 17307041822177798519 UNAVAIL 0 299 0 was >> /dev/gpt/disk-e1:s2 >> gpt/newdisk-e1:s2 ONLINE 0 0 0 >> gpt/disk-e2:s10 ONLINE 0 0 0 >> gpt/disk-e1:s3 ONLINE 30 0 0 >> gpt/disk-e1:s4 ONLINE 0 0 0 >> gpt/disk-e1:s5 ONLINE 0 0 0 >> raidz1 ONLINE 0 0 0 >> gpt/disk-e1:s6 ONLINE 0 0 0 >> gpt/disk-e1:s7 ONLINE 0 0 0 >> gpt/disk-e1:s8 ONLINE 0 0 0 >> gpt/disk-e1:s9 ONLINE 0 0 0 >> raidz1 ONLINE 0 0 0 >> gpt/disk-e1:s10 ONLINE 0 0 0 >> gpt/disk-e1:s11 ONLINE 0 0 0 >> gpt/disk-e1:s12 ONLINE 0 0 0 >> gpt/disk-e1:s13 ONLINE 0 0 0 >> raidz1 DEGRADED 0 0 0 >> gpt/disk-e1:s14 ONLINE 0 0 0 >> gpt/disk-e1:s15 ONLINE 0 0 0 >> gpt/disk-e1:s16 ONLINE 0 0 0 >> spare DEGRADED 0 0 0 >> replacing DEGRADED 0 0 0 >> 15258738282880603331 UNAVAIL 0 48 0 was >> /dev/gpt/disk-e1:s17 >> gpt/newdisk-e1:s17 ONLINE 0 0 0 >> gpt/disk-e2:s11 ONLINE 0 0 0 >> raidz1 ONLINE 0 0 0 >> gpt/disk-e1:s18 ONLINE 0 0 0 >> gpt/disk-e1:s19 ONLINE 0 0 0 >> gpt/disk-e1:s20 ONLINE 0 0 0 >> gpt/disk-e1:s21 ONLINE 0 0 0 >> raidz1 ONLINE 0 0 0 >> gpt/disk-e1:s22 ONLINE 0 0 0 >> gpt/disk-e1:s23 ONLINE 0 0 0 >> gpt/disk-e2:s0 ONLINE 0 0 0 >> gpt/disk-e2:s1 ONLINE 0 0 0 >> raidz1 ONLINE 0 0 0 >> gpt/disk-e2:s2 ONLINE 0 0 0 >> gpt/disk-e2:s3 ONLINE 0 0 0 >> gpt/disk-e2:s4 ONLINE 0 0 0 >> gpt/disk-e2:s5 ONLINE 0 0 0 >> raidz1 ONLINE 0 0 0 >> gpt/disk-e2:s6 ONLINE 0 0 0 >> gpt/disk-e2:s7 ONLINE 0 0 0 >> gpt/disk-e2:s8 ONLINE 0 0 0 >> gpt/disk-e2:s9 ONLINE 0 0 0 >> spares >> gpt/disk-e2:s10 INUSE currently in use >> gpt/disk-e2:s11 INUSE currently in use >> gpt/disk-e1:s2 UNAVAIL cannot open >> gpt/newdisk-e1:s17 INUSE currently in use >> >> errors: 4 data errors, use '-v' for a list >> >> >> The problem is: after replacing the bad drives and resilveri
Re: Degraded zpool cannot detach old/bad drive
No ideas whatsoever? On Tue, Oct 26, 2010 at 1:04 PM, Rumen Telbizov wrote: > Hello everyone, > > After a few days of struggle with my degraded zpool on a backup server I > decided to ask for > help here or at least get some clues as to what might be wrong with it. > Here's the current state of the zpool: > > # zpool status > > pool: tank > state: DEGRADED > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. >see: http://www.sun.com/msg/ZFS-8000-8A > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > tank DEGRADED 0 0 0 > raidz1 DEGRADED 0 0 0 > spare DEGRADED 0 0 0 > replacing DEGRADED 0 0 0 > 17307041822177798519 UNAVAIL 0 299 0 was > /dev/gpt/disk-e1:s2 > gpt/newdisk-e1:s2 ONLINE 0 0 0 > gpt/disk-e2:s10 ONLINE 0 0 0 > gpt/disk-e1:s3ONLINE 30 0 0 > gpt/disk-e1:s4ONLINE 0 0 0 > gpt/disk-e1:s5ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > gpt/disk-e1:s6ONLINE 0 0 0 > gpt/disk-e1:s7ONLINE 0 0 0 > gpt/disk-e1:s8ONLINE 0 0 0 > gpt/disk-e1:s9ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > gpt/disk-e1:s10 ONLINE 0 0 0 > gpt/disk-e1:s11 ONLINE 0 0 0 > gpt/disk-e1:s12 ONLINE 0 0 0 > gpt/disk-e1:s13 ONLINE 0 0 0 > raidz1 DEGRADED 0 0 0 > gpt/disk-e1:s14 ONLINE 0 0 0 > gpt/disk-e1:s15 ONLINE 0 0 0 > gpt/disk-e1:s16 ONLINE 0 0 0 > spare DEGRADED 0 0 0 > replacing DEGRADED 0 0 0 > 15258738282880603331 UNAVAIL 048 0 was > /dev/gpt/disk-e1:s17 > gpt/newdisk-e1:s17ONLINE 0 0 0 > gpt/disk-e2:s11 ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > gpt/disk-e1:s18 ONLINE 0 0 0 > gpt/disk-e1:s19 ONLINE 0 0 0 > gpt/disk-e1:s20 ONLINE 0 0 0 > gpt/disk-e1:s21 ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > gpt/disk-e1:s22 ONLINE 0 0 0 > gpt/disk-e1:s23 ONLINE 0 0 0 > gpt/disk-e2:s0ONLINE 0 0 0 > gpt/disk-e2:s1ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > gpt/disk-e2:s2ONLINE 0 0 0 > gpt/disk-e2:s3ONLINE 0 0 0 > gpt/disk-e2:s4ONLINE 0 0 0 > gpt/disk-e2:s5ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > gpt/disk-e2:s6ONLINE 0 0 0 > gpt/disk-e2:s7ONLINE 0 0 0 > gpt/disk-e2:s8ONLINE 0 0 0 > gpt/disk-e2:s9ONLINE 0 0 0 > spares > gpt/disk-e2:s10 INUSE currently in use > gpt/disk-e2:s11 INUSE currently in use > gpt/disk-e1:s2 UNAVAIL cannot open > gpt/newdisk-e1:s17 INUSE currently in use > > errors: 4 data errors, use '-v' for a list > > > The problem is: after replacing the bad drives and resilvering the old/bad > drives cannot be detached. > The replace command didn't remove it automatically and manual detach fails. > Here are some examples: > > # zpool detach tank 15258738282880603331 > cannot detach 15258738282880603331: no valid replicas > # zpool detach tank gpt/disk-e2:s11 > cannot detach gpt/disk-e2:s11: no valid replicas > # zpool detach tank gpt/newdisk-e1:s17 > cannot detach gpt/newdisk-e1:s17: no valid replicas > # zpool detach tank gpt/disk-e1:s17 > cannot detach gpt/disk-e1:s17: no valid repli
Re: ZFS write speed
Am 27.10.2010 um 22:51 schrieb S.N.Grigoriev: > Hi list, > > I've got very low write speed using ZFS on a SATA disk. > My HDD configuration is: > ad4: 70911MB at ata2-master UDMA100 SATA 3Gb/s > ad6: 78532MB at ata3-master UDMA100 SATA > 1.5Gb/s > ad8: 1430799MB at ata4-master UDMA100 SATA > 3Gb/s The EARS has 4k sectors, if I'm not mistaken. I don't recall the eventual outcome, but there was a long thread on stable or hackers on how to ensure proper alignment and (minimun) 4k-sized writes to make sure the disk doesn't have to do a read-modify-write cycle, so try and search the archives. > ad4 and ad6 are single-slice disks (UFS2 with soft updates) > > ZFS configuration is following: > zpool create Z ad8 > zfs create Z/music > zfs create Z/video > All ZFS parameters are default. > kern.maxvnodes = 100 > > To test my configuration I recursively copied from ad6 to ad8 two directories. > The first one contains MP3 files (average size = 10MB). > The second one contains AVI files (average size = 1GB). > > To compare performance I repeated above tests with ad8 using UFS2 with soft > updates. > > 18GB of MP3 files required 10m35s to copy to UFS2 and 21m40s to copy to ZFS. > 30GB of AVI files required 16m6s to copy to UFS2 and 1h2m39s to copy to ZFS. > > I used for tests FreeBSD 8.1R amd64. Amount of RAM on my machine is 6GB. > > Any tips? > > -- > Regards, > Serguey. > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Stefan BethkeFon +49 151 14070811 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: cdrtools /devel and wodim broken
Sean C. Farley-2 wrote: > > For me, the solution appeared to be setting the grace time to three > seconds to avoid the slowdown of the drive: gracetime=3 > At least, the disc worked on subsequent burns this way. Jakub, you may > try to see if this setting helps. > No, gracetime doesn't help. Maybe Alexander Motin could shed some light on (ahci?) problem? thanks for assistance, Jakub Lach -- View this message in context: http://old.nabble.com/cdrtools--devel-and-wodim-broken-tp29978939p30071221.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ZFS write speed
Hi list, I've got very low write speed using ZFS on a SATA disk. My HDD configuration is: ad4: 70911MB at ata2-master UDMA100 SATA 3Gb/s ad6: 78532MB at ata3-master UDMA100 SATA 1.5Gb/s ad8: 1430799MB at ata4-master UDMA100 SATA 3Gb/s ad4 and ad6 are single-slice disks (UFS2 with soft updates) ZFS configuration is following: zpool create Z ad8 zfs create Z/music zfs create Z/video All ZFS parameters are default. kern.maxvnodes = 100 To test my configuration I recursively copied from ad6 to ad8 two directories. The first one contains MP3 files (average size = 10MB). The second one contains AVI files (average size = 1GB). To compare performance I repeated above tests with ad8 using UFS2 with soft updates. 18GB of MP3 files required 10m35s to copy to UFS2 and 21m40s to copy to ZFS. 30GB of AVI files required 16m6s to copy to UFS2 and 1h2m39s to copy to ZFS. I used for tests FreeBSD 8.1R amd64. Amount of RAM on my machine is 6GB. Any tips? -- Regards, Serguey. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: beastiality
> This is often caused by a combination of two things being enabled > simultaneously: BIOS-level serial console redirection after POST, and > FreeBSD's serial console support. bingo! thanks randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: beastiality
On Thu, Oct 28, 2010 at 04:47:00AM +0900, Randy Bush wrote: > on the serial console, i am seeing twirlies doubled, as in > > // > > and the beastie is very tortured > > > +-++¿Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä|Ä-Ä > ||³ > ||³ ||³ ,, ,, >||³,, ||³/()` > //(( ||³Welcome to FreeBSD!oo FFrr|BSSDD!! \ \___ / > | \\ \\___||³ // || ||³/- _ > `-/ ' //-- __ ||³``--//'' ||³ (/\/ > \ \ /\((//\\// \||³1. Boot FreeBSD [default]BSSDD [[ddeef|aauulltt]] / > / | `\/ // ||³2. Boot FreeBSD with ACPI enabledwiitth| AACCPPII > eennaab) /|/|||³3. Boot FreeBSD in Safe ModeDD iinn S|a >`-^--'`< '`--^^'||³4. Boot FreeBSD in single user moden s|i > (_.) _ ) /ddee))_||³5. Boot FreeBSD with verbose loggingtth| >`.___/`/ /||³6. Escape to loader promptllooaaddeerr |p >`-' / ``-||³7. Rebootebbtt || > <. __ / __ \ // _||³ \\ > || <|O)))==) \) /|))))||³\\)) //|| > || <'`--' `.__,' \`'' ``.||³__,,'' \\ > || || || ||³|| > || \ / /\ ||³Select option, [Enter] for > defaultEnntt|e __( (_ / \__/_(( ||³or [Space] to pause > timer H--11 ussee| ,' ,-' | > ,,-+-++ > `--{__) -Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä_)) > > [...] > spare.psg.com:/root# cat /boot/loader.conf.local > loader_logo=beastie > # > console="comconsole vidconsole" > comconsole_speed="9600" > # > ipfw_load=YES This is often caused by a combination of two things being enabled simultaneously: BIOS-level serial console redirection after POST, and FreeBSD's serial console support. Effectively, the system BIOS is "redirecting" VGA output to the serial port, while simultaneously FreeBSD is doing serial console. But I've seen different behaviour on different hardware over the years when the first option is enabled. - "Doubling of characters" like the above (but sometimes not doubled) - System hard locking (reset/power cycle required) the instant the boot loader tries to do serial (some of my Yahoo! colleagues can confirm this one, even when using RedHat) - System boots/runs fine but no serial output is visible past loader I have some older Supermicro systems which do even weirder things when the option is enabled, like lock up after loader. I've also see different behaviour on RELENG_7 than I do RELENG_8. Back to Supermicro systems -- the aforementioned feature is usually labelled as "Continue C.R. After POST" (C.R. stands for Console Redirection). This is not the same thing as disabling BIOS-level serial console entirely, just that the "Agent" (some sort of interrupt tie-in) isn't retained after POST. If your system offers the BIOS option, you can try turning it off and see if things improve. Be aware that you will lose the ability to access things like Option ROMs (SCSI BIOSes, Intel NIC PXE boot information, etc.). If your system doesn't offer that BIOS option, then possibly just leaving console as its default will suffice. -- | Jeremy Chadwick j...@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 "freebsd-stable-unsubscr...@freebsd.org"
beastiality
on the serial console, i am seeing twirlies doubled, as in // and the beastie is very tortured +-++¿Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä|Ä-Ä ||³ ||³ ||³ ,, ,, ||³,, ||³/()` //(( ||³Welcome to FreeBSD!oo FFrr|BSSDD!! \ \___ / | \\ \\___||³ // || ||³/- _ `-/ ' //-- __ ||³``--//'' ||³ (/\/ \ \ /\((//\\// \||³1. Boot FreeBSD [default]BSSDD [[ddeef|aauulltt]] / / | ` \/ // ||³2. Boot FreeBSD with ACPI enabledwiitth| AACCPPII eennaab) / |/|||³3. Boot FreeBSD in Safe ModeDD iinn S|a`-^--'`< '`--^^'||³4. Boot FreeBSD in single user moden s|i (_.) _ ) /ddee))_||³5. Boot FreeBSD with verbose loggingtth| `.___/` / /||³6. Escape to loader promptllooaaddeerr |p `-' / ``-||³7. Rebootebbtt || <. __ / __ \ // _||³ \\ || <|O)))==) \) /|))))||³\\)) //|| || <'`--' `.__,' \`'' ``.||³__,,'' \\ || | | || ||³|| || \ / /\ ||³Select option, [Enter] for defaultEnntt|e __( (_ / \__/_(( ||³or [Space] to pause timer H--11 ussee| ,' ,-' | ,,-+-++ `--{__) -Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä_)) Copyright (c) 1992-2010 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 8.1-STABLE #1: Sun Sep 5 12:04:21 GMT 2010 r...@test.psg.com:/usr/obj/usr/src/sys/SPARE i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2798.67-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Family = f Model = 2 Stepping = 7 Features=0xbfebfbffhttp://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: hast vs ggate+gmirror sychrnoisation speed
On Tue, 26 Oct 2010 17:01:01 +0100 Pete French wrote: PF> Actually, I just llooked I dmesg on the secondary - it is full PF> of messages thus: PF> Oct 26 15:44:59 serpentine-passive hastd[10394]: [serp0] (secondary) Unable to receive request header: RPC version wrong. PF> Oct 26 15:45:00 serpentine-passive hastd[782]: [serp0] (secondary) Worker process exited ungracefully (pid=10394, exitcode=75). PF> Oct 26 15:46:59 serpentine-passive hastd[10421]: [serp0] (secondary) Unable to receive request header: RPC version wrong. PF> Oct 26 15:47:04 serpentine-passive hastd[782]: [serp0] (secondary) Worker process exited ungracefully (pid=10421, exitcode=75). I saw this too but only sporadic messages so I forgot and did not investigate then this :-). Now running synchronization I see them too (but again only sporadic). Setting the assertion and looking at the received header: (gdb) list 309 goto fail; 310 311 if (hdr.version != HAST_PROTO_VERSION) { 312 assert(0); 313 errno = ERPCMISMATCH; 314 goto fail; 315 } 316 317 hdr.size = le32toh(hdr.size); 318 (gdb) p/x hdr $2 = {version = 0x9, size = 0x65657266} So it looks like garbage. In hast_proto_send() we send header and then data. Couldn't it be that remote_send and sync threads interfere and their packets are mixed? May be some synchronization is needed here? I set sleep(1) in hast_proto_send() between proto_send(header) and proto_send(data). The error started to occur frequently. -- Mikolaj Golub ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Can't build boot blocks after new GPT attributes added
Jeremy Chadwick writes: > $ uname -a > FreeBSD icarus.home.lan 8.1-STABLE FreeBSD 8.1-STABLE #0: Sat Oct 16 07:10:54 > PDT 2010 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 > amd64 > $ sudo -i > icarus# rm -fr /usr/obj/* > rm: No match. > icarus# cd /usr/src icarus# make toolchain > icarus# make buildenv > Entering world for amd64:amd64 > # make clean && make > [...] FTFY. HTH, HAND! DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Can't build boot blocks after new GPT attributes added
On Wed, Oct 27, 2010 at 06:48:58AM -0700, Jeremy Chadwick wrote: > On Wed, Oct 27, 2010 at 09:27:03AM -0400, John Baldwin wrote: > > On Wednesday, October 27, 2010 3:44:02 am Jeremy Chadwick wrote: > > > The below commit has broken the ability to build system boot blocks > > > (including pxeldr) the "historic way"[1]: > > > > > > http://freshbsd.org/2010/10/17/20/10/00 > > > > > > The breakage on RELENG_8 (dated as of a few minutes ago): > > > > > > > > > # rm -fr /usr/obj/* > > > # cd /sys/boot > > > # make clean > > > > This only works if your source tree is in sync with your installed world. > > Adding a hack to the Makefile is wrong. The buildenv approach pjd@ > > suggested > > will work for the case that your source tree does not match your installed > > world. > > But this doesn't appear to be the case here: [...] Because you don't have toolchain built. Once you buildworld you can do that. All in all, the safest and most recommended way is to just use buildworld/buildkernel. -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgppZbOHEKVga.pgp Description: PGP signature
Re: Can't build boot blocks after new GPT attributes added
On Wed, Oct 27, 2010 at 09:27:03AM -0400, John Baldwin wrote: > On Wednesday, October 27, 2010 3:44:02 am Jeremy Chadwick wrote: > > The below commit has broken the ability to build system boot blocks > > (including pxeldr) the "historic way"[1]: > > > > http://freshbsd.org/2010/10/17/20/10/00 > > > > The breakage on RELENG_8 (dated as of a few minutes ago): > > > > > > # rm -fr /usr/obj/* > > # cd /sys/boot > > # make clean > > This only works if your source tree is in sync with your installed world. > Adding a hack to the Makefile is wrong. The buildenv approach pjd@ suggested > will work for the case that your source tree does not match your installed > world. But this doesn't appear to be the case here: $ uname -a FreeBSD icarus.home.lan 8.1-STABLE FreeBSD 8.1-STABLE #0: Sat Oct 16 07:10:54 PDT 2010 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 $ sudo -i icarus# rm -fr /usr/obj/* rm: No match. icarus# cd /usr/src icarus# make buildenv Entering world for amd64:amd64 # make clean && make [...] cc -DBOOTPROG=\"gptboot\" -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DGPT -DUFS1_AND_UFS2 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/gptboot/../../common -I/usr/src/sys/boot/i386/gptboot/../common -I/usr/src/sys/boot/i386/gptboot/../btx/lib -I. -I/usr/src/sys/boot/i386/gptboot/../boot2 -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -std=gnu99 -c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptfind': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: (Each undeclared identifier is reported only once /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: for each function it appears in.) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:130: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootfailed': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:217: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:222: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootconv': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:249: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:250: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:251: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/sys/boot/i386/gptboot. *** Error code 1 Stop in /usr/src/sys/boot/i386. *** Error code 1 Stop in /usr/src/sys/boot. # ls -l /usr/src/sys/boot/i386/gptboot/../../common/gpt.c -rw-r--r-- 1 root wheel 10927 Oct 17 13:10 /usr/src/sys/boot/i386/gptboot/../../common/gpt.c Any ideas? > Maybe you could add text to the handbook to say this, but it is already > implicitly assumed in the handbook section you are referring to since it > assumes you can safely compile a new kernel, etc. The handbook section is > meant as more of a tutorial on how to enable a serial console on a fresh box. > > Once you are experienced enough to start using buildworld, etc. I don't think > it is unreasonable to require users to understand that having a source tree > different from the installed world requires extra steps. I don't think it's unreasonable either, it's just not well-documented or well-established. For example, this is the first time I've heard of "buildenv", not to mention the other pieces mentioned in build(7). That doesn't mean FreeBSD is at fault, it just means there's been changes to things which are hard to keep up to date on. > If we were to document those every time it would clutter documentation > making it harder for someone who is new to FreeBSD to simply setup a > serial console on a box that they just installed. Understood. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | _
Re: Can't build boot blocks after new GPT attributes added
On Wednesday, October 27, 2010 3:44:02 am Jeremy Chadwick wrote: > The below commit has broken the ability to build system boot blocks > (including pxeldr) the "historic way"[1]: > > http://freshbsd.org/2010/10/17/20/10/00 > > The breakage on RELENG_8 (dated as of a few minutes ago): > > > # rm -fr /usr/obj/* > # cd /sys/boot > # make clean This only works if your source tree is in sync with your installed world. Adding a hack to the Makefile is wrong. The buildenv approach pjd@ suggested will work for the case that your source tree does not match your installed world. Maybe you could add text to the handbook to say this, but it is already implicitly assumed in the handbook section you are referring to since it assumes you can safely compile a new kernel, etc. The handbook section is meant as more of a tutorial on how to enable a serial console on a fresh box. Once you are experienced enough to start using buildworld, etc. I don't think it is unreasonable to require users to understand that having a source tree different from the installed world requires extra steps. If we were to document those every time it would clutter documentation making it harder for someone who is new to FreeBSD to simply setup a serial console on a box that they just installed. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Can't build boot blocks after new GPT attributes added
on 27/10/2010 12:17 Jeremy Chadwick said the following: > On Wed, Oct 27, 2010 at 10:08:17AM +0200, Pawel Jakub Dawidek wrote: >> The proper way is to: >> >> # cd /usr/src >> # make buildenv >> # cd sys/boot >> # make clean && make && make install > > Thanks for the tip -- the CFLAGS change in a Makefile sounds like the > solution, since the latter (re: "proper way") didn't work (exact same > problem). The above will work if you already have the toolchain built - that's the only way to ensure that you don't depend on anything in the currently installed world. See build(7). -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Can't build boot blocks after new GPT attributes added
On Wed, Oct 27, 2010 at 10:08:17AM +0200, Pawel Jakub Dawidek wrote: > On Wed, Oct 27, 2010 at 12:44:02AM -0700, Jeremy Chadwick wrote: > > The below commit has broken the ability to build system boot blocks > > (including pxeldr) the "historic way"[1]: > > > > http://freshbsd.org/2010/10/17/20/10/00 > > > > The breakage on RELENG_8 (dated as of a few minutes ago): > > > > > > # rm -fr /usr/obj/* > > # cd /sys/boot > > # make clean > > [...] > > # make > > [...] > > cc -DBOOTPROG=\"gptboot\" -Os -fno-guess-branch-probability > > -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd > > -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DGPT -DUFS1_AND_UFS2 > > -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 > > -I/usr/src/sys/boot/i386/gptboot/../../common > > -I/usr/src/sys/boot/i386/gptboot/../common > > -I/usr/src/sys/boot/i386/gptboot/../btx/lib -I. > > -I/usr/src/sys/boot/i386/gptboot/../boot2 -Wall -Waggregate-return > > -Wbad-function-cast -Wcast-align -Wmissing-declarations > > -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow > > -Wstrict-prototypes -Wwrite-strings -Winline --param > > max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 > > -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 > > -std=gnu99 -c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptfind': > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: > > 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: (Each > > undeclared identifier is reported only once > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: for each > > function it appears in.) > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:130: error: > > 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function > > 'gptbootfailed': > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:217: error: > > 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:222: error: > > 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function > > 'gptbootconv': > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:249: error: > > 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:250: error: > > 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:251: error: > > 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) > > *** Error code 1 > > > > Stop in /usr/src/sys/boot/i386/gptboot. > > *** Error code 1 > > > > Stop in /usr/src/sys/boot/i386. > > *** Error code 1 > > > > Stop in /usr/src/sys/boot. > > > > > > Please advise. If there is a new/correct method, then I'd like to know > > what it is, in addition to the Handbook needing to be updated. > > > > [1]: http://www.freebsd.org/doc/handbook/serialconsole-setup.html > > (See Section 26.6.5.2) > > Well, your problem is that gptboot.c is including gpt.h not from your > source tree, but from /usr/include/sys/, which has an old version of > this header file. This can be easly fixed by extending CFLAGS in one of > the Makefiles (which is already done in HEAD), but I'm afraid this > procedure is incorrect (and never was correct). Apart from including > wrong files it also links to wrong libraries, etc. > > The proper way is to: > > # cd /usr/src > # make buildenv > # cd sys/boot > # make clean && make && make install Thanks for the tip -- the CFLAGS change in a Makefile sounds like the solution, since the latter (re: "proper way") didn't work (exact same problem). The Makefile adjustment you mention for HEAD is here: http://freshbsd.org/2010/10/08/10/27/52 But there's no mention of an MFC date in the commit message. Can this be MFC'd? For now, "make buildworld" works as a workaround (pull the bootstrap binaries needed out of /usr/obj). -- | Jeremy Chadwick j...@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 "freebsd-stable-unsubscr...@freebsd.org"
Re: Can't build boot blocks after new GPT attributes added
On Wed, Oct 27, 2010 at 12:44:02AM -0700, Jeremy Chadwick wrote: > The below commit has broken the ability to build system boot blocks > (including pxeldr) the "historic way"[1]: > > http://freshbsd.org/2010/10/17/20/10/00 > > The breakage on RELENG_8 (dated as of a few minutes ago): > > > # rm -fr /usr/obj/* > # cd /sys/boot > # make clean > [...] > # make > [...] > cc -DBOOTPROG=\"gptboot\" -Os -fno-guess-branch-probability > -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd > -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DGPT -DUFS1_AND_UFS2 > -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 > -I/usr/src/sys/boot/i386/gptboot/../../common > -I/usr/src/sys/boot/i386/gptboot/../common > -I/usr/src/sys/boot/i386/gptboot/../btx/lib -I. > -I/usr/src/sys/boot/i386/gptboot/../boot2 -Wall -Waggregate-return > -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes > -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes > -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -m32 -march=i386 -std=gnu99 -c > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptfind': > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: > 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: (Each > undeclared identifier is reported only once > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: for each > function it appears in.) > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:130: error: > 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function > 'gptbootfailed': > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:217: error: > 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:222: error: > 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootconv': > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:249: error: > 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:250: error: > 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:251: error: > 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) > *** Error code 1 > > Stop in /usr/src/sys/boot/i386/gptboot. > *** Error code 1 > > Stop in /usr/src/sys/boot/i386. > *** Error code 1 > > Stop in /usr/src/sys/boot. > > > Please advise. If there is a new/correct method, then I'd like to know > what it is, in addition to the Handbook needing to be updated. > > [1]: http://www.freebsd.org/doc/handbook/serialconsole-setup.html > (See Section 26.6.5.2) Well, your problem is that gptboot.c is including gpt.h not from your source tree, but from /usr/include/sys/, which has an old version of this header file. This can be easly fixed by extending CFLAGS in one of the Makefiles (which is already done in HEAD), but I'm afraid this procedure is incorrect (and never was correct). Apart from including wrong files it also links to wrong libraries, etc. The proper way is to: # cd /usr/src # make buildenv # cd sys/boot # make clean && make && make install -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpGuoEb8uCVg.pgp Description: PGP signature
Can't build boot blocks after new GPT attributes added
The below commit has broken the ability to build system boot blocks (including pxeldr) the "historic way"[1]: http://freshbsd.org/2010/10/17/20/10/00 The breakage on RELENG_8 (dated as of a few minutes ago): # rm -fr /usr/obj/* # cd /sys/boot # make clean [...] # make [...] cc -DBOOTPROG=\"gptboot\" -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DGPT -DUFS1_AND_UFS2 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/gptboot/../../common -I/usr/src/sys/boot/i386/gptboot/../common -I/usr/src/sys/boot/i386/gptboot/../btx/lib -I. -I/usr/src/sys/boot/i386/gptboot/../boot2 -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -std=gnu99 -c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptfind': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: (Each undeclared identifier is reported only once /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: for each function it appears in.) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:130: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootfailed': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:217: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:222: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootconv': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:249: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:250: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:251: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/sys/boot/i386/gptboot. *** Error code 1 Stop in /usr/src/sys/boot/i386. *** Error code 1 Stop in /usr/src/sys/boot. Please advise. If there is a new/correct method, then I'd like to know what it is, in addition to the Handbook needing to be updated. [1]: http://www.freebsd.org/doc/handbook/serialconsole-setup.html (See Section 26.6.5.2) -- | Jeremy Chadwick j...@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 "freebsd-stable-unsubscr...@freebsd.org"