IPv6 ANSI cleanup
Hello. I made diffs to ANSI the IPv6 stack in both OpenBSD and NetBSD and here comes my version for FreeBSD. NetBSD has already commited their diff and it would be good if all the *BSD have the same style for it. Diff can be found here: http://213.113.152.10/freebsd_ipv6.diff br dunceor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: file(1) cannot detect UFS2?
On Sun, Jun 10, 2007 at 12:41:31AM +0200, Ivan Voras wrote: Hi! I'm trying to use file(1) to detect file system type on partitions, and so far it's working for any file system I've cared to try (the usual MS and Linux list) *except* UFS2. Detecting UFS1 works, though much more verbosely than it needs to be, but UFS2 isn't detected at all. I'd like to ask someone familiar with UFS2 to take a quick peak and add the appropriate rules to the file(1) magic database, if anyone's interested. At the very least, I need someone to commit this patch: well... yeah but not to freebsd :) I guess you want to forward the patch upstream to the maintainers of file. thnx for the work though ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: file(1) cannot detect UFS2?
Roman Divacky wrote: well... yeah but not to freebsd :) I guess you want to forward the patch upstream to the maintainers of file. Thanks. By a happy coincedence, it's already there, in version 4.21! 42332 belong 0x19540119 Unix Fast File system [v2] (big-endian) -1164 string x last mounted on %s, -696 string \0 volume name %s, -304 beqldatex last written at %s, Now there's only the matter of importing it :) signature.asc Description: OpenPGP digital signature
Ricoh r5u870
Hi, Is there is any one working on Ricoh r5u870 webcam driver ? Ricoh r5u870 known as hp webcam. Thanks -- System Programmer I'm Searching For Perfection, So Even If U Need Potability U've To Use Assembly ;-) -- http://libosdk.berlios.de/wiki/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: file(1) cannot detect UFS2?
0n Sun, Jun 10, 2007 at 12:41:31AM +0200, Ivan Voras wrote: I'm trying to use file(1) to detect file system type on partitions, and so far it's working for any file system I've cared to try (the usual MS and Linux list) *except* UFS2. Not sure if what you're doing *has* to be done with file(1). However, you can what you want like so: #dumpfs ad0s1a | head -1 magic 19540119 (UFS2) timeSun Jun 10 21:30:45 2007 -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: file(1) cannot detect UFS2?
Wilkinson, Alex wrote: 0n Sun, Jun 10, 2007 at 12:41:31AM +0200, Ivan Voras wrote: I'm trying to use file(1) to detect file system type on partitions, and so far it's working for any file system I've cared to try (the usual MS and Linux list) *except* UFS2. Not sure if what you're doing *has* to be done with file(1). However, you can what you want like so: #dumpfs ad0s1a | head -1 magic 19540119 (UFS2) timeSun Jun 10 21:30:45 2007 So you're proposing one utility per possible file system instead of one utility total? :) signature.asc Description: OpenPGP digital signature
Re: kern/83807: [sis] [patch] if_sis: Wake On Lan support for FreeBSD
On Sat, Jun 09, 2007 at 05:07:39PM +0200, Edwin Mons wrote: I currently have one -CURRENT machine, and several 6.2-STABLE machines. For at least two of them (the -CURRENT and an x86 -STABLE machine) I'd really like to have WoL support, as these are my workstation and a home server, both of them really do not need to be on all the time, but I want to be able to reach them when I need a file from them when I'm elsewhere. Yes, wake on lan, if used properly, makes computers a bit more friendly to the environment :-) I usually use either if_em or if_xl chipsets, so I hoped landing this code in at least -CURRENT (should go there first, I guess) would result in more chipsets supported ;) There is code for enabling wake on lan in the Linux drivers for both if_xl and if_em cards. See drivers/net/3c59x.c and drivers/net/e1000/e1000_ethtool.c in the linux source tree. So I don't think adding support for these cards is a problem. Just need to find some time to do it... If anyone has data sheets for these cards I'd like a copy if possible. By the way if anyone has data sheets for if_vr I'd like a copy as well please because there is something the Linux driver does that I do not understand because the code is not obvious enough. Specifically I need to understand what the hell they mean exactly by patterns for WOL. If anyone has a card that does wake on lan after shutdown from Linux but not after shutdown from FreeBSD with my patch applied let me know. You may need to use the ethtool utility to enable WOL on Linux. I don't run Linux on either machine. Perhaps I could do some tests on my workstation with a CD-based linux distribution. No need to test your cards with Linux since we know now there is code for this in Linux so it should work anyway. -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpOZxTHbA4SM.pgp Description: PGP signature
Re: file(1) cannot detect UFS2?
Now there's only the matter of importing it :) you mean... like was done 2 weeks ago? :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: file(1) cannot detect UFS2?
Roman Divacky wrote: Now there's only the matter of importing it :) you mean... like was done 2 weeks ago? :) Aargh. (it was done a few minutes after I've last cvsupped and started buildworld, so I've just missed it). Thanks and sorry for bogosity. signature.asc Description: OpenPGP digital signature
Re: GPT - (last) call for action
:Technically speaking, the MBR can only have a single partition of :type 0xEE that covers the whole disk. This is to protect the GPT :from MBR-specific tools that do not know about the GPT. This is :not a bootable slice by definition. : :Practice is different. To support bootcamp on Intel-based Macs, :the MBR will have real partitions that mirror GPT partitions or :otherwise describe partitions outside the GPT controlled area. :These can be bootable partitions and the protective partition :(the one with type 0xEE) will not cover the whole disk anymore. : :The nasty part is keeping MBR and GPT partitions in sync, so it :may be better to have the MBR partition fall outside the GPT :controlled area. This can be done because the GPT header contains :the LBA of the first and last sectors on the disk that can be :assigned to a partition. You can free up space for MBR partitions :after the primary GPT table by adjusting the first LBA. In the :MBR partition you can put a GPT aware boot loader that uses the :GPT to find the real partitions... : :-- :Marcel Moolenaar In the bootcamp approach, is the GPT (0xEE) slice the first slice, and the bootcamp slice the second slice? I'm assuming it is. Do they mirror a GPT partition or do they use the uncontrolled area approach? I like the mirroring approach, because I can make the label manager just treat the special MBR slice (s2) as being part of the integrated GPT spec (which it is). From the end-user's point of view he would just do something like 'gptlabel -e ad0' and one of the GPT partitions listed would be the 'boot' partition. gptlabel would recognize the special nature of the partition and automatically and silently adjust the special MBR slice (s2) to match it. I don't like the out-of-band approach... I definitely want the partitions to be within GPTs managed area, at least for newly minted disks. With the in-band approach the gpt labeling program can take care of any special compatibility cases in a fairly straightforward and controlled manner. -Matt Matthew Dillon [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
On Jun 10, 2007, at 10:52 AM, Matthew Dillon wrote: :Technically speaking, the MBR can only have a single partition of :type 0xEE that covers the whole disk. This is to protect the GPT :from MBR-specific tools that do not know about the GPT. This is :not a bootable slice by definition. : :Practice is different. To support bootcamp on Intel-based Macs, :the MBR will have real partitions that mirror GPT partitions or :otherwise describe partitions outside the GPT controlled area. :These can be bootable partitions and the protective partition :(the one with type 0xEE) will not cover the whole disk anymore. : :The nasty part is keeping MBR and GPT partitions in sync, so it :may be better to have the MBR partition fall outside the GPT :controlled area. This can be done because the GPT header contains :the LBA of the first and last sectors on the disk that can be :assigned to a partition. You can free up space for MBR partitions :after the primary GPT table by adjusting the first LBA. In the :MBR partition you can put a GPT aware boot loader that uses the :GPT to find the real partitions... : :-- :Marcel Moolenaar In the bootcamp approach, is the GPT (0xEE) slice the first slice, and the bootcamp slice the second slice? I'm assuming it is. Do they mirror a GPT partition or do they use the uncontrolled area approach? I seem to recall that the 0xEE partition is not the first, but rather the second or third. It would make sense, because it has no function other than to have the disk appear used. Bootcamp uses the mirroring approach. -- Marcel Moolenaar [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Disable mutex spinning?
Hi I'm not sure I'm thinking the right way here, so this could be just nonsense. Since I started using VMWare (and that was a long time ago) and other virtual machine applications, I've noticed FreeBSD spends a lot of time in system space (i.e. much time is allocated to sys in utilities like top and time) during IO intensive operations. At first I thought this is because the emulated IO devices are much slower than real devices, so IO requests take a long time to complete, leading to sys time. It occurred to me that this might be bogus thinking - yes, emulated IO devices take a long time to perform IO but during that time the system doesn't do anything, so that time should be effectively described as idle, waiting for IO completion... or does it? I'm thinking of experiment - removing all spinning from mutex-like code and try running such kernel in a VMWare machine. For start, is there anything else except turning off ADAPTIVE_MUTEXES, ADAPTIVE_GIANT and ADAPTIVE_RWLOCKS I can do via the kernel config file? If someone has more insight to share on this topic, I'm listening :) signature.asc Description: OpenPGP digital signature
Re: Disable mutex spinning?
Ivan Voras wrote: I'm thinking of experiment - removing all spinning from mutex-like code and try running such kernel in a VMWare machine. For start, is there anything else except turning off ADAPTIVE_MUTEXES, ADAPTIVE_GIANT and ADAPTIVE_RWLOCKS I can do via the kernel config file? Hmm, on second thought this wouldn't help at all unless there's much contention signature.asc Description: OpenPGP digital signature
Re: GPT - (last) call for action
:No. :The first partition is the EFI GPT (0xee): : :% fdisk -1 :*** Working on device /dev/ad0 *** :... :parameters to be used for BIOS calculations are: :cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) : :Media sector size is 512 :Warning: BIOS sector numbering starts with sector 1 :Information from DOS bootblock is: :The data for partition 1 is: :sysid 238 (0xee),(EFI GPT) :start 40, size 409600 (200 Meg), flag 0 :beg: cyl 0/ head 0/ sector 41; :end: cyl 406/ head 6/ sector 14 I think I have it mostly figured out, but the 'start 40' in your output can't be right. The intel documentation says that the starting LBA in a PMBR record must be set to 1 by definition (table 11-7 in the 1.10 documentation). -Matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
pkgdb -F calling portupgrade -a
I'm very surprised and upset that running pkgdb -F has started a whole upgrade of my stable machine. I'm sure hacker's isn't the right list for this but it is so amazing that I don't know what the right list would be and I think just calling attention to some very bizarre behavior is maybe the best thing. This machine should only have X11 clients... Anyhow output below... Jeff Anton __ paris.hesiod.org:root[62]: portversion Stale dependency: Xaw3d-1.5E_1 -- xf86dgaproto-2.0.2 -- manually run 'pkgdb -F' to fix, or specify -O to force. paris.hesiod.org:root[63]: pkgdb -F --- Checking the package registry database Stale origin: 'x11/xorg-manpages': perhaps moved or obsoleted. - The port 'x11/xorg-manpages' was removed on because: X.org manual pages are now installed with every single port - Hint: xorg-manpages-6.9.0 is not required by any other package - Hint: checking for overwritten files... - No files installed by xorg-manpages-6.9.0 have been overwritten by other packages. Deinstall xorg-manpages-6.9.0 ? [no] yes --- Deinstalling 'xorg-manpages-6.9.0' [Updating the pkgdb format:bdb_btree in /var/db/pkg ... - 70 packages found (-1 +0) (...) done] -- Done. Stale dependency: Xaw3d-1.5E_1 - xf86dgaproto-2.0.2 (x11/xf86dgaproto): Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n New dependency? (? to help): . Abort. 62.580u 41.058s 2:08.82 80.4% 157+2488k 1300+1603io 12pf+0w paris.hesiod.org:root[64]: pkgdb -F --- Checking the package registry database Stale dependency: Xaw3d-1.5E_1 - xf86dgaproto-2.0.2 (x11/xf86dgaproto): Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n New dependency? (? to help): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. Stale dependency: Xaw3d-1.5E_1 - libXdamage-1.1.1 (x11/libXdamage): libXft-2.1.7_1 (score:25%) ? ([y]es/[n]o/[a]ll) [no] Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n New dependency? (? to help): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. Stale dependency: Xaw3d-1.5E_1 - renderproto-0.9.2 (x11/renderproto): Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n New dependency? (? to help): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. Stale dependency: Xaw3d-1.5E_1 - compositeproto-0.3.1 (x11/compositeproto): Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n New dependency? (? to help): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. Stale dependency: Xaw3d-1.5E_1 - libXv-1.0.3,1 (x11/libXv): libXft-2.1.7_1 (score:22%) ? ([y]es/[n]o/[a]ll) [no] Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n --- Installing 'libXv-1.0.3,1' from a port (x11/libXv) --- Building '/usr/ports/x11/libXv' === Cleaning for xextproto-7.0.2 === Cleaning for videoproto-2.2.2 === Cleaning for libX11-1.1.2,1 ^Z=== Cleaning for libXext-1.0.3,1 === Cleaning for pkg-config-0.21 === Cleaning for bigreqsproto-1.0.2 === Cleaning for xcmiscproto-1.1.2 === Cleaning for kbproto-1.0.3 === Cleaning for inputproto-1.3.2 === Cleaning for xf86bigfontproto-1.1.2 === Cleaning for libXau-1.0.3_2 === Cleaning for libXdmcp-1.0.2 === Cleaning for xtrans-1.0.3 === Cleaning for xproto-7.0.10 === Cleaning for libtool-1.5.22_4 === Cleaning for gmake-3.81_2 === Cleaning for gettext-0.16.1_3 === Cleaning for libiconv-1.9.2_2 === Cleaning for libXv-1.0.3,1 === Vulnerability check disabled, database not found = libXv-1.0.3.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/xorg/lib. = Attempting to fetch from ftp://ftp.gwdg.de/pub/x11/x.org/pub/individual/lib/. libXv-1.0.3.tar.bz2 100% of 226 kB 98 kBps === Extracting for libXv-1.0.3,1 = MD5 Checksum OK for xorg/lib/libXv-1.0.3.tar.bz2. = SHA256 Checksum OK for xorg/lib/libXv-1.0.3.tar.bz2. === Patching for libXv-1.0.3,1 === libXv-1.0.3,1 depends on file: /usr/local/libdata/pkgconfig/xextproto.pc - not found ===Verifying install for /usr/local/libdata/pkgconfig/xextproto.pc in /usr/ports/x11/xextproto === Vulnerability check disabled, database not found = xextproto-7.0.2.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/xorg/proto. = Attempting to fetch from ftp://ftp.gwdg.de/pub/x11/x.org/pub/individual/proto/. xextproto-7.0.2.tar.bz2 100% of 66 kB 53 kBps === Extracting for xextproto-7.0.2 = MD5 Checksum OK for xorg/proto/xextproto-7.0.2.tar.bz2. = SHA256 Checksum OK for xorg/proto/xextproto-7.0.2.tar.bz2. === Patching for xextproto-7.0.2 === Configuring for xextproto-7.0.2 configure: WARNING: you should use --build, --host, --target checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes configure: creating ./config.status config.status: creating Makefile config.status: creating xextproto.pc === Building for xextproto-7.0.2 === Installing for xextproto-7.0.2 === Generating temporary packing list === Checking if
Re: pkgdb -F calling portupgrade -a
On Sun, Jun 10, 2007 at 04:15:29PM -0700, Jeff Anton wrote: I'm very surprised and upset that running pkgdb -F has started a whole upgrade of my stable machine. Well, it didn't. I'm sure hacker's isn't the right list for this Correct. but it is so amazing that I don't know what the right list would be Ports problems go to the ports list. Problems with a particular port (e.g. portupgrade) go to that list and/or the port's maintainer. Deinstall xorg-manpages-6.9.0 ? [no] yes --- Deinstalling 'xorg-manpages-6.9.0' [Updating the pkgdb format:bdb_btree in /var/db/pkg ... - 70 packages found (-1 +0) (...) done] -- Done. Stale dependency: Xaw3d-1.5E_1 - xf86dgaproto-2.0.2 (x11/xf86dgaproto): Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n New dependency? (? to help): . Abort. 62.580u 41.058s 2:08.82 80.4% 157+2488k 1300+1603io 12pf+0w You need to go through the xorg 7.2 upgrade. Most of what you chose to do was actually damaging your port installations, e.g. --- Checking the package registry database Stale dependency: Xaw3d-1.5E_1 - xf86dgaproto-2.0.2 (x11/xf86dgaproto): Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n ^ New dependency? (? to help): Delete this? ([y]es/[n]o/[a]ll) [yes] Whee, you've deleted metadata that was required for correctness of future upgrades. Deleted. Stale dependency: Xaw3d-1.5E_1 - libXdamage-1.1.1 (x11/libXdamage): libXft-2.1.7_1 (score:25%) ? ([y]es/[n]o/[a]ll) [no] Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n New dependency? (? to help): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. Stale dependency: Xaw3d-1.5E_1 - renderproto-0.9.2 (x11/renderproto): Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n New dependency? (? to help): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. Stale dependency: Xaw3d-1.5E_1 - compositeproto-0.3.1 (x11/compositeproto): Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n New dependency? (? to help): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. Stale dependency: Xaw3d-1.5E_1 - libXv-1.0.3,1 (x11/libXv): libXft-2.1.7_1 (score:22%) ? ([y]es/[n]o/[a]ll) [no] Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n This is the only part that doesn't make sense. Are you sure you didn't do e.g. 'y^Hn' where that was not interpreted by the terminal as a backspace but as a string beginning with 'y'? It's the only way I can think that this would trigger the 'yes' branch. Anyway, it wasn't doing 'portupgrade -a' but trying to bring your system up to a consistent state. Really what you probably should have done was either leave your system alone (i.e. not answered 'yes' to requests to modify things), or go through the documented x.org 7.2 upgrade procedure to perform the upgrade correctly and completely. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkgdb -F calling portupgrade -a
In [EMAIL PROTECTED], Jeff Anton [EMAIL PROTECTED] typed: I'm very surprised and upset that running pkgdb -F has started a whole upgrade of my stable machine. I'm sure hacker's isn't the right list for this but it is so amazing that I don't know what the right list would be and I think just calling attention to some very bizarre behavior is maybe the best thing. This machine should only have X11 clients... Anyhow output below... Hi Jeff, Long time no see. The only wierd thing I see is right here: Stale dependency: Xaw3d-1.5E_1 - libXv-1.0.3,1 (x11/libXv): libXft-2.1.7_1 (score:22%) ? ([y]es/[n]o/[a]ll) [no] Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n --- Installing 'libXv-1.0.3,1' from a port (x11/libXv) --- Building '/usr/ports/x11/libXv' Where it starts installing the port even though you told it not to. That's a pkgdb issue, and the right person to talk to is the portupgrade maintainer, [EMAIL PROTECTED] For the rest of it - you've apperently got x.org 6.9 installed on the system and x.org 7.0 in the ports tree. So once it starts installing ports, it's pretty much going to install the entire xorg ports set. Since they install in different prefixes (7.0 moved to /usr/local), that will actually work. I didn't see anything but client stuff in the output. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkgdb -F calling portupgrade -a
On Sun, Jun 10, 2007 at 07:59:14PM -0400, Mike Meyer wrote: In [EMAIL PROTECTED], Jeff Anton [EMAIL PROTECTED] typed: I'm very surprised and upset that running pkgdb -F has started a whole upgrade of my stable machine. I'm sure hacker's isn't the right list for this but it is so amazing that I don't know what the right list would be and I think just calling attention to some very bizarre behavior is maybe the best thing. This machine should only have X11 clients... Anyhow output below... Hi Jeff, Long time no see. The only wierd thing I see is right here: Stale dependency: Xaw3d-1.5E_1 - libXv-1.0.3,1 (x11/libXv): libXft-2.1.7_1 (score:22%) ? ([y]es/[n]o/[a]ll) [no] Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n --- Installing 'libXv-1.0.3,1' from a port (x11/libXv) --- Building '/usr/ports/x11/libXv' Where it starts installing the port even though you told it not to. That's a pkgdb issue, and the right person to talk to is the portupgrade maintainer, [EMAIL PROTECTED] For the rest of it - you've apperently got x.org 6.9 installed on the system and x.org 7.0 in the ports tree. So once it starts installing ports, it's pretty much going to install the entire xorg ports set. Since they install in different prefixes (7.0 moved to /usr/local), that will actually work. Unfortunately it will not work and will actually lead to package database corruption due to a portupgrade bug. That's why the more extensive upgrade process in UPDATING is necessary. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
At Sun, 10 Jun 2007 11:08:47 -0700, Marcel Moolenaar wrote: On Jun 10, 2007, at 10:52 AM, Matthew Dillon wrote: :Technically speaking, the MBR can only have a single partition of :type 0xEE that covers the whole disk. This is to protect the GPT :from MBR-specific tools that do not know about the GPT. This is :not a bootable slice by definition. : :Practice is different. To support bootcamp on Intel-based Macs, :the MBR will have real partitions that mirror GPT partitions or :otherwise describe partitions outside the GPT controlled area. :These can be bootable partitions and the protective partition :(the one with type 0xEE) will not cover the whole disk anymore. : :The nasty part is keeping MBR and GPT partitions in sync, so it :may be better to have the MBR partition fall outside the GPT :controlled area. This can be done because the GPT header contains :the LBA of the first and last sectors on the disk that can be :assigned to a partition. You can free up space for MBR partitions :after the primary GPT table by adjusting the first LBA. In the :MBR partition you can put a GPT aware boot loader that uses the :GPT to find the real partitions... : :-- :Marcel Moolenaar In the bootcamp approach, is the GPT (0xEE) slice the first slice, and the bootcamp slice the second slice? I'm assuming it is. Do they mirror a GPT partition or do they use the uncontrolled area approach? I seem to recall that the 0xEE partition is not the first, but rather the second or third. It would make sense, because it has no function other than to have the disk appear used. Bootcamp uses the mirroring approach. No. The first partition is the EFI GPT (0xee): % fdisk -1 *** Working on device /dev/ad0 *** parameters extracted from in-core disklabel are: cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 238 (0xee),(EFI GPT) start 40, size 409600 (200 Meg), flag 0 beg: cyl 0/ head 0/ sector 41; end: cyl 406/ head 6/ sector 14 % gpt -r show ad0 gpt show: ad0: Suspicious MBR at sector 0 start size index contents 0 1 MBR 1 1 Pri GPT header 2 32 Pri GPT table 34 6 40 409600 1 GPT part - EFI System 409640 41943040 2 GPT part - Apple HFS 42352680 74857527 3 GPT part - FreeBSD UFS/UFS2 117210207 32 Sec GPT table 117210239 1 Sec GPT header -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
At Sun, 10 Jun 2007 14:43:26 -0700 (PDT), Matthew Dillon wrote: :No. :The first partition is the EFI GPT (0xee): : :% fdisk -1 :*** Working on device /dev/ad0 *** :... :parameters to be used for BIOS calculations are: :cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) : :Media sector size is 512 :Warning: BIOS sector numbering starts with sector 1 :Information from DOS bootblock is: :The data for partition 1 is: :sysid 238 (0xee),(EFI GPT) :start 40, size 409600 (200 Meg), flag 0 :beg: cyl 0/ head 0/ sector 41; :end: cyl 406/ head 6/ sector 14 I think I have it mostly figured out, but the 'start 40' in your output can't be right. The intel documentation says that the starting LBA in a PMBR record must be set to 1 by definition (table 11-7 in the 1.10 documentation). I don't know why Apple does that. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkgdb -F calling portupgrade -a
In [EMAIL PROTECTED], Kris Kennaway [EMAIL PROTECTED] typed: --- Checking the package registry database Stale dependency: Xaw3d-1.5E_1 - xf86dgaproto-2.0.2 (x11/xf86dgaproto): Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n ^ New dependency? (? to help): Delete this? ([y]es/[n]o/[a]ll) [yes] Whee, you've deleted metadata that was required for correctness of future upgrades. Just out of curiosity, what should he have done? Yes, the data was required for the correctness of future upgrades, but the data was broken in ways that the automated tools couldn't deal with. Installing the stale dependency would lead to incorrectly trying to install the new x.org 7 ports. There's no right-looking new dependency to use, or pkgdb would have suggested it. Leaving the dependency in place wouldn't solve the problem that pkgdb was run to fix in the first place. So what's the right alternative? mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkgdb -F calling portupgrade -a
On Sun, Jun 10, 2007 at 08:15:33PM -0400, Mike Meyer wrote: In [EMAIL PROTECTED], Kris Kennaway [EMAIL PROTECTED] typed: --- Checking the package registry database Stale dependency: Xaw3d-1.5E_1 - xf86dgaproto-2.0.2 (x11/xf86dgaproto): Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n ^ New dependency? (? to help): Delete this? ([y]es/[n]o/[a]ll) [yes] Whee, you've deleted metadata that was required for correctness of future upgrades. Just out of curiosity, what should he have done? Yes, the data was required for the correctness of future upgrades, but the data was broken in ways that the automated tools couldn't deal with. Installing the stale dependency would lead to incorrectly trying to install the new x.org 7 ports. There's no right-looking new dependency to use, or pkgdb would have suggested it. Leaving the dependency in place wouldn't solve the problem that pkgdb was run to fix in the first place. So what's the right alternative? I guess deleting it is probably the least bad alternative, followed by upgrading to xorg 7.2, followed by a pkgdb -L to repair the damage. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
