Re: Destroy GPT partition scheme absolutely, how?

On Mon, Sep 26, 2016 at 11:06 PM, O'Connor, Daniel wrote: > >> On 27 Sep 2016, at 14:28, Warner Losh wrote: >> dd of 2MB of zeros to the start and end of the disk. That will destroy >> pretty much everything. For SSDs, sometimes you can do the same with >> TRIMs only faster (other times they are

Re: Destroy GPT partition scheme absolutely, how?

> On 27 Sep 2016, at 14:28, Warner Losh wrote: > dd of 2MB of zeros to the start and end of the disk. That will destroy > pretty much everything. For SSDs, sometimes you can do the same with > TRIMs only faster (other times they are slower or unreliable). Yeah, but it would be nicer to not have

Re: Destroy GPT partition scheme absolutely, how?

On Mon, Sep 26, 2016 at 8:46 PM, O'Connor, Daniel wrote: > >> On 27 Sep 2016, at 06:21, John Baldwin wrote: >> That doesn't always work. In particular, if a disk was partitioned with GPT >> and then you use normal MBR on it afterwards, the 'gpart destroy -F' of the >> MBR will leave most of the

Re: Destroy GPT partition scheme absolutely, how?

On Tue, 27 Sep 2016 00:36:22 +0900 Ngie Cooper wrote: > > On Sep 26, 2016, at 22:48, Ernie Luzar wrote: > > ... > > > This little script has been posted before. Maybe it will be what your > > looking for. Called gpart.nuke > > > > #! /bin/sh > > echo "What disk do you want" > > echo "to wip

Re: Destroy GPT partition scheme absolutely, how?

On Mon, 26 Sep 2016 09:48:22 -0400 Ernie Luzar wrote: > Hartmann, O. wrote: > > I ran into a very nasty and time consuming problem. Creating a NanoBSD > > image with a modified script framework creating GPT partitions, I put > > the imaes via "dd(1)" on USB flash or SD flash. Because the images a

Re: Destroy GPT partition scheme absolutely, how?

> On 27 Sep 2016, at 06:21, John Baldwin wrote: > That doesn't always work. In particular, if a disk was partitioned with GPT > and then you use normal MBR on it afterwards, the 'gpart destroy -F' of the > MBR will leave most of the GPT intact and the disk will come up with the old > GPT partiti

Re: [VBox] Extreme slow UDP performance between host and guest

Did you use the "-b" option to set the bandwidth it uses for UDP? It defaults to 1Mb/s, which is close to what you're seeing. Plus, I think the recommendation is that you use iperf3, anyway, and I don't think it has this quirk. On Thu, Sep 1, 2016 at 2:06 AM Howard Su wrote: > I used iperf to d

Re: Freeze during booting of ASUS F2A85-M motherboard with Coreboot

On Wednesday, September 21, 2016 11:19:05 AM Piotr Kubaj wrote: > I'm trying to boot the ASUS F2A85-M board with flashed Coreboot 4.4 and > SeaBIOS 1.9.1 as a payload. > > This board works nicely with stock UEFI, it can also boot Slackware 14.2 > from Coreboot with SeaBIOS without any issues. > >

Re: Destroy GPT partition scheme absolutely, how?

On Tuesday, September 27, 2016 12:36:22 AM Ngie Cooper wrote: > > > On Sep 26, 2016, at 22:48, Ernie Luzar wrote: > > ... > > > This little script has been posted before. Maybe it will be what your > > looking for. Called gpart.nuke > > > > #! /bin/sh > > echo "What disk do you want" > > echo

Re: Panic @306337: Duplicate free of 0xfffff8000ef61500 from zone 0xfffff8000772b000(mbuf) slab 0xfffff8000ef61f90(5)

On Mon, 26 Sep 2016, David Wolfskill wrote: > > I tried "panic" at the laptop's "db> " prompt, but I have no crash dump. IIRC, just 'dump' is supposed to work these days. Also 'call doadump' which is older. 'panic' does more stuff and is somewhat more likely to fail than directly dumping. -Ben

Re: urtwn(4) / rtwn(4) drivers are merged - call for testing (Was: RTL8812AU / RTL8821AU driver)

> On 26 Sep 2016, at 17:10, Andriy Voskoboinyk wrote: > > Mon, 26 Sep 2016 23:02:15 +0300 було написано Renato Botelho > : > > No, warnings are for 'untested' parts (although I think they are not the > reason...) > > Can you send messages.log when > dev.rtwn.0.debug=0x829f > is set? Sure, her

Re: urtwn(4) / rtwn(4) drivers are merged - call for testing (Was: RTL8812AU / RTL8821AU driver)

Mon, 26 Sep 2016 23:02:15 +0300 було написано Renato Botelho : No, warnings are for 'untested' parts (although I think they are not the reason...) Can you send messages.log when dev.rtwn.0.debug=0x829f is set? I’ve built and loaded it and the error is gone. But ‘list scan’ never show anythi

Re: urtwn(4) / rtwn(4) drivers are merged - call for testing (Was: RTL8812AU / RTL8821AU driver)

> On 26 Sep 2016, at 16:53, Andriy Voskoboinyk wrote: > > Mon, 26 Sep 2016 22:46:58 +0300 було написано Renato Botelho > mailto:ga...@freebsd.org>>: > > AFAIK, it is not critical (at least for USB devices). > > If it won't work without firmware try to install it from > sys/modules/rtwnfw/rtwnr

