Re: [rfc] removing the NDISulator
On 19.10.2013 10:01, Thomas Mueller wrote: I too would like to see more effort writing new Ethernet and wifi drivers and porting from other operating systems. But I would like to keep the NDISulator/NDISwrapper as a fallback. There are still wifi adapters, Ethernet too, where there is no FreeBSD driver (AR9271 for instance), or the FreeBSD driver is buggy. I'm agree. While there are still some devices without native drivers, but that work via NDISulator, we should keep it. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel broken: run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config
On 23.06.2011 11:54, O. Hartmann wrote: With today's update of sources (Revision: 223466 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 223466 Last Changed Date: 2011-06-23 08:55:29 +0200 (Do, 23 Jun 2011)) FreeBSD 9.0-CURRENT/amd64 won't boot anymore. The box gets stuck in booting the kernel and ending up with the message (repeated every 60 seconds): run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config I have this problem too. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: kernel broken: run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config
On 23.06.2011 11:54, O. Hartmann wrote: FreeBSD 9.0-CURRENT/amd64 won't boot anymore. The box gets stuck in booting the kernel and ending up with the message (repeated every 60 seconds): run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config What's up? I backed out r223443 and r223448 and it helped. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: FreeBSD 9
On 30.06.2011 21:40, Tim Gustafson wrote: I think you need something along the line of ifconfig_bce0_alias0=inet 1.2.3.5 netmask ..., notice the 'inet', since aliasN can be used for both inet and inet6. Got it, thanks! I assume that's also recommended for the primary interface as well? I've added the inet prefix to both lines and it is working. Thanks! There is also ipv4_addrs_IF variable, you can use it: ipv4_addrs_bce0=1.2.3.4/22 1.2.3.5/32 -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: A replacement for GEOM_LABEL's gpt/gptid
On 18.08.2011 4:08, Nathan Whitehorn wrote: What it contains: * gpt/gptid support removed from GEOM_LABEL class; * new GEOM_ALIAS class added. This class has two public functions: void g_alias_create(struct g_provider *pp, const char *name); void g_alias_spoil(struct g_provider *pp); * first two consumers of GEOM_ALIAS class are GEOM_PART and GEOM_DISK: GEOM_DISK uses g_alias_create() to create aliases for disks, disk's serial number is used for alias name. GEOM_PART uses g_alias_create() to create aliases for labeled partitions (gpt/gptid, apm and pc98). How it looks like: http://paste.org.ru/?5exeve What happened to this? It would be really nice to have in 9.0, or soon after anyway. Anything I can do to help it along? :) Well, there were some problems found. AFAIR, the last patch i tested is here: http://people.freebsd.org/~ae/geom_alias.diff Among other things it slightly extends GEOM core to be able pass trough taste and spoil events. To recall for myself how it works: I added new GEOM class - GEOM_ALIAS. It provides two public functions: void g_alias_create(struct g_provider *pp, const char *name); It creates one instance of geom_alias class for given provider and this instance might have several providers (aliases). void g_alias_spoil(struct g_provider *pp); It destroys all aliases for given provider if they are not in use. If some alias is used, then function only marks it as stale. The access method of GEOM_ALIAS class destroys stale provider when it is released. The spoiled method calls g_spoil() for each alias, i.e. it passes spoil event to consumers of all aliases. The taste method checks given provider and if it has GEOM_ALIAS consumer and it was spoiled before, then it does retaste for each alias. I don't remember what were the results of testing, but looks like there is something that could be improved. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Well, there goes Windows!
On 22.08.2011 4:00, Nathan Whitehorn wrote: The larger problem is that this behavior means that destroying gparts sometimes doesn't work at all. For instance, if you have nested partitioning like MBR+BSD (or EBR) it is not possible to destroy the underlying MBR geom without committing the destruction of the BSD geom. This is because the MBR geom cannot be destroyed, even without committing, while it continues to have children, which it does due to the ghost geom for the BSD slice. Actually you can destroy underlying MBR geom without committing, just use force flag. But there is another problem, the metadata of nested scheme will not deleted and it might appear again when you create new MBR and new partition in the same place. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Well, there goes Windows!
On 22.08.2011 17:13, Nathan Whitehorn wrote: Actually you can destroy underlying MBR geom without committing, just use force flag. But there is another problem, the metadata of nested scheme will not deleted and it might appear again when you create new MBR and new partition in the same place. This isn't true for nested partitioning, at least in my experience. You can try: # mdconfig -s 100m # gpart create -s mbr md0 # gpart add -t freebsd md0 # gpart create -s bsd md0s1 # gpart add -t freebsd-ufs md0s1 # gpart destroy -F -f x md0 But when you create MBR again: # gpart create -f x -s mbr md0 # gpart add -f x -t fat32 md0 Now the old BSD scheme will be detected: = 9 204791 md0 MBR (100M) 9 2047861 fat32 (100M) 204795 5 - free - (2.5k) = 0 204786 md0s1 BSD (100M) 0 204786 1 freebsd-ufs (100M) -- The forced destroying does not work for the case when you destroyed nested scheme before MBR, e.g. # gpart destroy -f x -F md0s1 # gpart destroy -f x -F md0 gpart: Device busy It's because the first destroying is not committed and provider md0s1 is still opened: # gpart list md0s1 | grep Mode Mode: r1w1e1 - -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 9.0 BETA2 gpart resize -s uses whole disk on first resize
On 07.09.2011 04:21, Mikael Fridh wrote: Hi gurus, FreeBSD freebsd9.mg8.tmtowtdi.se 9.0-BETA2 FreeBSD 9.0-BETA2 #0: Wed Aug 31 18:07:44 UTC 2011 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 When resizing a partition, on first attempt it uses up the whole disk. Only on second attempt it resizes to the correct target size. Resizing from any smaller size to a larger size initially uses up the whole disk, like if -s was not used at all even if it's as little as one logical disk block. I'm wondering if anyone else can reproduce. I can't reproduce. # dd if=/dev/zero of=./disk count=1 seek=3907029167 1+0 records in 1+0 records out 512 bytes transferred in 0.000116 secs (4409617 bytes/sec) # mdconfig -f disk md0 # gpart create -s gpt md0 md0 created # gpart add -t freebsd-boot -b 64 -s 128 md0 md0p1 added # gpart add -t freebsd-swap -s 8388608 md0 md0p2 added # gpart show md0 =34 3907029101 md0 GPT (1.8T) 34 30 - free - (15k) 64 1281 freebsd-boot (64k) 192 83886082 freebsd-swap (4.0G) 8388800 3898640335 - free - (1.8T) # gpart resize -i 2 -s 33554432 md0 md0p2 resized # gpart show md0 =34 3907029101 md0 GPT (1.8T) 34 30 - free - (15k) 64 1281 freebsd-boot (64k) 192335544322 freebsd-swap (16G) 33554624 3873474511 - free - (1.8T) === So, can you enable G_F_CTLDUMP flag and try it again, and show what you will get? Just use: # sysctl kern.geom.debugflags=0x80 # gpart resize -i 2 -s 33554432 md0 On the console (and in the log files) will be printed some info. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: FreeBSD 9.0 BETA2 gpart resize -s uses whole disk on first resize
On 07.09.2011 04:21, Mikael Fridh wrote: Resizing from any smaller size to a larger size initially uses up the whole disk, like if -s was not used at all even if it's as little as one logical disk block. I'm wondering if anyone else can reproduce. Also, can you show the output of this command: # diskinfo -v ada0 -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: FreeBSD 9.0-BETA2 invalid ada0 layout prevents installation
On 08.09.2011 20:13, Willem Jan Withagen wrote: This however results in that I can not find any normal way in the guided and expert config menus to actual tell it to use the whole disk for a new fresh FreeBSD install. it keeps complaining Operation not permitted 'ada0 table is corrupt' Do you mean new FreeBSD installer? Only way to proceeds seems to be is to go to shell, dd /dev/zero over the first few blocks and then restart Not shure that many people that end up using a ZFS old disk, also do not know how to fix this. But then again, what is there is another corrupt GPT setup on the disk... If your partition table marked as corrupt, you can only destroy or recover it. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0-BETA3 can't boot with USB enabled
On 29.09.2011 10:23, Andrey V. Elsukov wrote: On 23.06.2011 11:54, O. Hartmann wrote: FreeBSD 9.0-CURRENT/amd64 won't boot anymore. The box gets stuck in booting the kernel and ending up with the message (repeated every 60 seconds): run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config I tried to install 9.0-BETA3 to HP Compaq DX7500 and this problem appeared again. I turned off the USB support from the BIOS and after that i installed the system. Now, when i turned on the USB support the kernel could not boot. Can someone suggest something? I'm sorry, but it seems the cause is not in the USB. The kernel could boot with USB enabled after i have disabled firewire. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
9.0-BETA3 can't boot with USB enabled (was: kernel broken: run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config)
On 23.06.2011 11:54, O. Hartmann wrote: FreeBSD 9.0-CURRENT/amd64 won't boot anymore. The box gets stuck in booting the kernel and ending up with the message (repeated every 60 seconds): run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config I tried to install 9.0-BETA3 to HP Compaq DX7500 and this problem appeared again. I turned off the USB support from the BIOS and after that i installed the system. Now, when i turned on the USB support the kernel could not boot. Can someone suggest something? -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Create a gpart in a multipath container?
On 30.09.2011 18:51, John wrote: Apologies for the long-winded explanation. I hope it made sense. Is there a way to make this work? Is there a better way to configure this? I'd like the partitions to be protected by multipathing which lead me to try this. Am I missing something totally obvious? I've been looking at the code and I'm thinking there is an issue between a real physical disk container vs a partition and sizing. Any comments are appreciated. Do you have loaded geom_multipath module after reboot? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: RFC: Project geom-events
On 04.10.2011 22:05, Lev Serebryakov wrote: So, here it is. GEOM Events. Project consists of several parts (all are ready and commited to project branch!): Hi, Lev (5) Changes in all geom classes to post these events. It seems that you could change only geom_dev.c to get most of what you want. Actually, the part of your changes related to the DISCONNECT events, and maybe DESTROY events could be implemented in the geom_dev. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFC: Project geom-events
On 05.10.2011 10:39, Lev Serebryakov wrote: (1) Class and name of GEOM which is affected. (2) Name of provider which is affected. (3) Name of underlying provider which is lost (consumer from reporting GEOM's point of view). (4) Resulting state of affected provider (fixable, alive, dead). All except last could be get from the consumer in the orphan method. And, I'm affraid, that geom_dev could not distinguish manual operations with geom (performed from userland by administrator) and real accidents. I don't want geoms to post DISCONNECTED or DESTROYED events when administrator knows what he does -- and it could lead to race conditions, when administrator rebuild array and forgot todisable spare drives, for example. Other example -- geom_label creates and destroys about 10 labels on boot (on my test VM) and, if DESTROYED will be reported by very generic mechanism, it will end up with 10 e-mails to administrator on every boot -- I've got this, when put notifications in too generic place for first try. Ok, good point. Can you explain how your script will distinguish which actions are performed by administrator? Since change made by administrator could trigger disappearing of several child geoms. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFC: Project geom-events
On 06.10.2011 16:36, Ivan Voras wrote: 2) this makes the device unbootable as the GPT partition is per definition not valid. It still stores the primary partition table on the first sector (and the following sectors...), but its secondary table is stored at one sector short of device's last sector (which is used by glabel). Any utilities and BIOSes which test for GPT will find the first table but not the last and depending on how sensitive / broken they are, they will either recognize a broken GPT (and/or try to fix it, destroying the glabel label), or not work at all. Actually we support booting from GPT when secondary GPT header is not in the last LBA. Our bootcode will complain in this situation, but it works. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: aliasing (or renaming) kern.geom.debugflags
On 07.10.2011 22:53, Warren Block wrote: The current documentation is sysctl kern.geom.debugflags=16 dd if=memstick.img of=/dev/whatever0 bs=64k Did you try just write your image without debugflags settings? When /dev/whatever0 is not used nothing should prevent you write your image. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: aliasing (or renaming) kern.geom.debugflags
On 07.10.2011 23:41, Glen Barber wrote: In my experience, without kern.geom.debugflags=16, the MBR will not be written to the memstick, leaving you with what would effectively be a coaster in the not-so-distant past. The problem is that this bad suggestion is everywhere in the Internet. And users use it always even when it not needed. I think it is bad idea add it in the our official documentation. When you doing all in the right way using debugflags=16 is not needed. And it is really dangerous when you doing something what you do not know exactly. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: aliasing (or renaming) kern.geom.debugflags
On 24.10.2011 1:54, Arnaud Lacombe wrote: NOTE Protection mechanisms in the geom(4) subsystem might prevent boot0cfg from being able to update the MBR on a mounted disk. Instructions for temporarily disabling these protection mechanisms can be found in the geom(4) manpage. Specifically, do a sysctl kern.geom.debugflags=0x10 to allow writing to the MBR, and restore it to 0 afterwards. This is stale message. boot0cfg might work without this. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: aliasing (or renaming) kern.geom.debugflags
On 25.10.2011 5:18, Benjamin Kaduk wrote: to allow writing to the MBR, and restore it to 0 afterwards. This is stale message. boot0cfg might work without this. On a *mounted* disk? Surely that qualifies as an open for the purposes of the check. Yes. boot0cfg uses GEOM_PART' control interface and it may write bootcode to the open disk. Actually i found bug here and now it is fixed in r226714. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: aliasing (or renaming) kern.geom.debugflags
On 25.10.2011 10:08, Poul-Henning Kamp wrote: The way this used to work before gpart, is that boot0cfg would send a GEOM ctl-message to the MBR-geom asking Would you please write this boot code ? Since the MBR-geom was the owner of the whole disk, and the one who had it open for writing, it could obviously do so, if it saw fit, and after it had edited its idea about the mbr-partition table into that boot-code. Gpart appearantly does not implement such a ctl message. gpart does it in the same way. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: gmirror failed with error 19.
On 28.10.2011 13:48, Sascha Klauder wrote: I've got bitten by this as well when trying a source up- grade of a freshly installed 8.2-RELEASE system that had gmirror configured after installation according to the procedure in the Handbook. The 9.0-RC1 kernel drops to the mountroot prompt when booting with GEOM_MIRROR: Device mirror/gm0 launched (2/2). GEOM_PART: partition 1 has end offset beyond last LBA: 490350671 490350670 GEOM_PART: integrity check failed (mirror/gm0, MBR) This is the main problem. Your MBR' slice is bigger than actual space you have. The only way to fix this - recreate slice. You can break your mirror, recreate the slice (NOTE: you must preserve one sector for the gmirror's meta-data), then copy your data to the newly created slice, then reboot from the new slice and recreate mirror. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [Call for reviews] Support domain-search option in dhclient(8)
On 12.11.2011 20:07, Jean-Sébastien Pédron wrote: Attached is a patch that adds support for domain-search option (#119) as defined in RFC 3397[1]. This allows a DHCP server to publish a list of domain names that should be used to search for non-fully qualified domain names. There's already a PR opened about this: http://www.freebsd.org/cgi/query-pr.cgi?pr=151940 With this patch applied and a DHCP server configured to publish this option, dhclient(8) will add a line similar to the following one: search example.org. foobar.com. In the example, this indicates that the name www should be resolved first as www.example.org, then as www.foobar.com. I prepared a regression test to be added to tools/regression (not included). However, I'm not knowledgeable enough to anticipate all security-related issues. I would appreciate a review especially with this in mind :) Hi, I have several questions after a quick view of your patch: 1. AFAIR, our dhclient was doing changes in the system configuration via dhclient-script, but i don't see that your changes touched it. 2. Your code handles compressed options. It's good. But it seems you don't check names correctness. There were some checks for domain-name option, probably you can use them. 3. Also it would be good to update man pages :) -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: CFR: backup GPT header support in pmbr and loader(8) (Re: Handbook mirroring section)
On 10.06.2012 17:48, Hiroki Sato wrote: ae Yes, i also have thought about this and this should work for most GEOM classes, ae but i revised again PMBR code and it seems that it will not work anyway :) ae Our PMBR doesn't use backup GPT header and table, and it doesn't verify ae correctness of primary GPT. ae ae From the other side, there are three situations when we use GPT: ae 1. FreeBSD is only one system on the disk and we use PMBR and gptboot to boot it. ae ae In case if we will fix PMBR your patch will help. I created the attached patchset for the loader and pmbr to support backup GPT header when the primary one is corrupted. Can anyone test and/or review it? The pmbr program now checks the GPT signature, and if failed it tries to search the backup header from the last LBA. When GEOM metadata is found at the last LBA, the second last will be checked. The loader(8) program also supports the same algorithm to search the backup header. Hi, I have tested your patch and discovered yet another problem. Actually the loader(8) doesn't read backup GPT header and table and this stops booting when primary header or table damaged (pmbr and gptboot works as expected in this case). The libi386/biosdisk.c should be modified to add this support. Also, our PMBR image doesn't contain any partition entries and writing it to the disk with dd(1) makes the system unbootable. What you think if we will add one partition entry to the PMBR image? I modified your patch (the last hunk added) and it is attached. -- WBR, Andrey V. Elsukov Index: head/sys/boot/i386/pmbr/pmbr.s === --- head/sys/boot/i386/pmbr/pmbr.s (revision 237056) +++ head/sys/boot/i386/pmbr/pmbr.s (working copy) @@ -42,8 +42,9 @@ .set STACK,EXEC+SECSIZE*4 # Stack address .set GPT_ADDR,STACK # GPT header address .set GPT_SIG,0 - .set GPT_SIG_0,0x20494645 - .set GPT_SIG_1,0x54524150 + .set GPT_SIG_0,0x20494645 # EFI + .set GPT_SIG_1,0x54524150 # PART + .set GEOM_MAGIC,0x4d4f4547 # GEOM .set GPT_MYLBA,24 .set GPT_PART_LBA,72 .set GPT_NPART,80 @@ -52,6 +53,8 @@ .set PART_TYPE,0 .set PART_START_LBA,32 .set PART_END_LBA,40 + .set DPBUF,PART_ADDR+SECSIZE + .set DPBUF_SEC,0x10 # Number of sectors .set NHRDRV,0x475 # Number of hard drives @@ -91,16 +94,40 @@ main: cmpb $0x80,%dl # Drive valid? jb main.2 # Yes main.1:movb $0x80,%dl # Assume drive 0x80 # -# Load the primary GPT header from LBA 1 and verify signature. +# Load the GPT header and verify signature. Try LBA 1 for the primary one and +# the last LBA for the backup if it is broken. Skip the LBAs if GEOM +# metadata found at the backup location. # -main.2:movw $GPT_ADDR,%bx +main.2:call getdrvparams # Read drive parameters + movb $1,%dh # %dh := 1 (reading primary) +main.2a: movw $GPT_ADDR,%bx movw $lba,%si - call read + call read # Read header and check GPT sig cmpl $GPT_SIG_0,GPT_ADDR+GPT_SIG - jnz err_pt + jnz main.2b cmpl $GPT_SIG_1,GPT_ADDR+GPT_SIG+4 - jnz err_pt + jnz main.2b + jmp load_part +main.2b: cmpb $1,%dh # Reading primary? + je main.3 # Try backup if yes + cmpl $GEOM_MAGIC,GPT_ADDR # GEOM sig at backup location? + jz main.3 # Skip GEOM metadata + jmp err_pt # Invalid table found # +# Try alternative LBAs from the last sector for the GPT header. +# +main.3:movb $0,%dh # %dh := 0 (reading backup) + movw $DPBUF+DPBUF_SEC,%si # %si = last sector + 1 + movw $lba,%di # %di = $lba + cmpl $0,(%si) # + jnz main.3a # + decl 0x4(%si) # 0x4(%si) = last sec (32-64) +main.3a: decl (%si) # 0x0(%si) = last sec (0-31) + movw $2,%cx + rep + movsw # $lastsec--, copy it to $lba + jmp main.2a # Read the next sector +# # Load a partition table sector from disk and look for a FreeBSD boot # partition. # @@ -172,6 +199,16 @@ read: pushl 0x4(%si) # Set
Re: CFR: backup GPT header support in pmbr and loader(8) (Re: Handbook mirroring section)
On 14.06.2012 17:08, Olivier Smedts wrote: 2012/6/14 Andrey V. Elsukov a...@freebsd.org: Also, our PMBR image doesn't contain any partition entries and writing it to the disk with dd(1) makes the system unbootable. What you think if we will add one partition entry to the PMBR image? I modified your patch (the last hunk added) and it is attached. Isn't it gpart(8)'s job to write the proper boot code from the pmbr image without damaging the partition table ? ie. gpart bootcode -b /boot/pmbr ada0 instead of using dd. gpart(8) works only when GPT's geom exists, when PMBR is damaged GEOM_PART_GPT can't detect GPT and thus you can't use it. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: CFR: backup GPT header support in pmbr and loader(8) (Re: Handbook mirroring section)
On 14.06.2012 20:05, Olivier Smedts wrote: gpart(8) works only when GPT's geom exists, when PMBR is damaged GEOM_PART_GPT can't detect GPT and thus you can't use it. IMO, GEOM_PART_GPT should not depend on the MBR do detect GPT. That's the problem which should be fixed ; adding a partition to the MBR is only a workaround (and what would happen if the sector 0 was permanently damaged on disk ?). Why does GEOM_PART_GPT depends on the sector LBA 0 while the GPT header is located at sector LBA 1 ? Don't know the feasability of this, just saying... :-) When the GPT disk layout is used the disk should contain a Protective MBR at the LBA 0. This is by the UEFI standard. The protective MBR contains one partition record with the type 0xEE, this partition covers the entire space on the disk after the PMBR. The remaining partition records shall each be set to zeros. When the disk capacity exceeds LBA 0x this value is used in the size field of PMBR record. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: minor GEOM disk API change coming
On 21.06.2012 08:29, Kenneth D. Merry wrote: Fix a bug which causes a panic in daopen(). The panic is caused by a da(4) instance going away while GEOM is still probing it. In this case, the GEOM disk class instance has been created by disk_create(), and the taste of the disk is queued in the GEOM event queue. While that event is queued, the da(4) instance goes away. When the open call comes into the da(4) driver, it dereferences the freed (but non-NULL) peripheral pointer provided by GEOM, which results in a panic. I think this situation is very specific for the GEOM_DISK class, and this callback will be less useful for other classes. Does g_cancel_event() cannot help you prevent tasting? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: minor GEOM disk API change coming
On 21.06.2012 20:48, Kenneth D. Merry wrote: In this case, the GEOM disk class instance has been created by disk_create(), and the taste of the disk is queued in the GEOM event queue. While that event is queued, the da(4) instance goes away. When the open call comes into the da(4) driver, it dereferences the freed (but non-NULL) peripheral pointer provided by GEOM, which results in a panic. I think this situation is very specific for the GEOM_DISK class, and this callback will be less useful for other classes. Does g_cancel_event() cannot help you prevent tasting? Calling g_cancel_event(), for instance from disk_gone(), would not completely close the race condition. It can't cancel an event that is already in progress, and it is possible for the peripheral to go away while the event is marked in progress but before the taste gets far enough into daopen() to acquire a reference to the peripheral. If i understand correctly your patch, you acquires a reference to the periph and release it when g_destroy_provider finished. What if you will queue some custom event from the disk_gone() that will call cddiskgonecb()? Does it close the race? This event will be executed after the taste completes. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
[CFC/CFT] large changes in the loader(8) code
Hi All, Some time ago i have started reading the code in the sys/boot. Especially i'm interested in the partition tables handling. I found several problems: 1. There are several copies of the same code in the libi386/biosdisk.c and common/disk.c, and partially libpc98/biosdisk.c. 2. ZFS probing is very slow, because the ZFS code doesn't know how many disks and partitions the system has: http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 http://www.freebsd.org/cgi/query-pr.cgi?pr=161897 3. The GPT support doesn't check CRC and even doesn't know anything about the secondary GPT header/table. So, i have created the branch and committed the changes: http://svnweb.freebsd.org/base/user/ae/bootcode/ The patch is here: http://people.freebsd.org/~ae/boot.diff What i already did: 1. The partition tables handling now is machine independent, and it is compatible with the kernel's GEOM_PART implementation. There is new API for disk drivers in the loader to get information about partitions and tables: common/Makefile.inc common/part.c common/part.h 2. The similar and general code from the disk drivers merged in the disk.c: common/disk.c common/disk.h i386/libi386/libi386.h i386/libi386/biosdisk.c userboot/test/test.c userboot/userboot/userboot_disk.c userboot/userboot.h 3. ZFS code now uses new API and probing on the systems with many disks should be greatly increased: zfs/zfs.c i386/loader/main.c 4. The gptboot now searches the backup GPT header in the previous sectors, when it finds the GEOM:: signature in the last sector. PMBR code also tries to do the same: common/gpt.c i386/pmbr/pmbr.s 5. Also the pmbr image now contains one fake partition record. When several first sectors are damaged the kernel can't detect GPT (see RECOVERING section in the gpart(8)). We can restore PMBR with dd(1) command, but the old pmbr image has an empty partition table and loader doesn't able to boot from GPT, when there is no partition record in the PMBR. Now it will be able. When pmbr is installed via 'gpart bootcode' command, the kernel correctly modifies this partition record. So, this is only for the first rescue step. 6. I have changed userboot interface. I guess there is none consumers except the one test program. But if it isn't that, i can make it compatible. Any comments are welcome. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [CFC/CFT] large changes in the loader(8) code
On 26.06.2012 16:57, Pawel Jakub Dawidek wrote: On Tue, Jun 26, 2012 at 04:50:36PM +0400, Andrey V. Elsukov wrote: Hi All, Some time ago i have started reading the code in the sys/boot. Especially i'm interested in the partition tables handling. I found several problems: 1. There are several copies of the same code in the libi386/biosdisk.c and common/disk.c, and partially libpc98/biosdisk.c. 2. ZFS probing is very slow, because the ZFS code doesn't know how many disks and partitions the system has: http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 http://www.freebsd.org/cgi/query-pr.cgi?pr=161897 3. The GPT support doesn't check CRC and even doesn't know anything about the secondary GPT header/table. Just a quick note here. At some point when I was adding GPT attributes to allow for test starts I greatly improved, at least parts of, the GPT implementation. I did implement support for both CRC checksum verification and fallback to backup GPT header when primary is broken. And the code is still in sys/boot/common/gpt.c. So my question would be what do you mean by this sentence? Yes, gptboot does that, but the loader/zfsloader doesn't. So there might be a situation when gptboot does boot, but loader(8) can't. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [CFC/CFT] large changes in the loader(8) code
On 26.06.2012 21:37, John Baldwin wrote: 4. The gptboot now searches the backup GPT header in the previous sectors, when it finds the GEOM:: signature in the last sector. PMBR code also tries to do the same: common/gpt.c i386/pmbr/pmbr.s GPT really wants the backup header at the last LBA. I know you can set it, but I've interpreted that as a way to see if the primary header is correct or not. It seems to me that GPT tables created in this fashion (inside a GEOM provider) will not work properly with partition editors for other OS's. I'm hesitant to encourage the use of this as I do think putting GPT inside of a gmirror violates the GPT spec. The standard says: The following test must be performed to determine if a GPT is valid: • Check the Signature • Check the Header CRC • Check that the MyLBA entry points to the LBA that contains the GUID Partition Table • Check the CRC of the GUID Partition Entry Array If the GPT is the primary table, stored at LBA 1: • Check the AlternateLBA to see if it is a valid GPT If the primary GPT is corrupt, software must check the last LBA of the device to see if it has a valid GPT Header and point to a valid GPT Partition Entry Array. For the FreeBSD an each GEOM provider can be treated as disk device. So, i don't see anything criminal if we will add some quirks in the our loader for the better supporting of our technologies. If a user wants modify GPT in the disk editor from the another OS, he can do it, and it should work. The result depends only from the partition editor, it might overwrite the last sector and might don't. 5. Also the pmbr image now contains one fake partition record. When several first sectors are damaged the kernel can't detect GPT (see RECOVERING section in the gpart(8)). We can restore PMBR with dd(1) command, but the old pmbr image has an empty partition table and loader doesn't able to boot from GPT, when there is no partition record in the PMBR. Now it will be able. When pmbr is installed via 'gpart bootcode' command, the kernel correctly modifies this partition record. So, this is only for the first rescue step. As I said earlier, I do not think this is appropriate and that instead gpart should have an appropriate 'recover' command to install just the pmbr on a disk and also create a correct entry in the MBR if needed while doing so. gpart(8) is only one of several geom(8)' tools to manage objects of a GEOM class. It only sends control requests to the kernel. If GPT is not detected, there is no geom objects to manage. And we can't write bootcode with gpart(8). I think that adding such functions to the gpart(8) is not good. Maybe, the boot0cfg is the better tool for that. Also we still haven't any tool to install zfsboot. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [CFC/CFT] large changes in the loader(8) code
On 27.06.2012 1:41, Kevin Oberman wrote: Long ago I saw a proposal to create a dedicated partition on GPT to hold the metadata. With the large number of partitions available on GPT, tying up one just for GEOM seems like a low price and it moves the device GEOM out of the realm of FreeBSD unique and subject to serious issues when/if a disk is shared with some other OS. I have seen little comment on this and have never seen any argument that that it could not work. When you share some disk with another OS, it seems that much serious issue will be when other OS did some changes in your mirror without you knowing. I know about successful sharing of the disk between Windows and FreeBSD via graid on the Intel pseudo raid. Just use compatible technologies. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [CFC/CFT] large changes in the loader(8) code
On 27.06.2012 16:07, John Baldwin wrote: • Check the Signature • Check the Header CRC • Check that the MyLBA entry points to the LBA that contains the GUID Partition Table • Check the CRC of the GUID Partition Entry Array If the GPT is the primary table, stored at LBA 1: • Check the AlternateLBA to see if it is a valid GPT If the primary GPT is corrupt, software must check the last LBA of the device to see if it has a valid GPT Header and point to a valid GPT Partition Entry Array. Right, we break the last rule. If you want to use a partition editor that doesn't grok gmirror (because you are using another OS's editor), to repair a GPT, it will do the wrong thing. When we are in the FreeBSD, our loader can detect that device size is lower than it see and it will work. When primary header is OK, then other OSes should work with this GPT. When it isn't OK, you just can't load other OS :) As I said earlier, I do not think this is appropriate and that instead gpart should have an appropriate 'recover' command to install just the pmbr on a disk and also create a correct entry in the MBR if needed while doing so. gpart(8) is only one of several geom(8)' tools to manage objects of a GEOM class. It only sends control requests to the kernel. If GPT is not detected, there is no geom objects to manage. And we can't write bootcode with gpart(8). I think that adding such functions to the gpart(8) is not good. Maybe, the boot0cfg is the better tool for that. Also we still haven't any tool to install zfsboot. We can't write bootcode with gpart? What do you think the 'bootcode' command does? `gpart bootcode -b` reads file, creates ioctl request and sends this data to the GEOM_PART class. GEOM_PART receives the control request, checks the data and writes it to the provider. `gpart bootcode -p` works like dd(1) and writes bootcode to the given partition. gpart(8) haven't any knowledge about specific partitioning scheme. Also, there is no reason we can't have a 'recover' command that attempts to recover a corrupted table including repairing the PMBR. gpart(8) already generates a full PMBR when you use 'gpart create' to create a GPT even though there isn't a GPT object yet. `gpart create` creates only ioctl control request to the GEOM_PART class. GEOM_PART class creates new GPT geom object and this objects writes PMBR and its metadata to the provider. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFC/CFT] large changes in the loader(8) code
On 27.06.2012 21:55, Marcel Moolenaar wrote: You can't just re-interpret standards to match a context you know very well isn't applicable and consequently redefine what the word device means. You're on a slippery slope and while you may not see it as a problem, you do make it a problem for FreeBSD users. It's our users we should be keeping in mind when we solve problems. If a user wants modify GPT in the disk editor from the another OS, he can do it, and it should work. The result depends only from the partition editor, it might overwrite the last sector and might don't. Right. Another happy user that sees his/her FreeBSD installation destroyed or degraded (no mirroring, warning messages about corrupted GPT, etc) for no apparent reason and without any kind of warning that what he/she is doing is potentially harmful... That's the spirit! Ok. Let's return back to my patches. They don't add any new methods to shoot in the foot. We are talking about the *FreeBSD loader*. This is the program that starts FreeBSD kernel. It doesn't start other OS. We already have many users who uses FreeBSD as a single system on the machine. Many of them use GPT inside of some GEOM provider. You can just read the lists, articles about installing FreeBSD, forums, etc. We already have these users and i hope they will use FreeBSD as before. So, why can't add a simple quirk to make theirs system a bit more reliable? As i understand there two parts where we haven't a consensus: 1. You are against from: Our loader detects that primary GPT header is damaged. It tries to read backup GPT header from the last LBA and it detects that there is GEOM:: signature. It tries to read one previous sector and there is *valid* GPT header. It is valid, because it's CRC is valid, it's self_LBA is valid. For the *FreeBSD* users it is better to don't use this GPT and just complain i'm sorry, can't boot. The other OSes can't, and we shouldn't. 2. You are against from having one fake PMBR entry by default in the /boot/pmbr image. Ok, I can propose several ways to resolve this: * remove from the loader's GPT probing code restriction to necessarily have PMBR partition record in the MBR; * teach the boot0cfg command properly write the PMBR; * add new condition to mark GPT as corrupt when it has invalid PMBR. Thus, when you write PMBR with empty partition table with dd(1), the kernel will complain and you will be forced to run `gpart recover`. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [CFC/CFT] large changes in the loader(8) code
On 28.06.2012 00:14, Marcel Moolenaar wrote: Our loader detects that primary GPT header is damaged. It tries to read backup GPT header from the last LBA and it detects that there is GEOM:: signature. It tries to read one previous sector and there is *valid* GPT header. How do you know it's valid? It's in a location that is not valid to begin with. Validity is based on rules and you're violating the the rules without defining exactly what we call valid given the new rules. This may seem nitpicking, but having went through the hassle of dealing with the broken way we created the dangerously dedicated disk, I appreciate the importance of being anal when it comes to something that lives on non-volatile storage and gets to be exposed to a world much larger than FreeBSD. So why do you not prevent to attach GEOM_PART_GPT to any providers that are not the disk drive? This will be the right solution to all our problems. Just don't create invalid GPT. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFC/CFT] large changes in the loader(8) code
On 28.06.2012 13:19, Boris Samorodov wrote: 27.06.2012 23:27, Andrey V. Elsukov пишет: 1. You are against from: Our loader detects that primary GPT header is damaged. It tries to read backup GPT header from the last LBA and it detects that there is GEOM:: signature. It tries to read one previous sector and there is *valid* GPT header. Can we do the other way round? I.e. the GPT header is at the last sector. And if GEOM singature is not found at last sector of the disk and this sector is a GPT header then look at the previous sector? Then this sector contains GPT table. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFC/CFT] large changes in the loader(8) code
On 28.06.2012 14:35, Wojciech Puchar wrote: Just modify GEOM classes that keep state at the end of a partition to leave some spare area *behind* the GEOM data. I.e.: what is really a problem aat all? just leave as is. If someone want's use gpart and mirror then mirroring every partition is simpler. usually not every partition needs to be mirrored. or mirror a whole and make gpart in it, it should still boot fine. I already reverted changes related to the GPT and GEOM metadata detection. even better - update bsdlabel to work with 2TB devices. MUCH better. DragonFlyBSD has disklabel64 partitioning scheme. Make a port is simple task. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFC/CFT] large changes in the loader(8) code
On 28.06.2012 15:36, Boris Samorodov wrote: 28.06.2012 14:10, Stefan Esser пишет: All of the above is ugly, U'm afraid :( One more try to overcome it. :-) We already have freebsd-boot partition at GPT scheme. Right? Then why not use it (dedicated file/part/etc.) to store geom FreeBSD information? Recently i have ported LDM support to the FreeBSD. LDM uses 1Mbytes to store its database. All disks that are used by LDM have this database. When the disk is partitioned with MBR, LDM is stored in the last 1Mbyte. When the disk is partitioned with GPT, one partition is dedicated to this database. LDM is not just partitioning scheme, it is also LVM and can do RAID0-5. This is how Microsoft and Veritas have resolved this problem. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFC/CFT] large changes in the loader(8) code
On 29.06.2012 15:01, Jan Beich wrote: So, i have created the branch and committed the changes: http://svnweb.freebsd.org/base/user/ae/bootcode/ The patch is here: http://people.freebsd.org/~ae/boot.diff FWIW, I verified it compiles OK with clang, and especially boot2's size isn't increased at all. Does it boot for you? Same if I build zfs.c with gcc -O0: FreeBSD/x86 ZFS enabled bootstrap loader, Revision 1.1 (foo@bar, Tue Jun 26 18:52:52 UTC 2012) ZFS: can't find pool by guid ZFS: can't find pool by guid can't load 'kernel' Does zfsloader without patches compiled with CLANG work for you? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [CFC/CFT] large changes in the loader(8) code
On 16.07.2012 14:23, Andriy Gapon wrote: on 26/06/2012 15:50 Andrey V. Elsukov said the following: 3. ZFS code now uses new API and probing on the systems with many disks should be greatly increased: zfs/zfs.c i386/loader/main.c First of all, it's hard to parse the above sentence. probing ... should be greatly increased. Probing what? :-) If probing time, then we don't want that ;-) I looked through the ZFS-related part and here are a few comments: Thanks for that. 1. I think that the predominant indentation style of i386/loader/main.c should be preserved for consistency. 2. I am not sure if I like the approach of moving partition tasting code into common ZFS code (zfs.c). On one hand, it now makes sense because the new partition iteration code is machine-independent. On the other hand, the reason that I added arch_zfs_probe method was to give platforms full control over which partitions and in what order are probed. It seems to be important for some of them. So, I like how your new partition interface makes it much easier to ZFS-probe partitions, but I would prefer to have that code in arch_zfs_probe implementations rather than in zfs_probe_dev. From the other point of view, ZFS is not a just file system and it works directly with disks and partitions. And it seems to me this code will be common for other architectures. 3. Related to the above. In what shape is sparc64 ZFS support in your branch? Have you tried to adapt it to the new model too? It's the platform that has special requirements for disk/partition probing order. Marius can help with additional information and testing here. Currently i have not received any feedback reports from the users who can test patches on the other architectures. I added VTOC8 support to the part.c, but it seems it is not needed and ofw can work without this. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [CFC/CFT] large changes in the loader(8) code
On 16.07.2012 15:05, Andriy Gapon wrote: 2. I am not sure if I like the approach of moving partition tasting code into common ZFS code (zfs.c). On one hand, it now makes sense because the new partition iteration code is machine-independent. On the other hand, the reason that I added arch_zfs_probe method was to give platforms full control over which partitions and in what order are probed. It seems to be important for some of them. So, I like how your new partition interface makes it much easier to ZFS-probe partitions, but I would prefer to have that code in arch_zfs_probe implementations rather than in zfs_probe_dev. From the other point of view, ZFS is not a just file system and it works directly with disks and partitions. And it seems to me this code will be common for other architectures. Well, it seems that you haven't yet touched sparc64_zfs_probe. Yes. It should work as before. But if Marius can suggest how to change ofw_disk.c to get disk size and sector size, then i will be able to break something here :) If you'll find that you don't have to use any ugly hacks there, then good. But my impression is that it would be easier to stick to the previous approach. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [CFC/CFT] large changes in the loader(8) code
On 16.07.2012 15:31, Andriy Gapon wrote: Yes. It should work as before. Well, but it's obvious that zfs_probe_dev would be attempting to do some unneeded stuff (trying to treat partitions as disks) for that case. To me this is a clear indication zfs_probe_dev is not optimal for arch-independent implementation. So I still think that arch_zfs_probe should decide what disks and partitions to probe, and zfs_probe_dev should only probe what it's given and not try to be any smarter. But I've repeated myself three times already :-) And we will have the same - several copies of the same code in each architecture, which i have deleted... Sparc doesn't support DIOCGMEDIASIZE and DIOCGSECTORSIZE ioctls, so it will not check each partition, only fd that is passed to the zfs_probe_dev. Currently there is only one problem with ZFS tasting, that can affect users - now we taste each disk and partition, but in the my branch ZFS tastes only disks and partitions with type freebsd and freebsd-zfs. So if you have created ZFS on top of MBR partition with type ntfs, then loader will be unable to detect it. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
[Request for review] loader changes
Hi, All.
It's been a long ago, when i published my patches first time.
And it seems, there is no one who is against or wants suggest something.
So I'm asking for review, and I want start merge changes at the end of week.
Patches are here: http://people.freebsd.org/~ae/bootcode/
full.diff:
The full diff, except tools.
tools.diff:
A small test program bootparttest. It uses sys/boot/common/part.c to
taste GEOM provider or disk image in the similar way, how loader does.
common.diff:
Changes to the common code. This code is used with many architectures and
libraries.
* common/Makefile.inc
added LOADER_NO_DISK_SUPPORT knob to disable build common code related to
disks and
partitions. By default GPT and MBR support are enabled, LOADER_NO_GPT_SUPPORT
and
LOADER_NO_MBR_SUPPORT can disable they.
* common/part.c
common/part.h
these files are new. They contains partition tables related code. Several
words about API:
Partition table described with opaque type struct ptable, partition entries
with
struct ptable_entry {
uint64_tstart;
uint64_tend;
int index;
enum partition_type type;
};
The partition tables detection occurs when ptable_open() is called. This
function takes
as arguments the number of disk sectors, sector size and pointer to the
callback
function, that is know how to read from the disk.
The ptable_close() function releases allocated resources.
The ptable_gettype() functions returns the type of partition table.
The ptable_getpart() functions returns information about specified partition.
The ptable_iterate() functions calls a callback function for each partition
in the table.
The parttype2str() converts partition type to the string.
The following partition tables are supported: BSD label, GPT, MBR, EBR and
VTOC8.
* common/disk.c
common/disk.h
These files have been changed and they use new API to work with partitions.
Also now
they provide new disk API to the devsw disk drivers: disk_open(),
disk_close(),
disk_print(), disk_fmtdev() and disk_parsedev().
i386.diff:
Changes related to the i386 architecture:
* i386/libi386/devicename.c
Use disk_fmtdev() and disk_parsedev() functions from the common code.
* i386/libi386/biosdisk.c
The disk driver was rewritten to use new disk API. To the devsw ioctl handler
was added.
It handles DIOCGSECTORSIZE and DIOCGMEDIASIZE ioctls.
* i386/libi386/libi386.h
The offset field was added to the i386_devdesc.d_kind.biosdisk structure.
* i386/libi386/Makefile
removed unneeded flag.
* i386/pmbr/pmbr.s
Added secondary GPT support.
* i386/loader/main.c
ZFS probing simplified.
* i386/loader/Makefile
removed unneeded flag.
userboot.diff:
The disk driver and sample program updated according to the changes in the
disk.c.
Also new diskioctl callback added.
uboot.diff:
The disk driver was rewritten to use new disk API.
arm.diff:
powerpc.diff:
Added LOADER_NO_DISK_SUPPORT handling to be able build uboot with or without
disk support.
zfs.diff:
Use new partitions API to probe all ZFS partitions in the GPT and BSD partition
tables.
So, if there will not any opinions against these APIs and patches I will start
commit. The first step will be common and userboot code, then - i386 and zfs
parts.
--
WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
Re: geom mirror now rebuilding on every reboot?
On 07.08.2012 04:03, Tom Uffner wrote: GEOM_RAID: Promise: Array Promise Created GEOM_RAID: Promise: Disk ad4 state changed from NONE to SPARE GEOM_MIRROR: Cannot open consumer ad4 (error=1) GEOM_MIRROR: Cannot add disk ad4 to gm0 (error=1) wondering if anyone knew offhand what is going on how to fix it. You can remove options GEOM_RAID from your kernel config. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: zfsloader failure with r239244
On 14.08.2012 21:03, Steve Wills wrote: Any ideas if this is a bug or something wrong with my system would be appreciated. Can you boot with serial console and show what show the `lsdev` command in the loader? And from the running system the output of `gpart show` and `zpool status`. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gptzfsboot problem on HP P410i Smart Array
On 19.08.2012 11:22, Bjorn Larsson wrote: We are having problems with gptzfsboot on a HP DL360 G7 using the P410i Smart Array Controller. I’ve some information on this in the archive on this mailing list that this has supposedly been fixed with revision 227400, by implementing the edd data structure. However we still see the same problem and by adding a printf() in zfsboot.c fixes the problem. Please, let me know if anyone have seen this problem and if there is a fix for it? Hi, what exactly do you have? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Trying current
On 29.09.2012 04:00, Brett wrote: Hi list, I'm getting and old core2duo today to install FreeBSD (hopefully current) on it. Looking in the ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ folder for the last week or so, there have been no snapshots in there. Do they still come out roughly monthly and/or is one likely to appear soon? Hi, There are snapshots created by Hiroki Sato, i use it regularly and they are ok. https://pub.allbsd.org/FreeBSD-snapshots/ -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gpart on macbook air
On 30.09.2012 20:37, Raoul MEGELAS wrote: i installed CURRENT on a macbook air (internal ssd as you know): i noticed the following: 1. on freebsd, deleting a partition with gpart: say gpart delete -i 4 ada0 dammage the osx boot. of cours, booting with a backup disk and repairing the disk make it functional again. any light woukd be appreciated on this topic. Hi, When you are deleting a partition, the kernel completely overwrites the partition table and PMBR area. You can compare first 34 blocks before deletion and after to see what is going on. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gpart on macbook air
On 30.09.2012 23:06, Raoul MEGELAS wrote: When you are deleting a partition, the kernel completely overwrites the partition table and PMBR area. You can compare first 34 blocks before deletion and after to see what is going on. I can understand that, but i would have thought that the deletion of the concerned partition was written preserving others??? something like: - read the gpt table - find the offset - zeroes the partition entry - rewrites the table? is not that logic? if it is not so, i does not understand this behaviour. Hi, Raoul, The kernel has a copy of the partition table in the memory. When you are deleting some partition, it removes the partition entry from the memory, constructs updated GPT header and table, calculates checksums and writes this data into corresponding places. Any way, this should correctly work. My guess is that Apple's boot loader detects some changes and just doesn't want to work. If you think that gpart incorrectly works, please make a copy of first 34 blocks before and after deletion and send them to me. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gptboot rewrite, bootonce, etc.
On 31.01.2012 19:49, Andrey Fesenko wrote: This work if use ZFS? My issues Root on ZFS GPT and boot to ufs partition http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013514.html I test # gpart show = 34 625142381 ada0 GPT (298G) 34128 1 freebsd-boot (64k) 162 26621952 2 freebsd-ufs [bootonce,bootme] (12G) 266221148388608 3 freebsd-swap (4.0G) 35010722 590131693 4 freebsd-zfs (281G) system ada0p2 not boot. Hi, Andrey If you want or plan rewrite boot code, i think it is better to write EFI loader with simple multiboot functionality. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
[RFC, RFT] LDM support (aka Windows Dynamic Volumes)
Hi, All i wrote GEOM_PART_LDM class. It provides basic support of Logical Disk Manager partitioning scheme [1]. Since LDM metadata is not documented i used several articles found in the web and linux implementation as reference [2]. Only generic volumes is supported. Spanned, striped and raid5 configurations aren't implemented. Mirrored volumes also are not shown by default, but they can be accessed when kern.geom.part.ldm.show_mirrors=1 (by your own risk). Currently only LDM on top of MBR is supported. Also only gpart destroy is allowed with LDM scheme. you can compile class without patching, the source code is here: http://people.freebsd.org/~ae/LDM/ [1] http://en.wikipedia.org/wiki/Logical_Disk_Manager [2] http://fxr.watson.org/fxr/source/fs/partitions/?v=linux-2.6 Example: /* da1 and da2 disks without geom_part_ldm module */ # gpart show da1 da2 = 63 104857537 da1 MBR (50G) 63 19851 ms-ldm-data (992k) 2048 2048002 ms-ldm-data [active] (100M) 206848 1046487043 ms-ldm-data (49G) 10482 2048 - free - (1.0M) = 32 2097120 da2 MBR (1.0G) 32 31 - free - (15k) 63 20950411 ms-ldm-data (1G) 2095104 2048 - free - (1.0M) # kldload ./geom_part_ldm.ko # gpart show da1 da2 = 63 104855489 da1 LDM (50G) 63 1985 - free - (992k) 2048 2048001 ntfs (100M) 206848 1046487042 ntfs (49G) = 63 2095041 da2 LDM (1.0G) 63 65 - free - (32k) 128 10240001 ntfs (500M) 1024128 10670082 ntfs (521M) 2091136 3968 - free - (2M) -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [RFC, RFT] LDM support (aka Windows Dynamic Volumes)
On 11.03.2012 23:31, Adrian Chadd wrote: This is awesome! Is it just read-only, or does it allow creation/destruction of LDM volumes? It is read-only, but you can partially destroy LDM metadata on given disk. LDM keeps information about all volumes on each disk, and i guess windows can recover destroyed metadata. It is targeted to get access to some windows partitions. Actually, it is possible make better LDM support in conjunction with GEOM_RAID, but i think we don't need it :) -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC, RFT] LDM support (aka Windows Dynamic Volumes)
On 12.03.2012 11:49, Adrian Chadd wrote: partitions. Actually, it is possible make better LDM support in conjunction with GEOM_RAID, but i think we don't need it :) Hah, I wouldn't say no to being able to modify (correctly) LDM metadat.a i'd also love to see say, read/write Linux LVM support, but that's just me. We have geom_linux_lvm, doesn't it work for you? -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Idea for GEOM and policy based file encryption
On 21.03.2012 13:47, Harald Schmalzbauer wrote: Was such a policy based file encryption control doable with GEOM? Maybe it's easier to make use of existing tools like gpg with GEOM interaction? I don't want to reinvent any file encryption, I just need some automatic encryption (without _mandatory_ interaction) with lowest possible bypass possibilities. It sounds like not a task for GEOM. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Idea for GEOM and policy based file encryption
On 21.03.2012 14:09, Victor Balada Diaz wrote: You would need to modify UFS, or maybe do something like CFS[1]. CFS works as an NFS server and you could modify it to only cipher the needed files. Also you could write a simple FS on FUSE, but last time i checked, our FUSE support had some problems. Yet another link: http://www.arg0.net/encfs -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sysutils/fusefs-kmod problem in CURRENT
On 27.03.2013 07:00, Marcelo/Porks wrote: Sorry, maybe I didnt understand what you said. I tried to use in my kernel conf: options FUSEFS option FUSEFS options fusefs option fusefs But they didnt work. The kernel does not compile. The result is above: Hi, you can just load the kernel module fuse.ko. Fuse is in the base system. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Booting an alternative kernel from loader prompt fails the first time only
On 21.04.2013 04:36, Steven Hartland wrote: This fails and trips the Restart from the beginning case which contains: last_file_format = i = 0; fp = NULL; continue; So i gets set to 0 but the loop then increments it to 1 before running the next iteration, so its impossible to use first handler in the retry case; which I suspect is the kernel loader. This also explains why the second call to boot works as last_file_format is now 0 due to the previous failure. If this is the issue the attached patch should fix it. I can't test it ATM as my current box is at the office and doesn't have remote KVM, so I need to be in front of it. If anyone can confirm this attached patch fixes the problem then I'll get it committed, otherwise I'll test on Monday. Hi, yes, you are right. I just committed this with r249719. Thanks. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: IPSEC crashes after r253088
On 21.07.2013 00:43, Taku YAMAMOTO wrote: After r253088, systems with IPSEC and KSTACK_PAGES 4 crashes on booting into multi-user mode. The crash is due to sysctl -a in /etc/rc.d/initrandom ended up with kernel stack overflow. where type is struct ipsecstat which is 12560 bytes of size (larger than 3 pages) of size when processing net.inet.ipsec.ipsecstats. Hi, Only few fields of struct ipsecstat is used, the rest fields are never updated. We can split it to several structures, or just remove unused fields. What is better? -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: IPSEC crashes after r253088
On 23.07.2013 15:28, Andre Oppermann wrote: On 23.07.2013 09:28, Andrey V. Elsukov wrote: On 21.07.2013 00:43, Taku YAMAMOTO wrote: After r253088, systems with IPSEC and KSTACK_PAGES 4 crashes on booting into multi-user mode. The crash is due to sysctl -a in /etc/rc.d/initrandom ended up with kernel stack overflow. where type is struct ipsecstat which is 12560 bytes of size (larger than 3 pages) of size when processing net.inet.ipsec.ipsecstats. Hi, Only few fields of struct ipsecstat is used, the rest fields are never updated. We can split it to several structures, or just remove unused fields. What is better? Not storing it on the stack? It seems that only about 120 bytes are used from all 12 Kbytes. The old ipsecstat structure was concatenated with newipsecstat some time ago. And in fact, only fields of newipsecstat are used. I see no sense to just waste 12*ncpu Kbytes of memory. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: IPSEC crashes after r253088
On 23.07.2013 15:28, Andre Oppermann wrote:
On 23.07.2013 09:28, Andrey V. Elsukov wrote:
On 21.07.2013 00:43, Taku YAMAMOTO wrote:
After r253088, systems with IPSEC and KSTACK_PAGES 4 crashes on
booting into multi-user mode.
The crash is due to sysctl -a in /etc/rc.d/initrandom ended up with
kernel stack overflow.
where type is struct ipsecstat which is 12560 bytes of size (larger than
3 pages) of size when processing net.inet.ipsec.ipsecstats.
Hi,
Only few fields of struct ipsecstat is used, the rest fields are never
updated. We can split it to several structures, or just remove unused
fields. What is better?
Not storing it on the stack?
Also, I already prepared patch to test.
--
WBR, Andrey V. Elsukov
Index: sys/netinet/sctp_input.c
===
--- sys/netinet/sctp_input.c(revision 253562)
+++ sys/netinet/sctp_input.c(working copy)
@@ -5705,7 +5705,7 @@ sctp_common_input_processing(struct mbuf **mm, int
#ifdef INET
case AF_INET:
if (ipsec4_in_reject(m, inp-ip_inp.inp)) {
- IPSECSTAT_INC(in_polvio);
+ IPSECSTAT_INC(ips_in_polvio);
SCTP_STAT_INCR(sctps_hdrops);
goto out;
}
@@ -5714,7 +5714,7 @@ sctp_common_input_processing(struct mbuf **mm, int
#ifdef INET6
case AF_INET6:
if (ipsec6_in_reject(m, inp-ip_inp.inp)) {
- IPSEC6STAT_INC(in_polvio);
+ IPSEC6STAT_INC(ips_in_polvio);
SCTP_STAT_INCR(sctps_hdrops);
goto out;
}
Index: sys/netinet/tcp_input.c
===
--- sys/netinet/tcp_input.c (revision 253562)
+++ sys/netinet/tcp_input.c (working copy)
@@ -899,12 +899,12 @@ findpcb:
#ifdef IPSEC
#ifdef INET6
if (isipv6 ipsec6_in_reject(m, inp)) {
- IPSEC6STAT_INC(in_polvio);
+ IPSEC6STAT_INC(ips_in_polvio);
goto dropunlock;
} else
#endif /* INET6 */
if (ipsec4_in_reject(m, inp) != 0) {
- IPSECSTAT_INC(in_polvio);
+ IPSECSTAT_INC(ips_in_polvio);
goto dropunlock;
}
#endif /* IPSEC */
Index: sys/netinet/udp_usrreq.c
===
--- sys/netinet/udp_usrreq.c(revision 253562)
+++ sys/netinet/udp_usrreq.c(working copy)
@@ -282,7 +282,7 @@ udp_append(struct inpcb *inp, struct ip *ip, struc
/* Check AH/ESP integrity. */
if (ipsec4_in_reject(n, inp)) {
m_freem(n);
- IPSECSTAT_INC(in_polvio);
+ IPSECSTAT_INC(ips_in_polvio);
return;
}
#ifdef IPSEC_NAT_T
@@ -1294,7 +1294,7 @@ udp4_espdecap(struct inpcb *inp, struct mbuf *m, i
if (minlen m-m_pkthdr.len)
minlen = m-m_pkthdr.len;
if ((m = m_pullup(m, minlen)) == NULL) {
- IPSECSTAT_INC(in_inval);
+ IPSECSTAT_INC(ips_in_inval);
return (NULL); /* Bypass caller processing. */
}
data = mtod(m, caddr_t);/* Points to ip header. */
@@ -1334,7 +1334,7 @@ udp4_espdecap(struct inpcb *inp, struct mbuf *m, i
uint32_t spi;
if (payload = sizeof(struct esp)) {
- IPSECSTAT_INC(in_inval);
+ IPSECSTAT_INC(ips_in_inval);
m_freem(m);
return (NULL); /* Discard. */
}
@@ -1355,7 +1355,7 @@ udp4_espdecap(struct inpcb *inp, struct mbuf *m, i
tag = m_tag_get(PACKET_TAG_IPSEC_NAT_T_PORTS,
2 * sizeof(uint16_t), M_NOWAIT);
if (tag == NULL) {
- IPSECSTAT_INC(in_nomem);
+ IPSECSTAT_INC(ips_in_nomem);
m_freem(m);
return (NULL); /* Discard. */
}
Index: sys/netinet6/ip6_forward.c
===
--- sys/netinet6/ip6_forward.c (revision 253562)
+++ sys/netinet6/ip6_forward.c (working copy)
@@ -120,7 +120,7 @@ ip6_forward(struct mbuf *m, int srcrt)
* before forwarding packet actually.
*/
if (ipsec6_in_reject(m, NULL)) {
- IPSEC6STAT_INC(in_polvio);
+ IPSEC6STAT_INC(ips_in_polvio);
m_freem(m);
return;
}
@@ -182,7 +182,7 @@ ip6_forward(struct mbuf *m, int srcrt)
sp = ipsec_getpolicybyaddr(m, IPSEC_DIR_OUTBOUND,
IP_FORWARDING, error);
if (sp == NULL) {
- IPSEC6STAT_INC(out_inval);
+ IPSEC6STAT_INC(ips_out_inval);
IP6STAT_INC(ip6s_cantforward
Re: Problem updating bootcode on ZFS on root system with MBR
On 20.01.2014 23:32, Thomas Hoffmann wrote: I am running 11.0-CURRENT (r260850) with zfs on root with MBR. After upgrading my 10.0-RELEASE (r260669) system to 11.0-CURRENT (r260850) my zpools reported that they needed to be upgraded. So, I upgraded my zpools and I am attempting to update the bootcode (as required). I managed to get the boot1 stage code updated, but cannot get the boot2 stage code updated. Here is what I have done: # sysctl kern.geom.debugflags=0x10 kern.geom.debugflags: 0 - 16 # dd if=/boot/zfsboot of=/tmp/zfsboot1 count=1 1+0 records in 1+0 records out 512 bytes transferred in 0.014996 secs (34142 bytes/sec) # gpart bootcode -b /tmp/zfsboot1 /dev/ada0s1 bootcode written to ada0s1 # dd if=/boot/zfsboot of=/dev/ada0s1a skip=1 seek=1024 dd: /dev/ada0s1a: Operation not permitted The final dd statement fails with operation not permitted. In all my research, understood the initial sysctl command I ran would prevent this particular error from happening. What do I need to do to get the boot2 code written to /dev/ada0s1a? This will work only if ada0s1a isn't in use. The debugflags trick works only for whole disk, i.e. for geoms with rank=1. Another way is calculate needed offset and write bootcode directly to ada0. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problem updating bootcode on ZFS on root system with MBR
On 21.01.2014 14:45, Andriy Gapon wrote: What do I need to do to get the boot2 code written to /dev/ada0s1a? This will work only if ada0s1a isn't in use. The debugflags trick works only for whole disk, i.e. for geoms with rank=1. Another way is calculate needed offset and write bootcode directly to ada0. And ultimately we should extend our ZFS interface with an ioctl to write a blob to a boot code area of a specified ZFS leaf vdev. This would the right way to install zfsboot. Hi Andriy, do you have some patches to test? :-) -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gpart destroy, zpool destroy, zfs destroy under securelevel 3
On 26.05.2014 17:31, Vladimir Sharun wrote: Hello FreeBSD community, Recently plays with securelevel and what I discover: no chance for data to survive against remote root, except backups of course. Maybe this log can be a proposal for raising securelevel further or include securelevel support against the software which can deal with zfs and GEOM labels ? Hi, if you have root privileges you can just write some random bytes in some places and this will be enough to break your system. So, restricting some gpart's or zpool's actions depending from securelevel looks like protection from kids. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gpart destroy, zpool destroy, zfs destroy under securelevel 3
On 29.05.2014 12:56, Vladimir Sharun wrote: Hello, if you have root privileges you can just write some random bytes in some places and this will be enough to break your system. So, restricting some gpart's or zpool's actions depending from securelevel looks like protection from kids. Having root under securelevel 3 confirmed disallows you to: 1) Direct write to the block devices such as (a)da 2) Change rules and/or shutdown pf 3) Remove system flags such as schg, sunlnk I think your statement true in case of securelevel -1, we're talking about the highest one - 3, which shown in logs. Ok, you are right. But geom_dev restricts access only from user level applications. When GEOM object does access directly via GEOM methods this protection won't work. And it seems it isn't easy to fix, all classes should have own check. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: diskid documentation
On 02.06.2014 01:32, Adam McDougall wrote: Also, I believe it is only in 10.0-RELEASE and higher. Even if your kernel supports it, /dev/diskid will not exist if no hardware is found with supported strings (tested in a VM just now). Probably, they just disappeared like all other labels, when you got access to disk not through the label. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 20.07.2014 18:15, Maxim Khitrov wrote: In my opinion, the way forward is to forget (at least temporarily) the SMP changes, bring pf in sync with OpenBSD, put a policy in place to follow their releases as closely as possible, and then try to reintroduce all the SMP work. I think the latter has to be done upstream, otherwise it'll always be a story of diverging codebases. Furthermore, if FreeBSD developers were willing to spend some time improving pf performance on OpenBSD, then Henning and other OpenBSD developers might be more receptive to changes that make the porting process easier. Even if you just drop current PF from FreeBSD, there is nobody, who want to port new PF from OpenBSD. And this is not easy task, as you may think. Gleb has worked on rewriting PF more than half year. So, return back all improvements after import will be hard enough and, again, nobody want to do it. :) -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: mkimg used to create gpt image, problem booting
On 24.08.2014 06:14, Craig Rodrigues wrote:
Hi,
I did some more experiments, and found that after /boot/loader runs,
if I break into the loader prompt and type lsdev, I would get this:
(1) GPT Disk image which boots under QEMU, made by bsdinstall
==
View from loader
OK lsdev
cd devices:
disk devices:
disk0:BIOS drive A:
disk1:BIOS drive C:
disk1p1: FreeBSD boot
disk1p2: FreeBSD UFS
disk1p3: FreeBSD swap
pxe devices:
View from gpart, after we mdconfig the disk image
= 34 10485693 md0 GPT (5.0G)
34 1281 freebsd-boot (64K)
162 99592962 freebsd-ufs (4.7G)
99594585242883 freebsd-swap (256M)
10483746 1981 - free - (991K)
(2) GPT Disk image which fails to boot under QEMU, made by mkimg
===
View from loader
OK lsdev
cd devices:
disk devices:
disk0:BIOS drive A:
disk1:BIOS drive C:
pxe devices:
View from gpart, after we mdconfig the disk image
= 3 1784944 md1 GPT (872M)
3 321 freebsd-boot (16K)
35 17849122 freebsd-ufs (872M)
This leads me to believe that there is logic in /boot/loader,
which is not in GEOM, that fails to parse the GPT produced by mkimg.
I did some further debugging inside the loader by doing the following.
- I added CFLAGS += -DPART_DEBUG to sys/boot/common/Makefile.inc
- I added DEBUG() statements all over sys/boot/common/part.c
I observed that in sys/boot/common/part.c in the ptbl_gptread() function,
that in this section:
305 ent = (struct gpt_ent *)tbl;
306 size = MIN(hdr.hdr_entries * hdr.hdr_entsz,
307 MAXTBLSZ * table-sectorsize);
308 for (i = 0; i size / hdr.hdr_entsz; i++, ent++) {
309 if (uuid_equal(ent-ent_type, gpt_uuid_unused,
NULL))
310 continue;
ent-ent_type is all 0's, which matches gpt_uuid_unused, so it bails
out of the loop and never adds the gpt partitions to the list of partitions
that the loader can access.
I'm not familiar with the GPT format, nor am I familiar with the
gpt code inside the loader, and how it differs from GEOM.
Do you have any further ideas of where to hunt for the root cause of
the problem?
Yes, the problem is in the ptable_gptread() function. I'll commit the fix.
--
WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
Re: Error 1: gpart create -s GPT ad0
On 12.11.2010 21:47, Ivan Klymenko wrote: http://img80.imageshack.us/i/qemu.png/ Think all options for gpart are correct - what can there be a problem? This was temporary regression and it is fixed now in r215118. In any case it is harmless. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Error 1: gpart create -s GPT ad0
On 12.11.2010 21:47, Ivan Klymenko wrote: I use the alternate installer pc-sysinstall based on FreeBSD 9.0-CURRENT r215176 Hmm, are you sure that your kernel is based on r215176? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Error 1: gpart create -s GPT ad0
On 13.11.2010 10:34, Ivan Klymenko wrote: Hmm, are you sure that your kernel is based on r215176? no doubt! :) Do you use custom ISO image? Can you mount it and show output of command: # ident /mnt/boot/kernel/kernel.symbols | grep g_part.c -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Error 1: gpart create -s GPT ad0
On 13.11.2010 11:25, Ivan Klymenko wrote: Once mounted iso image of my drive to /mnt ident error: /mnt/boot/kernel/kernel.symbols: No such file or directory because this file (kernel.symbols) is really not in the iso image... So, I can not reproduce this error. And I still think that you use older revision and you should rebuild your ISO image with fresh sources. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Error 1: gpart create -s GPT ad0
On 13.11.2010 11:40, Ivan Klymenko wrote: So, I can not reproduce this error. And I still think that you use older revision and you should rebuild your ISO image with fresh sources. well ... but it will take a little time ... Just a note - as you may see from tinderbox's emails at the moment building of fresh current is broken :) -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: breaking the crunchgen logic into a share/mk file
On 08.11.2010 15:31, Adrian Chadd wrote:
I've broken out the crunchgen logic from src/rescue/rescue into a
share/mk file - that way it can be reused in other areas.
The diff is here: http://people.freebsd.org/~adrian/crunchgen-mk.diff
http://people.freebsd.org/%7Eadrian/crunchgen-mk.diff
This bsd.crunchgen.mk file is generic enough to use in my
busybox-style thing as well as for src/rescue/rescue/.
Comments, feedback, etc welcome!
It seems this broke usage of livefs from sysinstall.
sysinstall does check for /rescue/ldconfig and can not find it there.
I think attached patch can fix this issue (not tested).
--
WBR, Andrey V. Elsukov
Index: head/usr.sbin/sysinstall/install.c
===
--- head/usr.sbin/sysinstall/install.c (revision 215396)
+++ head/usr.sbin/sysinstall/install.c (working copy)
@@ -342,7 +342,7 @@ installFixitUSB(dialogMenuItem *self)
!DEVICE_INIT(mediaDevice)) {
msgConfirm(No USB devices found!);
return (DITEM_FAILURE);
- } else if (!file_readable(/dist/rescue/ldconfig)) {
+ } else if (!file_readable(/dist/rescue/rescue)) {
msgConfirm(Unable to find a FreeBSD live filesystem.);
return (DITEM_FAILURE);
}
@@ -375,7 +375,7 @@ installFixitCDROM(dialogMenuItem *self)
mediaClose();
if (need_eject msgYesNo(Unable to mount the disc. Do you want
to try again?) != 0)
return DITEM_FAILURE;
- } else if (!file_readable(/dist/rescue/ldconfig)) {
+ } else if (!file_readable(/dist/rescue/rescue)) {
mediaClose();
if (need_eject
msgYesNo(Unable to find a FreeBSD live filesystem. Do you
want to try again?) != 0)
@@ -565,7 +565,7 @@ fixit_livefs_common(dialogMenuItem *self)
/* Generate a new ld.so.hints */
if (!file_readable(/var/run/ld.so.hints)) {
Mkdir(/var/run);
- if (vsystem(/mnt2/rescue/ldconfig -s /mnt2/lib
+ if (vsystem(/mnt2/rescue/rescue ldconfig -s /mnt2/lib
/mnt2/usr/lib)) {
msgConfirm(Warning: ldconfig could not create the
ld.so hints file.\nDynamic executables from the
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: breaking the crunchgen logic into a share/mk file
On 16.11.2010 16:29, John Baldwin wrote: Err, are there no longer hard links to all of the frontends for a given crunch? If so, that is a problem as it will make rescue much harder to use. Yes, probably this patch is not needed and it should be fixed somewhere in makefiles. But currently rescue does not have any hardlinks: http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101116-JPSNAP/cdrom/livefs/rescue/ And what is was before: http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101112-JPSNAP/cdrom/livefs/rescue/ -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: CURRENT: Issue with ZFS and 2TB WD HDD (WDC WD20EURS-63Z9B1 80.00A80)
On 29.11.2010 11:52, O. Hartmann wrote: Exporting both volumes in FreeBSD 8 works. But importing them in FreeBSD 9.0-CURRENT/amd64 as with the most recent make world of today fails on the 2TB HDD (ZFS pool/volume BACKUP00). Issuing zpool import BACKUP00 results in cannot import 'BACKUP': no such pool available and on console I receive message It seems strange, why the pool name in error message is 'BACKUP' but not 'BACKUP00'? Surprisingly, the GPT partition of the pool BACKUP00 isn't shown in FreeBSD 9, while I see ada3p1 in FreeBSD 8.2. gpart show ada3 lists this: =34 3907029101 ada3 GPT (1.8T) 344062- free - (2.0M) 4096 3907025039 1 freebsd-zfs (1.8T) Do you have something related to GPT in log files? Can you show full output of `gpart show` from FreeBSD-8 and FreeBSD-9? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: ale(4) causes panic after r217323
On 14.01.2011 03:37, Aryeh Friedman wrote: I have already told jhb about this and he provided a patch that failed maybe someone else has a solution. Problem: As soon as ale(4) switches from DOWN to UP kernel panics due to lock state switch How to repeat: ifconfig ale0 192.168.2.2 I tried to update my system today and have a panic too. -- WBR, Andrey V. Elsukov GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x20 fault code = supervisor read data, page not present instruction pointer = 0x20:0x806352c8 stack pointer = 0x28:0xff812541a7f0 frame pointer = 0x28:0xff812541a820 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process = 2821 (dhclient) Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x20 fault code = supervisor read data, page not present instruction pointer = 0x20:0x806352c8 stack pointer = 0x28:0xff812541a7f0 frame pointer = 0x28:0xff812541a820 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process = 2821 (dhclient) Physical memory: 4063 MB Dumping 383 MB: 368 352 336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/ahci.ko...Reading symbols from /boot/kernel/ahci.ko.symbols...done. done. Loaded symbols for /boot/kernel/ahci.ko Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot/kernel/netgraph.ko.symbols...done. done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ether.ko Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:250 250 if (textdump_pending) (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:250 #1 0x801e99cc in db_fncall (dummy1=) at /usr/src/sys/ddb/db_command.c:548 #2 0x801e9d01 in db_command (last_cmdp=0x80ca7fc0, cmd_table=) at /usr/src/sys/ddb/db_command.c:445 #3 0x801e9f50 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0x801ebf99 in db_trap (type=) at /usr/src/sys/ddb/db_main.c:229 #5 0x80625dbe in kdb_trap (type=12, code=0, tf=0xff812541a740) at /usr/src/sys/kern/subr_kdb.c:546 #6 0x808f6e1d in trap_fatal (frame=0xff812541a740, eva=) at /usr/src/sys/amd64/amd64/trap.c:828 #7 0x808f71f1 in trap_pfault (frame=0xff812541a740, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:749 #8 0x808f76cf in trap (frame=0xff812541a740) at /usr/src/sys/amd64/amd64/trap.c:501 #9 0x808e1ec4 in calltrap () at /usr/src/sys
Re: Old ATA disk names emulation [Was: Switch from legacy ata(4) to CAM-based ATA]
On 25.04.2011 14:23, Alexander Motin wrote: What will not work: - old device names won't be seen inside GEOM, so users who hardcoded provider names in gmirror/gstripe/... metadata (not the default behavior) are still in trouble. - patch mimics ATA_STATIC_ID behavior, if user had custom kernel without it, he should update device names manually. - it won't work for users with hot-unplugging ATA controllers (not devices), but I believe it is really rare case. - low-level tools, such as smartmontools, won't be able to work with alias devices, as background ada driver doesn't implements legacy ioctls. May be I could partially fix this. Except those, I think this patch should work for the most of users. Any more objections/ideas? Is this an acceptable solution? Hi, what about new GEOM class? You can create new class instance after disk_alloc(), attach it to the new disk and create provider with old-style name. It seems this class will be very simple. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: A replacement for GEOM_LABEL's gpt/gptid
On 25.04.2011 14:38, Andrey V. Elsukov wrote: I wrote a small extension for the GEOM_PART class. It adds an ability to GEOM_PART class to create partition labels for schemes which are support them. Currently we have GEOM_LABEL class which does similar functions, but it has problems in conjunction with GEOM_PART (e.g. kern/154226). Current implementation of GEOM_LABEL's gpt/gptid module does direct access to GEOM_PART object structures, that seems not so good for me. So, my patch contains: * new GEOM class PART::LABEL. It attaches to partition provider and create new providers for each label. * new kobj method - G_PART_LABELS. It called when new partition is creating. A partition scheme can implement this method if it supports partition labels. Method should just call g_part_create_label() function to create new label for given partition. * g_part_spoil_labels() function. It called from GEOM_PART to destroy labels providers or mark them stale. At this time it called only from gpart modify method. What differs from GEOM_LABEL: * PART::LABEL class has not .spoiled method and all providers are persistent. * if label is changing while provider is in use, it will not be destroyed until access does not released, but new label will become available. * also it has support for APM and PC98 schemes. The patch is here: http://people.freebsd.org/~ae/gpart_labels.diff I updated the patch, it is in the same location. I turned off glabel's gpt/gpid support and added loader tunables: kern.geom.part_label.apm.enable kern.geom.part_label.gpt.enable kern.geom.part_label.gptid.enable kern.geom.part_label.pc98.enable Also for compatibility glabel's tunables still here: kern.geom.label.gpt.enable kern.geom.label.gptid.enable So, if you have them in your loader.conf and want to have gpt/gptid labels, you should remove them from loader.conf. Also now they are only loader tunables and they can not be changed in runtime. If there will no objections i am planning to commit patch in this weekend. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: A replacement for GEOM_LABEL's gpt/gptid
On 27.04.2011 11:37, Andrey V. Elsukov wrote: I wrote a small extension for the GEOM_PART class. It adds an ability to GEOM_PART class to create partition labels for schemes which are support them. Hi All, i got several successful reports from users, but now i decided to make this functional available for another consumers. New patch: http://people.freebsd.org/~ae/geom_alias.diff What it contains: * gpt/gptid support removed from GEOM_LABEL class; * new GEOM_ALIAS class added. This class has two public functions: void g_alias_create(struct g_provider *pp, const char *name); void g_alias_spoil(struct g_provider *pp); * first two consumers of GEOM_ALIAS class are GEOM_PART and GEOM_DISK: GEOM_DISK uses g_alias_create() to create aliases for disks, disk's serial number is used for alias name. GEOM_PART uses g_alias_create() to create aliases for labeled partitions (gpt/gptid, apm and pc98). How it looks like: http://paste.org.ru/?5exeve -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: bsdlabel showing value zero on fsize, bsize and bps/cpg for all partitions
On 05.05.2011 10:35, Sergi Seira wrote: on freebsd version 6 and 7 I was relaying on bsdlabel to get block size : Has anyone seen this? Is it some step I missed on install? Is there another command to get block size? I think dumpfs(8) is better tool for doing that. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: -CURRENT: mountroot failed
On 15.05.2011 22:05, Michiel Boland wrote: ioapic0: routing intpin 22 (GEOM_PART: integrity check failed (ada0, MBR) Can you send me a binary image of the first sector of ada0? Also, output of `gpart list ada0` would be helpful. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: -CURRENT: mountroot failed
On 16.05.2011 16:13, Michiel Boland wrote: Can you send me a binary image of the first sector of ada0? Also, output of `gpart list ada0` would be helpful. charlemagne# gpart list ada0 Geom name: ada0 modified: false state: OK fwheads: 16 fwsectors: 63 == last: 1953525167 == first: 63 entries: 4 scheme: MBR Providers: 1. Name: ada0s1 Mediasize: 1000204648448 (931G) Sectorsize: 512 Mode: r5w5e9 attrib: active rawtype: 165 length: 1000204648448 offset: 16384 type: freebsd index: 1 == end: 1953524735 == start: 32 Your partition has start offset below the first LBA. As temporary workaround you can set loader tunable kern.geom.part.check_integrity=0 (recently added to CURRENT) (Note that I partitioned the disk so that partition 1 starts at a multiple of 4096 bytes; this is one of those 4kb-sector disks that performs extremely badly if access is not aligned on a 4k boundary.) What tool did you use for partitioning? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: AW: -CURRENT: mountroot failed
On 01.06.2011 18:50, Uwe Grohnwaldt wrote: i have the same problem and setting kern.geom.part.check_integrity=0 works. I installed my system using sysinstall from 8.2-amd64-CD1. Hi, i added a workaround for this issue in r222341. Which revision do you use? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: AW: AW: -CURRENT: mountroot failed
On 02.06.2011 2:17, Uwe Grohnwaldt wrote: Hi, I build a kernel using src from svn. I have the same error. svn info shows Last Changed Rev: 222585 You should enable bootverbose mode and show all messages that begins from GEOM_PART. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [r222277] Strange GEOM, bsdlabel and ZFS behavior
On 09.06.2011 11:31, Eir Nym wrote: http://www.freebsd.org/cgi/query-pr.cgi?pr=157723 Can't reproduce. http://www.freebsd.org/cgi/query-pr.cgi?pr=157724 First of read this tread: http://lists.freebsd.org/pipermail/freebsd-stable/2011-May/062744.html and after reboot try: zpool create tank /dev/gpt/disk0 -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [r222277] Strange GEOM, bsdlabel and ZFS behavior
On 09.06.2011 13:32, Eir Nym wrote: Which revision do you use? Following link for mail is about this. http://www.freebsd.org/cgi/query-pr.cgi?pr=157724 First of read this tread: http://lists.freebsd.org/pipermail/freebsd-stable/2011-May/062744.html I mean that BSD scheme created with gpart(8) is not invalid. You always can use -b start_offset when creating partitions to preserve metadata area. Also you can use partition with zero offset for UFS. I've already compilled r222889 and will check it today. I have r222733. But it is no matter, nothing was changed in this area for 2-3 weeks. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [r222277] Strange GEOM, bsdlabel and ZFS behavior
On 09.06.2011 14:22, Eir Nym wrote: GEOM will say it only after reboot. part of dmesg log: GEOM_LABEL[1]: MSDOSFS: gzero: no FAT signature found. ugen0.1: Intel at usbus0 uhub0: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 ugen1.1: Intel at usbus1 uhub1: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1 ugen2.1: Intel at usbus2 uhub2: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus2 ugen3.1: Intel at usbus3 uhub3: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus3 ugen4.1: Intel at usbus4 uhub4: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus4 GEOM_LABEL[1]: MSDOSFS: gzero: no FAT signature found. ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: SAMSUNG HM641JI 2AJ10001 ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 610480MB (1250263728 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 SMP: AP CPU #1 Launched! Timecounter TSC frequency 1666519680 Hz quality 800 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered GEOM_LABEL[1]: MSDOSFS: ada0: FAT12/16 volume not valid. GEOM_LABEL[1]: MSDOSFS: ada0s1: no FAT signature found. GEOM_LABEL[1]: MSDOSFS: ada0s2: no FAT signature found. GEOM_LABEL[1]: MSDOSFS: ada0s3: FAT32 volume not valid. GEOM_LABEL[1]: Label for provider ada0s3 is ntfs/System Reserved. GEOM_LABEL[1]: MSDOSFS: ada0s4: FAT32 volume not valid. GEOM_LABEL[1]: MSDOSFS: ada0s1: no FAT signature found. g_dev_taste: make_dev_p() failed (gp-name=ada0s1, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s2: no FAT signature found. g_dev_taste: make_dev_p() failed (gp-name=ada0s2, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s3: FAT32 volume not valid. GEOM_LABEL[1]: Label System Reserved(ntfs/System Reserved) already exists (ada0s3). g_dev_taste: make_dev_p() failed (gp-name=ada0s3, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s4: FAT32 volume not valid. g_dev_taste: make_dev_p() failed (gp-name=ada0s4, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1a: no FAT signature found. GEOM: ada0s1a: invalid disklabel. GEOM_LABEL[1]: MSDOSFS: ada0s1b: no FAT signature found. GEOM_LABEL[1]: MSDOSFS: ada0s1c: no FAT signature found. GEOM_LABEL[1]: MSDOSFS: ada0s1a: no FAT signature found. g_dev_taste: make_dev_p() failed (gp-name=ada0s1a, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1b: no FAT signature found. g_dev_taste: make_dev_p() failed (gp-name=ada0s1b, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1a: no FAT signature found. GEOM: ada0s1a: invalid disklabel. g_dev_taste: make_dev_p() failed (gp-name=ada0s1a, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1b: no FAT signature found. g_dev_taste: make_dev_p() failed (gp-name=ada0s1b, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1c: no FAT signature found. g_dev_taste: make_dev_p() failed (gp-name=ada0s1c, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1a: no FAT signature found. g_dev_taste: make_dev_p() failed (gp-name=ada0s1a, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1b: no FAT signature found. g_dev_taste: make_dev_p() failed (gp-name=ada0s1b, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1ca: no FAT signature found. GEOM_LABEL[1]: MSDOSFS: ada0s1cb: no FAT signature found. GEOM_LABEL[1]: MSDOSFS: ada0s1aa: no FAT signature found. GEOM_LABEL[1]: MSDOSFS: ada0s1ab: no FAT signature found. GEOM_LABEL[1]: MSDOSFS: ada0s1ac: no FAT signature found. GEOM_LABEL[1]: MSDOSFS: ada0s1ca: no FAT signature found. g_dev_taste: make_dev_p() failed (gp-name=ada0s1ca, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1cb: no FAT signature found. g_dev_taste: make_dev_p() failed (gp-name=ada0s1cb, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1aa: no FAT signature found. g_dev_taste: make_dev_p() failed (gp-name=ada0s1aa, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1ab: no FAT signature found. g_dev_taste: make_dev_p() failed (gp-name=ada0s1ab, error=17) GEOM_LABEL[1]: MSDOSFS: ada0s1ac: no FAT signature found. g_dev_taste: make_dev_p() failed (gp-name=ada0s1ac, error=17) It is strange. I think you have something incorrect in your configuration. Can you show output of these commands: 1. kldstat 2. cat /boot/loader.conf 3. grep GEOM /path/to/your/kernel/config -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [r222277] Strange GEOM, bsdlabel and ZFS behavior
On 10.06.2011 10:50, Eir Nym wrote: messages on the start of this dmesg are for more pages of (I have see them for several seconds on same hardware) kernel config : http://eroese.org/_/_/pub/bsd/222889/GENERIC_PF You have mixed old partitioning classes with GEOM_PART. You should remove from the kernel at least: options GEOM_BSD options GEOM_MBR options GEOM_PC98 options GEOM_VOL -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: ports/net/mpd[45] broken with utmpx.h change
On 16.02.2010 4:51, Bernd Walter wrote:
I don't know how difficult it is to fix, but for many of us mpd is
important to have network connection.
You can try this patch. I don't know why Alexander did't commit it.
--
WBR, Andrey V. Elsukov
--- src/auth.c 2009-12-22 12:02:46.0 +0300
+++ src/auth.c 2010-01-18 15:01:25.918302237 +0300
@@ -1387,6 +1387,30 @@
* Account with system
*/
+#if __FreeBSD_version = 97
+static int
+AuthSystemAcct(AuthData auth)
+{
+ struct utmpxut;
+
+ memset(ut, 0, sizeof(ut));
+ snprintf(ut.ut_id, sizeof(ut.ut_id), %xmpd, auth-info.linkID);
+
+ if (auth-acct_type == AUTH_ACCT_START) {
+ ut.ut_type = USER_PROCESS;
+ strlcpy(ut.ut_host, auth-params.peeraddr, sizeof(ut.ut_host));
+ strlcpy(ut.ut_user, auth-params.authname, sizeof(ut.ut_user));
+ gettimeofday(ut.ut_tv, NULL);
+ Log(LG_AUTH, ([%s] ACCT: wtmp %s %s %s login,
auth-info.lnkname, ut.ut_line,
+ ut.ut_user, ut.ut_host));
+ } else if (auth-acct_type == AUTH_ACCT_STOP) {
+ ut.ut_type = DEAD_PROCESS;
+ Log(LG_AUTH, ([%s] ACCT: wtmp %s logout, auth-info.lnkname,
ut.ut_line));
+ }
+ pututxline(ut);
+ return (0);
+}
+#else
static int
AuthSystemAcct(AuthData auth)
{
@@ -1412,6 +1436,7 @@
}
return (0);
}
+#endif /* __FreeBSD_version = 97 */
#endif /* USE_SYSTEM */
#ifdef USE_PAM
--- src/auth.h 2009-12-22 12:02:46.0 +0300
+++ src/auth.h 2010-01-18 14:44:22.471540149 +0300
@@ -23,7 +23,11 @@
#ifdef USE_OPIE
#include opie.h
#endif
+#if __FreeBSD_version = 97
+#include utmpx.h
+#else
#include utmp.h
+#endif
/*
* DEFINITIONS
@@ -303,8 +307,10 @@
extern const char*AuthMPPEPolicyname(int policy);
extern const char*AuthMPPETypesname(int types, char *buf, size_t len);
+#if defined(USE_NG_BPF) || defined(USE_IPFW)
extern void ACLCopy(struct acl *src, struct acl **dst);
extern void ACLDestroy(struct acl *acl);
+#endif
extern void authparamsInit(struct authparams *ap);
extern void authparamsCopy(struct authparams *src, struct
authparams *dst);
extern void authparamsMove(struct authparams *src, struct
authparams *dst);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Can not boot after r203503. Unable to open /dev/ada(1/2)p3 for writing
26.02.10, 14:47, Paul Wootton p...@fletchermoorland.co.uk: I have an unusual problem. Last night I tried updating from my old-ish kernel/world to an up to date version. I had been using 202500-ish successfully. I can build and install the newer world and kernel fine, but when I reboot I get the following Trying to mount root from zfs:raid250/root ZFS WARNING: Unable to open /dev/ada1p3 for writing (error=1). ZFS WARNING: Unable to open /dev/ada2p3 for writing (error=1). ROOT MOUNT ERROR. If you have invalid mount options, reboot, and first try the following from the loader prompt: set vfs.root.mountfrom.options=rw and then remove the invalid options from /etc/fstab loader variables: vfs.root.mountfrom=zfs:raid250/root vfs.root.mountfrom.options=rw I had the same problem recently. I have ZFS-only 9.0-CURRENT-amd64. First time when i had this problem was after I added linux_load=YES in /boot/loader.conf. :-) It was only change i made. So, i rebooted again and unload linux from boot prompt. And system boots fine. I tried again with linux.ko and it failed to boot. After that i synced source tree and rebuild kernel. And after that it failed to boot with and without linux. :-) So, after that i booted from another disk and only thing that i did was: # zpool import -R /mnt z # gpart modify -l ZFS -i 3 ad4 (previous label was zfs) After that i can boot with and without linux.ko again. And I can't reproduce this bug again. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Results of BIND RFC
On 02.04.2010 9:24, Stanislav Sedov wrote: While it certainly might make sense to drop BIND out of the base, I'm not sure dropping bind tools as well from it is the best decision. How hard it will be to continue maintaining bind tools inside the base (so the critical ones like dig and nslookup still will be available), while moving the rest of it (the server itself and supporting tools) to the port? Hi, All. I'm agree with Stas. If it is not so hard to maintain bind-tools in the base, It is very useful to still having them in base system. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[RFC] Rewriting sade(8)
Hi, All.
Some days ago i begun rewriting sade(8) to libgeom(3). Just for fun :-)
Today i have progress and you can see some screenshoots here:
http://butcher.heavennet.ru/sade/
What is done:
1. It's fully rewritten, but yes, i reuse some code from old sade.
2. I wrote small framework customdlg for creating custom dialogs (not yet
fully finished, but works).
3. Now sade use libgeom for searching providers and it can use:
{DISK,disk device},
{MD, memory backed virtual disk},
{ZFS::ZVOL, ZFS volume},
{MIRROR, GEOM based mirror (RAID1)},
{STRIPE, GEOM based stripe (RAID0)},
{RAID3, GEOM based RAID3 array},
{CONCAT, GEOM based concatenated disk},
{ELI, GEOM based encrypted disk},
{JOURNAL, GEOM based journalled disk},
{MULTIPATH, GEOM based disk with multiple path}
4. Access to partitions based on geom_part.so library. I made some changes in
geom_part.c and
sent it to Marcel, but currently didn't receive answer. Any way if these
changes is not acceptable
i can rewrite it for using libgeom(3) only.
5. Undo/Commit features are based on internal implementation of geom class
PART. I found there
two bugs:
http://lists.freebsd.org/pipermail/freebsd-geom/2010-April/004018.html
http://lists.freebsd.org/pipermail/freebsd-bugs/2010-April/039390.html
6. All device related code can be placed in shared library and in future can
be reused in another
frontend...
7. New Partition Editor:
* partitions list now scrollable;
* all operations based on geom_part.so and similar to gpart(8);
* opening partition editor on empty provider opens new Selech Partitioning
Scheme dialog
and create selected scheme;
* new add slice dialog;
* deleting slice from empty table destroys scheme;
Todo:
1. Refine customdlg.
2. Waiting for fixes in geom_part_mbr, geom_part and geom_part.so.
3. Set Type and Label dialog.
4. Better wording needed for messages and help. My english is bad :(
--
Missing functions:
Creating filesystem and save them into /etc/fstab.
What new can be added:
1. Creating ZFS pools and datasets.
2. Creating GEOM-based raids.
Any comments are welcome.
--
WBR, Andrey V. Elsukov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Rewriting sade(8)
On 07.04.2010 21:49, Randi Harper wrote: Wow. This is awesome. patches? :D :) I'm not ready yet to publish code. I planned to announce this RFC a bit later, when code will be finished. But Konstantin (kib@) suggested do it before finishing. I've been working on moving sysinstall from libdisk to libgeom, but unfortunately it's a bit more complicated (redoing the way we detect devices while I'm at it). I've done a lot of the heavy lifting code, but I haven't even started on the GUI parts yet. I'd love to see how someone else tackled doing this. I'm particularly interested in #5 #7. :) Initially i wanted to only modify current sade's code to move it from libdisk to libgeom. But after several attempts i decided that it will be easier to rewrite it :) Generally, we try to keep sysinstall's disk tools and sade in sync, so I would like to work with you on this and see what we can come up with. I'm not entirely sure if #2 is a viable option since we already have functions in sysinstall that handle generating dialog boxes with libdialog, but if it's an improvement on what's existing, bring it on. Yes, I looked at this code in sysinstall and in libdialog. Also I looked to another console UI libs. The main problem of using external libraries is that not so easy import them into base system. libdialog have several problemls too, imho. 1. Custom dialogs based on ComposeObj are ugly :) 2. It supports *only* single-byte characters. Initially I wanted to write code with message catalogs support. But after several tests I leaved this idea. Also it seems there is no catgets analog for wide characters. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Rewriting sade(8)
On 08.04.2010 10:27, Bruce Cran wrote: That's a shame. As long as the source isn't available it's of little interest to me. For anyone who wants to see the bits of code I've got so far, I've created a Google Code project at http://code.google.com/p/gcpart/ . I'm currently trying to figure out how to get the partitioning scheme out of the XML tree, which is why there's no geom code there yet. As soon as I do so, I'll start checking in my effort at the new partitioning application. I just thinking about future of my project. It seems there are several people who worked on the same before. And I have not finished yet only few things from initially planned. After that i can remove any unused code, write some comments and publish it somewhere in perforce. Also at this time code depends on changes which i made in geom_part.so and which are not yet commited into base system. After code review there can be several ways to go. And I have an interest which way will be for me :) -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Rewriting sade(8)
On 08.04.2010 11:27, Randi Harper wrote: It's great that you want to work on this, but there are other people working in the same area, so keeping your code to yourself for too long makes it very likely that it will never get used. Ok. I put the code here: http://butcher.heavennet.ru/sade/sade-20100408.tgz -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Rewriting sade(8)
On 08.04.2010 14:15, Alexander Leidinger wrote: We don't grant non-committers access to the Subversion repo. Ooops... seems I misremembered his status. Somehow I associate him with something FreeBSD related. Andrey, did you participate in a GSoC? No, I'm not fit for GSoC. My suggestion is to add a sysinstall mode to sade where it operates under certain (minor) constraints and reports what it did in a format that sysinstall can parse, so sysinstall can just fork-exec sade instead of duplicating the code. I like this idea. Any way i'll try to finish my work myself. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Re: [RFC] Rewriting sade(8)
09.04.10, 11:20, Garrett Cooper yanef...@gmail.com: Ok. Or maybe since `we're here' sade needs to be populating $DESTDIR/etc/fstab, not sysinstall ? I'm also looking for answer to this question. It seems that all basic operations with partitions are already implemented. And I think about next steps. Also I think I should make a dialog for writing bootcode. And there are a bunch of different bootstrap code which can be used with different schemes. So if anyone can share own experience I'll be grateful. MBR: /boot/mbr - standart boot record (is it needed? Is it not the same which gpart creates?). /boot/boot0 - boot0 boot manager. /boot/boot0sio - boot0 boot manager with redirected output ot com1. GPT: /boot/pmbr - protective mbr /boot/gptboot - bootstrap code for booting from GPT, should be installed to freebsd-boot partition. /boot/gptzfsboot - bootstrap code for booting from GPT and ZFS, should be installed to freebsd-boot partition. /boot/zfsboot - bootstrap code for booting from ZFS from MBR, it seems this bootcode doesn't have a correct way (e.g `gpart bootcode ...`) to be writed. What about VTOC8, PC98, APM? -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfw bug on i386
On 12.04.2010 10:07, Hizel Ildar wrote:
Hey! I'm fix this bug :D
patch:
foo# diff -ruN main.c~ main.c
--- main.c~ 2010-03-04 19:54:56.0 +0300
+++ main.c 2010-04-12 09:37:21.0 +0400
@@ -553,7 +553,7 @@
}
while (fgets(buf, BUFSIZ, f)) { /* read commands */
- char linename[10];
+ char linename[11];
char *args[2];
lineno++;
Can you test your it with 100k lines? :)
I think it can be fixed with something similar to:
- sprintf(linename, Line %d, lineno);
+ snprintf(linename, sizeof(linename), Line %d, lineno);
--
WBR, Andrey V. Elsukov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Rewriting sade(8)
On 14.04.2010 13:28, Daniel Braniss wrote: correct me if I'm wrong, is MBR the only one that can be used to change the boot partition via menu? and also via serial? BTW, you said you would look into boot0cfg :-) At this thime I implemented writing bootstrap code only for MBR and GPT schemes. For MBR scheme user can select one from Standart MBR and Boot Manager. For GPT scheme user can select ZFS-aware gptzfsboot and gptboot. Currently I'm working on File Systems Editor. But here are lot of work. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server
On 21.04.2010 2:44, Maxim Sobolev wrote: Maxim Sobolev wrote: Maybe try adding hint.atkbdc.0.disabled=1 hint.atkbd.0.disabled=1 Actually it helped, thank you very much! The problem was that I have had my hints compiled into the kernel itself. Hi, Maxim. I tried to boot 9.0-CURRENT amd64 snapshot on IBM x3650 M2 and seems have the same problem, i set hints from loader prompt, but this didn't help. Can you explain what you did to boot FreeBSD faster? -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
