Re: [SOLVED] Re: labelling root file system (RELENG_8)
2011/6/8 Matthias Andree : > Am 08.06.2011 15:11, schrieb nickolas...@gmail.com: >> 1. Change your root fstab record to /dev/ada0s4a (not label!), reboot >> to single mode and try to re-label partition. > > Indeed not mounting from the label was (apparently) the key to solve > this. Thank you. > > In fact the successful procedure was: > > - from boot menu, escape to loader prompt > - set vfs.root.mountfrom=ufs:/dev/ada0s4a > - boot -s > - tunefs -L mylabel /dev/ada0s4a > - mount -a > - edit /etc/fstab to use /dev/ufs/mylabel as device for / > - shutdown -r now > Right, you cannot re-label partition because you've mount filesystem through label device. So this device is already in use and re-labeling would destroy label device. - wbr, Nickolas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [SOLVED] Re: labelling root file system (RELENG_8)
2011/6/8 Josh Carroll : >>> That would mean the only time a >>> person can use tunefs on a root filesystem is when they either do it >>> manually during the FreeBSD installation (adding "-t" to the list of >>> newfs flags in the filesystem creation UI), or if they boot off of some >>> other medium (USB flash drive, CD, PXE, etc.). >> >> Or when your root fs is mounted r/o, which is not as bad as what you listed >> above. Or when you've booted form device (not label), e.g. /dev/ada0s1a and have set sysctl kern.geom.debugflags=16 > > Perhaps I'm doing something wrong, but in my experience, at least with > glabel, the label will not stick even if you have the root fs mounted > ro. I have had to boot from an alternative media (boot cd, alternate > root fs, etc) in order to create a label for the root fs with glabel. > To be specific, I'm talking about the "automatic" labels created with > glabel label . > > I just tested this again in a VM, and sure enough if I boot single > user mode but use ad0s1a as the ro root file system during single user > mode, it still doesn't stick and upon reboot I don't have a /dev/label > entry. Here is the exact sequence I used: > > 1. boot single user with the default root fs (ad0s1a). > 2. leave / mounted read only > 3. glabel label -v root ad0s1a # reports successful addition of metadata > 4. /dev/label/root exists as expected > 5. reboot > 6. /dev/label/root does not exist You should mount fs from label device - /dev/label/root in your case, which must be in /etc/fstab, e.g.: /dev/label/root/ufs rw1 1 Otherwise if you mount fs from device directly (not from label) label entry (/dev/label/root) would be removed from /dev file system as unused device. This action will be reported in dmesg (you may check it) So, afrer labeling device you should add fstab record. After that you can reboot. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
re0 died last night; here's how I half-revived it
I have a FreeBSD 8-STABLE system that's been running stably since I last upgraded and rebooted on May 8. Yesterday, I updated /usr/src to get ZFS v28 and also seem to have gotten rid of my nice, solid re0 network interface: re0: port 0xb000-0xb0ff mem 0xea21-0xea210fff,0xea20-0xea20 irq 16 at device 0.0 on pci5 re0: Using 1 MSI-X message re0: Chip rev. 0x3c00 re0: MAC rev. 0x0040 miibus0: on re0 I'm too tired from lack of sleep due to getting the system back up and running to remember all the details, but the summary is that it started autodetecting its media as 10baseT/UTP. Almost immediately after boot - sometimes while still playing in single-user mode - I'd start seeing "no buffer space available" error messages all over the place. Forcing media to 1000baseTX/full-duplex fixed the problem for a few minutes, but it wouldn't stay in that state and would shortly start throwing "no buffer space available" errors again. Until I've gotten some sleep and have more mental energy to figure out exactly what's going on, I've found that forcing the media to 100baseTX keeps it solidly chugging along (if a little slowly). Anyway, that's where I'm at now. If your re NIC is giving you fits this morning, try setting it to 100baseTX and see if that'll get you running until a better fix comes along. - Kirk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
BTX loader problem on specific hardware
Hi! I'm having a problem with BTX hanging on an HP 6005 Pro PC. I have filed a followup to an existing PR about this exact problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=151122 All the information there looks correct and stands true. I have tried performing some trivial debugging on btxld and btx, but not having any ASM skills and not knowing much about PC booting process I could not conjure much. It looks that it hangs between the end of btxld.S just before relocating it's own start.8 routine and the first few instructions in btx.S. Could really not make up much more. I tried using old btx code, but it does not compile with present tools. So I'm a little stuck. I have the machine handy and can perform tests, run code and even debug further if instructed a little on what needs to be done. I hope someone with some specific knowledge could have a look at this(strange) problem. Thanks in advance! -- Guido Falsi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Disable probing of bge1?
we managed to disable bge0, by inserting the following: + if (device_get_unit(dev) == 0) + return (ENXIO); + -- View this message in context: http://freebsd.1045724.n5.nabble.com/Disable-probing-of-bge1-tp3961580p4473468.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [SOLVED] Re: labelling root file system (RELENG_8)
Am 08.06.2011 19:59, schrieb Rob Farmer: > Also, I've seen the sysctl kern.geom.debugflags=16 thing in zfs > tutorials and such, but haven't seen where it's actually necessary. I > think this is outdated and changed circa 8.0. Possibly - it's still a de-facto standard reflex action whenever a newer FreeBSD kernel refuses to write a superblock or MBR or partition stuff. 8-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: BTX loader problem on specific hardware
On Thursday, June 09, 2011 11:28:20 am Guido Falsi wrote: > Hi! > > I'm having a problem with BTX hanging on an HP 6005 Pro PC. > > I have filed a followup to an existing PR about this exact problem: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=151122 > > All the information there looks correct and stands true. > > I have tried performing some trivial debugging on btxld and btx, but not > having any ASM skills and not knowing much about PC booting process I > could not conjure much. > > It looks that it hangs between the end of btxld.S just before > relocating it's own start.8 routine and the first few instructions > in btx.S. Could really not make up much more. > > I tried using old btx code, but it does not compile with present tools. > So I'm a little stuck. > > I have the machine handy and can perform tests, run code and even debug > further if instructed a little on what needs to be done. > > I hope someone with some specific knowledge could have a look at > this(strange) problem. > > Thanks in advance! Hmm, these are not so easy to debug. You can try putting a 'foo: jmp foo' instruction in various places as a sort of 'while (1)' loop. The first test I would do is to put it earlier in btxld before the messages that BTXLDR_VERBOSE logs to see if when it hangs the cursor stays at its current location rather than jumping back up. If that works out then you can start moving the 'foo: jmp foo' later until you find a point where it hangs and moves the cursor (which means it hung in between your previous 'jmp foo' and the one you most recently added). I would start by walking down through btxldr.S. If it makes it all the way through that, start walking through the BTX init code. Oddly enough, BTX had to run at least once so that boot2 could find the loader and kick off the btxldr.S. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
recover file from destroyed zfs snapshot - is it possible?
Hi all, I know this is a long shot, but I figure it's worth asking. Is there anyway to recover a file from a zfs snapshot which was destroyed? I know the name of the file and a unique string that should be in it. The zfs pool is on geli devices so I can't dd the raw device and look for it. Any suggestions? Thanks for the help. -Greg ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
kvm_open errors on /proc/*/mem in top
i'm not sure which list this belongs to, so i'm posting to -hackers and -stable. i've noticed for a while now that during heavy activity (for instance buildworld), that top will get these kvm_read errors when reading proc mem entries. i have included a screenshot of what happens during such events... last pid: 92024; load averages: 4.79, 4.58, 4.10 up 0+00:49:07 15:30:53 225 processes: 10 running, 197 sleeping, 18 waiting CPU: 90.6% user, 0.0% nice, 9.4% system, 0.0% interrupt, 0.0% idle Mem: 493M Active, 1337M Inact, 604M Wired, 632K Cache, 315M Buf, 524M Free Swap: 4097M Total, 4097M Free kvm_open: cannot open /proc/86755/mem PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 91943 root 1 970 39536K 33620K RUN 1 0:01 7.37% [cc1plus] 2859 jbryant 1 480 406M 72332K select 0 3:10 5.96% kwin -session 1028b2382461f50001270420560001955_13 2747 root 1 460 419M 370M select 0 1:43 4.39% /usr/local/bin/X :0 -nolisten tcp -auth /var/run/xauth/A:0 1464 root 1 440 8068K 1384K select 0 0:03 0.39% /usr/sbin/moused -p /dev/ums0 -t auto -I /var/run/moused.u 11219 jbryant 7 440 299M 109M select 1 0:17 0.29% /usr/local/lib/thunderbird/thunderbird-bin 2865 jbryant 1 450 453M 86140K select 0 0:21 0.20% kdeinit4: kdeinit4: plasma-desktop (kdeinit4) 2882 jbryant 1 440 391M 60996K select 0 0:17 0.10% kdeinit4: kdeinit4: kmix -session 102511e52251c60001304471 92001 root 1 970 23452K 22256K CPU11 0:00 0.00% [cc1] 92017 root 1 960 16172K 13440K RUN 0 0:00 0.00% [cc1] and such as this: last pid: 19348; load averages: 1.03, 1.93, 2.84 up 1+04:42:07 15:31:37 201 processes: 4 running, 178 sleeping, 19 waiting CPU: 47.4% user, 0.0% nice, 3.4% system, 0.0% interrupt, 49.3% idle Mem: 318M Active, 2400M Inact, 679M Wired, 1948K Cache, 407M Buf, 428M Free Swap: 8192M Total, 6488K Used, 8186M Free kvm_open: cannot open /proc/1141/memm kvm_open: cannot open /proc/92606/memRES STATE C TIME WCPU COMMAND 10 root 2 171 ki31 0K32K RUN 0 55.9H 103.81% [idle] 19344 root 1 960 17188K 14300K CPU10 0:00 0.00% [cc1] 19341 root 1 760 3204K 1068K select 1 0:00 0.00% make all DIRPRFX=fdc/ 19342 root 1 760 8340K 1848K wait1 0:00 0.00% sh -ev 19343 root 1 760 3204K 596K wait0 0:00 0.00% [cc] 19345 root 1 760 3204K 1292K piperd 0 0:00 0.00% /usr/obj/usr/src/tmp/usr/bin/as -Qy -o fdc.o the current fix for this is to [CTRL]-L. i assume that what is happening is that top just loosing track of what's running, and the procs are dead by the time it tries to read them, or that the proc ends during top reading. is there any way to fix this? it's annoying as f&#k. ps: running 8-STABLE. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
problem with urtw
I just bought one of those chinese (apparently the same unit relabeled and being sold by multiple companies) realtek RTL8187B wifi units. The price is right. The label name on this one is WiFySky 1500mW. other than the fact that the case it is enclosed in is really cheesy, there is a more immediate problem with this. the current urtw driver returns a 6. here we go: on insert: ugen3.2: at usbus3 after kldload if_urtw.ko: urtw0: on usbus3 urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE device_attach: urtw0 attach returned 6 urtw0: on usbus3 urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE device_attach: urtw0 attach returned 6 urtw0: on usbus3 urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE device_attach: urtw0 attach returned 6 urtw0: on usbus3 urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE device_attach: urtw0 attach returned 6 3:28:35pm argus(48): usbconfig -u 3 -a 2 dump_device_desc ugen3.2: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0040 idVendor = 0x0bda idProduct = 0x8187 bcdDevice = 0x0200 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x bNumConfigurations = 0x0001 3:28:48pm argus(49): usbconfig -u 3 -a 2 dump_curr_config_desc ugen3.2: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0051 bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x0004 bmAttributes = 0x0080 bMaxPower = 0x00fa Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0009 bInterfaceClass = 0x00ff bInterfaceSubClass = 0x00ff bInterfaceProtocol = 0x00ff iInterface = 0x0002 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0083 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0004 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 2 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0005 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 3 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0006 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 4 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0007 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 5 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0089 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 6 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x000a bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 7 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x000b bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 8 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x000c bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x bRefresh = 0x bSynchAddress = 0x If a verbose boot or any other info is needed to get this working, please tell me, and I'll get you the info. I do have to admit, at the price these are going for, they are rather nice, and do reach out and touch a router. Review complaints: heat dissipation. If you buy one, don't operate it in a hot environment. I'd like to see it working in FreeBSD, but I don't have a handle on the wifi driver structure. Linux source code was included on the driver disk. I can email that directly to whomever needs it for comparison. Thanks, Jim, KC5VDJ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to
Re: recover file from destroyed zfs snapshot - is it possible?
On Thu, Jun 9, 2011 at 1:00 PM, Greg Bonett wrote: > Hi all, > I know this is a long shot, but I figure it's worth asking. Is there > anyway to recover a file from a zfs snapshot which was destroyed? I know > the name of the file and a unique string that should be in it. The zfs > pool is on geli devices so I can't dd the raw device and look for it. > Any suggestions? > > Thanks for the help. Theoretically it may be possible. Practically it will not be trivial. ZFS state at any given point in time is determined by it's uberblock. ZFS keeps number of previous uberblocks (and thus -- ZFS states). If you're familiar with ZDB and with ZFS filesystem layout, you may be able to use information in the last saved uberblock before the snapshot was nuked and, with some luck, would be able to find the data tat was in your file. That, however, relies on an optimistic assumption that a) such uberblock is still around and, b) appropriate disk blocks have not been reused by more recent transactions.I believe recent ZFS versions (v28 should qualify) make an effort to keep recent transaction groups in consistent state to improve chances of recovery with "zpool import -F" in case disks lied about cache flushes. In case you do want to dig in, ZFS on-disk data structures are documented here: http://opensolaris.org/os/community/zfs/docs/ondiskformat0822.pdf This script (WARNING -- DESCTRUCTIVE) should allow you to roll back ZFS state to an earlier point in time on single-device pools: http://www.solarisinternals.com/wiki/index.php/ZFS_forensics_scrollback_script Good luck. --Artem P.S. You wouldn't happen to have backup of your file, would you? That would make things so much easier. :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: recover file from destroyed zfs snapshot - is it possible?
On Thu, 2011-06-09 at 14:57 -0700, Artem Belevich wrote: On Thu, Jun 9, 2011 at 1:00 PM, Greg Bonett wrote: > > Hi all, > > I know this is a long shot, but I figure it's worth asking. Is there > > anyway to recover a file from a zfs snapshot which was destroyed? I know > > the name of the file and a unique string that should be in it. The zfs > > pool is on geli devices so I can't dd the raw device and look for it. > > Any suggestions? > > > > Thanks for the help. > > Theoretically it may be possible. Practically it will not be trivial. > > ZFS state at any given point in time is determined by it's uberblock. > ZFS keeps number of previous uberblocks (and thus -- ZFS states). If > you're familiar with ZDB and with ZFS filesystem layout, you may be > able to use information in the last saved uberblock before the > snapshot was nuked and, with some luck, would be able to find the data > tat was in your file. That, however, relies on an optimistic > assumption that a) such uberblock is still around and, b) appropriate > disk blocks have not been reused by more recent transactions.I believe > recent ZFS versions (v28 should qualify) make an effort to keep recent > transaction groups in consistent state to improve chances of recovery > with "zpool import -F" in case disks lied about cache flushes. > > In case you do want to dig in, ZFS on-disk data structures are documented here: > http://opensolaris.org/os/community/zfs/docs/ondiskformat0822.pdf > > This script (WARNING -- DESCTRUCTIVE) should allow you to roll back > ZFS state to an earlier point in time on single-device pools: > http://www.solarisinternals.com/wiki/index.php/ZFS_forensics_scrollback_script > > Good luck. > > Thanks for the response. I'll follow these links and see if I think I can pull it off. One question though, you say it's necessary that "appropriate disk blocks have not been reused by more recent transactions" Is it not possible for me to just read all the disk blocks looking for the filename and string it contained? How big are disk blocks, is it possible the whole 16k file is on one or a few contiguous blocks? Thanks! -Greg --Artem > > P.S. You wouldn't happen to have backup of your file, would you? That > would make things so much easier. :-) > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: recover file from destroyed zfs snapshot - is it possible?
On Thu, Jun 9, 2011 at 3:43 PM, Greg Bonett wrote: > One question though, you say it's necessary that "appropriate > disk blocks have not been reused by more recent transactions" > Is it not possible for me to just read all the disk blocks looking for > the filename and string it contained? How big are disk blocks, is it > possible the whole 16k file is on one or a few contiguous blocks? Whether all your data is in a single block would depend on how large the file is and how exactly it was written out. If it's something that's been written all at once, chances are that it will end up located sequentially somewhere on disk. If the file was written more than once, you may find several file variants. Telling which one is the most recent one without parsing ZFS metadata would be up to you. Another question is whether the content would be easy to identify. If you have compression turned on, then simple grepping for content will not work. So, if your pool does not have compression on, you know what was in the file and are reasonably sure that you will be able to tell whether the data you recover is consistent or not, then by all means start with searching for this content in a raw data. Default ZFS block size is 128K, so for the small file written at once there's a good chance that it's been written out in a single chunk. --Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