Re: urtwn(4) / rtwn(4) drivers are merged - call for testing (Was: RTL8812AU / RTL8821AU driver)

Mon, 26 Sep 2016 22:46:58 +0300 було написано Renato Botelho : AFAIK, it is not critical (at least for USB devices). If it won't work without firmware try to install it from sys/modules/rtwnfw/rtwnrtl8192cEB (and restart the interface). On 1 Sep 2016, at 13:29, Andriy Voskoboinyk wrote: Hi

Re: urtwn(4) / rtwn(4) drivers are merged - call for testing (Was: RTL8812AU / RTL8821AU driver)

> On 1 Sep 2016, at 13:29, Andriy Voskoboinyk wrote: > > Hi everyone, > > rtwn(4), urtwn(4) and urtwm (from previous emails) drivers were merged into a > single rtwn driver (plus rtwn_usb / rtwn_pci device glue); the code is > available on https://github.com/s3erios/rtwn repository. Among bugfix

Jenkins build is back to normal : FreeBSD_HEAD #710

See ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 11.0-RC1 boot prompt kernel load issue.

As I said, the only way I know to debug this is to start adding printfs in various parts of the boot loader to find out which EFI or BIOS call triggers the panic and then trying to infer from that what the BIOS routine might not like. If you think it is disk related, then the sys/boot/i386/libi386

Build failed in Jenkins: FreeBSD_HEAD #709

See -- [...truncated 352043 lines...] [192.168.10.2] out: lib/libarchive/functional_test:test_read_format_zip_malformed -> passed [0.097s] [192.168.10.2] out: lib/libarchive/functional_test:test_read_f

Re: Panic @306337: Duplicate free of 0xfffff8000ef61500 from zone 0xfffff8000772b000(mbuf) slab 0xfffff8000ef61f90(5)

On Mon, Sep 26, 2016 at 08:48:19AM -0700, hiren panchasara wrote: > On 09/26/16 at 05:11P, David Wolfskill wrote: > > Source upgrade from r306307 to r306337 completed OK; this was on build > > machine (laptop is "Installing everything" as I type). Serial console > > (on panicked build machine) rea

Re: Panic @306337: Duplicate free of 0xfffff8000ef61500 from zone 0xfffff8000772b000(mbuf) slab 0xfffff8000ef61f90(5)

On 09/26/16 at 05:11P, David Wolfskill wrote: > Source upgrade from r306307 to r306337 completed OK; this was on build > machine (laptop is "Installing everything" as I type). Serial console > (on panicked build machine) reads: Seems like my fault with r306337. Bruce also has some issues/concerns

Re: Destroy GPT partition scheme absolutely, how?

> On Sep 26, 2016, at 22:48, Ernie Luzar wrote: ... > This little script has been posted before. Maybe it will be what your looking > for. Called gpart.nuke > > #! /bin/sh > echo "What disk do you want" > echo "to wipe? For example - da1 :" > read disk > echo "OK, in 10 seconds I will destroy

Re: Destroy GPT partition scheme absolutely, how?

On 09/26/2016 11:08, Gary Jennejohn wrote: > On Mon, 26 Sep 2016 09:48:22 -0400 > Ernie Luzar wrote: > >> Hartmann, O. wrote: >>> I ran into a very nasty and time consuming problem. Creating a NanoBSD >>> image with a modified script framework creating GPT partitions, I put >>> the imaes via "dd(

Re: Destroy GPT partition scheme absolutely, how?

On Mon, 26 Sep 2016 09:48:22 -0400 Ernie Luzar wrote: > Hartmann, O. wrote: > > I ran into a very nasty and time consuming problem. Creating a NanoBSD > > image with a modified script framework creating GPT partitions, I put > > the imaes via "dd(1)" on USB flash or SD flash. Because the images a

Re: Destroy GPT partition scheme absolutely, how?

Hartmann, O. wrote: I ran into a very nasty and time consuming problem. Creating a NanoBSD image with a modified script framework creating GPT partitions, I put the imaes via "dd(1)" on USB flash or SD flash. Because the images are usually much smaller than the overall capacity of the USB or SD,

Re: Destroy GPT partition scheme absolutely, how?

Hartmann, O. wrote on 09/26/2016 15:01: [...] Using a fresh/new SD or USB resolves the problem. But the question remains: how can I destroy any relevant GPT information on a Flash drive (or even harddisk) to avoid unwanted remains of an foul image installation? First guess was to write the las

Destroy GPT partition scheme absolutely, how?

I ran into a very nasty and time consuming problem. Creating a NanoBSD image with a modified script framework creating GPT partitions, I put the imaes via "dd(1)" on USB flash or SD flash. Because the images are usually much smaller than the overall capacity of the USB or SD, the OS (FreeBSD CURREN

Panic @306337: Duplicate free of 0xfffff8000ef61500 from zone 0xfffff8000772b000(mbuf) slab 0xfffff8000ef61f90(5)

Source upgrade from r306307 to r306337 completed OK; this was on build machine (laptop is "Installing everything" as I type). Serial console (on panicked build machine) reads: ... Setting hostname: freebeast.catwhisker.org. Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,N

[CUURENT] NLM: failed to contact remote rpcbind, stat = 0, port = 0

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Since ~ 2 days now I get this log messages all over cleinst mounting a NFS folder from a server: NLM: failed to contact remote rpcbind, stat = 0, port = 0 I'm now on CURRENT, FreeBSD 12.0-CURRENT #4 r306320: Sun Sep 25 21:35:59 CEST 2016. The N