Re: Destroy GPT partition scheme absolutely, how?

[Warner Losh]

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 slower or unreliable).
>
> Yeah, but it would be nicer to not have to know that particular magic 
> incarnation :)

Disk formatting has always been 3 parts magic, 2 parts luck and 1 part skill :)

It doesn't fit nicely into geom because metadata can live elsewhere.

I forgot to add the caveat not to try this on a disk that is part of a
RAID volume.

Warner
___
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: Destroy GPT partition scheme absolutely, how?

[O'Connor, Daniel]

> 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 to know that particular magic 
incarnation :)

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

___
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: Destroy GPT partition scheme absolutely, how?

[Warner Losh]

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 GPT intact and the disk will come up with the old
>> GPT partitions, not as a raw disk.
>
> I wonder how feasible it would be to have a command which runs destroy for 
> every known partition scheme on a particular device..
>
> Sure there would be some duplicate zeroing but it's not likely to be 
> significantly slower and considerably more robust.

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).

Warner
___
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: Destroy GPT partition scheme absolutely, how?

[O. Hartmann]

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 wipe? For example - da1 :"
> > read disk
> > echo "OK, in 10 seconds I will destroy all data on $disk!"
> > echo "Press CTRL+C to abort!"
> > sleep 10
> > diskinfo ${disk} | while read disk sectorsize size sectors other
> > do
> > # Delete MBR and partition table.
> > dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} count=1
> > # Delete GEOM metadata.
> > dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} oseek=`expr $sectors - 2`
> > count=2 done  
> 
> Why not just use "gpart destroy -F provider"?
> 
> Cheers,
> -Ngie
> ___
> 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"

Yes, why not :-(

Maybe panic and too much swet on the forehead ... ;-) Thanks.
___
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: Destroy GPT partition scheme absolutely, how?

[O. Hartmann]

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 are
> > usually much smaller than the overall capacity of the USB or SD, the OS
> > (FreeBSD CURRENT, recently built as of this morning) complains about
> > the second GPT header isn't in the last LBA. Sometimes, my PCengines
> > APU2 doesn't boot then, a relief is to issue the command 
> > 
> > gpart recover da1
> > 
> > (in that case, the USB flash drive or SD flash is recognized
> > as /dev/da1).
> > 
> > But I run into a nasty situation, if the image put to the flash is
> > somehow corrupted. Then I tried to write a second, repaired image over
> > the first one using dd(1) again and do a recovering as mentioned above
> > - but this is fatal in two ways. First, the corrupted/broken GPT seems
> > to be "recovered" and put in replacement of the correct one - so I
> > guess. Performing no recover leaves the image on flash corrupted
> > anyway.
> > 
> > Well, to be honest, I didn't exactly know what is going on here. The
> > phenomenon is that I had a problem creating a NANO_DATASIZE= DATA
> > partition with an empty NANO_DATASIZE which somehow corrupted the
> > whole image. The image then never booted, complaining,
> > that /foo/bar/_.mnt was unmounted unleanly.
> > 
> > This happened multiple times, even if I tried to overwrite the SD or
> > USB flash with /dev/zero or /dev/random data, but I do stop such a dd
> > after a couple f minutes, since the SD is 32GB in size and the USB
> > flash drive is 32 GB, 64 GB and 128 GB - a pain in the ass if you want
> > to write via USB 2.0. But even with overwriting with a good image then
> > results in a corrupt image on flash drive, complaining about the GPT
> > second header not in last LBA and the issue with the uncleanly
> > unmount _.mnt (from the creation process of the NanoBSD image)! 
> > 
> > So I guess there is something magic happening. Some informations are
> > not lost and I suspect the "recovery" moving those foul data into
> > active places.
> > 
> > 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 last couple of bytes on such a flash drive
> > by letting dd(1) counting backwards, but I couldn't figure out how to
> > let dd(1) do such a procedure. The nightmare didn't end, while trying,
> > the SD flash card died :-(
> > 
> > thank you very much for your help and thoughts.
> > 
> > Kind regards, thanks in advance,
> > 
> >
> 
> 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 all data on $disk!"
> echo "Press CTRL+C to abort!"
> sleep 10
> diskinfo ${disk} | while read disk sectorsize size sectors other
> do
>   # Delete MBR and partition table.
>   dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} count=1
>   # Delete GEOM metadata.
>   dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} oseek=`expr $sectors 
> - 2` count=2
> done
> 
> ___
> 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"

Thank you very much.
___
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: Destroy GPT partition scheme absolutely, how?

[O'Connor, Daniel]

> 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 partitions, not as a raw disk.

I wonder how feasible it would be to have a command which runs destroy for 
every known partition scheme on a particular device..

Sure there would be some duplicate zeroing but it's not likely to be 
significantly slower and considerably more robust.

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

___
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: [VBox] Extreme slow UDP performance between host and guest

[Eric Joyner]

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 do a quick experiment on the UDP performance between
> VirtualBox and Guest through vboxnetadp. Guest is acting as server and Host
> machine is acting as client. the UDP throughput is only 1/350 of TCP
> throughput.
>
> Guest kernel is -Current and Host Kernel is 11.0-RC2. Anyone has idea? is
> there any known issue in vboxnetadp?
>
> 
> Client connecting to 192.168.0.60, UDP port 5001
> Sending 1470 byte datagrams
> UDP buffer size: 9.00 KByte (default)
> 
> [  3] local 192.168.0.1 port 48290 connected with 192.168.0.60 port 5001
> [ ID] Interval   Transfer Bandwidth
> [  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec
> [  3] Sent 893 datagrams
> [  3] Server Report:
> [  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec   0.039 ms0/  893 (0%)
>
> 
> Client connecting to 192.168.0.60, UDP port 5001
> Sending 4096 byte datagrams
> UDP buffer size: 9.00 KByte (default)
> 
> [  3] local 192.168.0.1 port 58009 connected with 192.168.0.60 port 5001
> [ ID] Interval   Transfer Bandwidth
> [  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec
> [  3] Sent 321 datagrams
> [  3] Server Report:
> [  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec   0.100 ms0/  321 (0%)
>
> 
> Client connecting to 192.168.0.60, TCP port 5001
> TCP window size: 32.8 KByte (default)
> 
> [  3] local 192.168.0.1 port 15490 connected with 192.168.0.60 port 5001
> [ ID] Interval   Transfer Bandwidth
> [  3]  0.0-10.0 sec   447 MBytes   374 Mbits/sec
>
>
> -Howard
>
> --
> -Howard
> ___
> 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"
>
___
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: Freeze during booting of ASUS F2A85-M motherboard with Coreboot

[John Baldwin]

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.
> 
> But it seems to have problems with FreeBSD (I've tried 11.0-RC3 and
> later 12.0-CURRENT). That's why I'm posting it here, instead of Coreboot
> mailing lists.
> 
> Booting freezes after printing:
> pcib1: failed to allocate initial I/O port window: 0x1000-0x1fff

Do you get this message in a verbose dmesg with the stock UEFI?

-- 
John Baldwin
___
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: Destroy GPT partition scheme absolutely, how?

[John Baldwin]

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 "to wipe? For example - da1 :"
> > read disk
> > echo "OK, in 10 seconds I will destroy all data on $disk!"
> > echo "Press CTRL+C to abort!"
> > sleep 10
> > diskinfo ${disk} | while read disk sectorsize size sectors other
> > do
> > # Delete MBR and partition table.
> > dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} count=1
> > # Delete GEOM metadata.
> > dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} oseek=`expr $sectors - 2` 
> > count=2
> > done
> 
> Why not just use "gpart destroy -F provider"?

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 partitions, not as a raw disk.

-- 
John Baldwin
___
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: Panic @306337: Duplicate free of 0xfffff8000ef61500 from zone 0xfffff8000772b000(mbuf) slab 0xfffff8000ef61f90(5)

[Benjamin Kaduk]

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
___
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: urtwn(4) / rtwn(4) drivers are merged - call for testing (Was: RTL8812AU / RTL8821AU driver)

[Renato Botelho]

> 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, here it is

rtwn0:  port 0x4000-0x40ff mem 0xf1c0-0xf1c03fff at 
device 0.0 on pci2
rtwn0: r92ce_attach: warning: hardware crypto enabled
rtwn0: MAC/BB RTL8188CE, RF 6052 1T1R
wlan0: Ethernet address: e0:06:e6:c7:54:73
rtwn0: r92ce_post_init: warning: net80211 ratectl is used
rtwn0: rtwn_raw_xmit: called; m 0xf80010f7e700, ni 0xfe0015226000
rtwn0: r92ce_dump_tx_desc: len 42, off 64, flags0 8D, dw: 1 00041201, 2 
, 3  (seq ), 4 0180, 5 1F00, 6 , size 002A, pad 
, addr: 10FF46E8 (64: ), next: 050B0E40 (64: ), rsvd: 
   
rtwn0: rtwn_pci_intr: status , tx_rings 0008
rtwn0: rtwn_pci_tx_done: qid 3, last 56, cur 57
rtwn0: rtwn_raw_xmit: called; m 0xf80010f7e700, ni 0xfe0015226000
rtwn0: r92ce_dump_tx_desc: len 42, off 64, flags0 8D, dw: 1 00041201, 2 
, 3  (seq ), 4 0180, 5 1F00, 6 , size 002A, pad 
, addr: 10FF46E8 (64: ), next: 050B0E80 (64: ), rsvd: 
   
rtwn0: rtwn_pci_intr: status , tx_rings 0008
rtwn0: rtwn_pci_tx_done: qid 3, last 57, cur 58
rtwn0: rtwn_raw_xmit: called; m 0xf80038177400, ni 0xfe0015226000
rtwn0: r92ce_dump_tx_desc: len 42, off 64, flags0 8D, dw: 1 00041201, 2 
, 3  (seq ), 4 0180, 5 1F00, 6 , size 002A, pad 
, addr: 381BD6E8 (64: ), next: 050B0EC0 (64: ), rsvd: 
   
rtwn0: rtwn_pci_intr: status , tx_rings 0008
rtwn0: rtwn_pci_tx_done: qid 3, last 58, cur 59
rtwn0: rtwn_raw_xmit: called; m 0xf80038477900, ni 0xfe0015226000
rtwn0: r92ce_dump_tx_desc: len 42, off 64, flags0 8D, dw: 1 00041201, 2 
, 3  (seq ), 4 0180, 5 1F00, 6 , size 002A, pad 
, addr: 384EA6E8 (64: ), next: 050B0F00 (64: ), rsvd: 
   
rtwn0: rtwn_pci_intr: status , tx_rings 0008
rtwn0: rtwn_pci_tx_done: qid 3, last 59, cur 60
rtwn0: rtwn_raw_xmit: called; m 0xf80010f7e700, ni 0xfe0015226000
rtwn0: r92ce_dump_tx_desc: len 42, off 64, flags0 8D, dw: 1 00041201, 2 
, 3  (seq ), 4 0180, 5 1F00, 6 , size 002A, pad 
, addr: 10FF46E8 (64: ), next: 050B0F40 (64: ), rsvd: 
   
rtwn0: rtwn_pci_intr: status , tx_rings 0008
rtwn0: rtwn_pci_tx_done: qid 3, last 60, cur 61
rtwn0: rtwn_raw_xmit: called; m 0xf80038055000, ni 0xfe0015226000
rtwn0: r92ce_dump_tx_desc: len 42, off 64, flags0 8D, dw: 1 00041201, 2 
, 3  (seq ), 4 0180, 5 1F00, 6 , size 002A, pad 
, addr: 3809BEE8 (64: ), next: 050B0F80 (64: ), rsvd: 
   
rtwn0: rtwn_pci_intr: status , tx_rings 0008
rtwn0: rtwn_pci_tx_done: qid 3, last 61, cur 62
rtwn0: rtwn_raw_xmit: called; m 0xf80038211200, ni 0xfe0015226000
rtwn0: r92ce_dump_tx_desc: len 42, off 64, flags0 8D, dw: 1 00041201, 2 
, 3  (seq ), 4 0180, 5 1F00, 6 , size 002A, pad 
, addr: 382816E8 (64: ), next: 050B0FC0 (64: ), rsvd: 
   
rtwn0: rtwn_pci_intr: status , tx_rings 0008
rtwn0: rtwn_pci_tx_done: qid 3, last 62, cur 63
rtwn0: rtwn_raw_xmit: called; m 0xf80113eb7900, ni 0xfe0015226000
rtwn0: r92ce_dump_tx_desc: len 42, off 64, flags0 8D, dw: 1 00041201, 2 
, 3  (seq ), 4 0180, 5 1F00, 6 , size 002A, pad 
, addr: 08181000 (64: ), next: 050B1000 (64: ), rsvd: 
   
rtwn0: rtwn_pci_intr: status , tx_rings 0008
rtwn0: rtwn_pci_tx_done: qid 3, last 63, cur 64
rtwn0: rtwn_raw_xmit: called; m 0xf80038212000, ni 0xfe0015226000
rtwn0: r92ce_dump_tx_desc: len 42, off 64, flags0 8D, dw: 1 00041201, 2 
, 3  (seq ), 4 0180, 5 1F00, 6 , size 002A, pad 
, addr: 38289EE8 (64: ), next: 050B1040 (64: ), rsvd: 
   
rtwn0: rtwn_pci_intr: status , tx_rings 0008
rtwn0: rtwn_pci_tx_done: qid 3, last 64, cur 65
rtwn0: rtwn_raw_xmit: called; m 0xf80038206700, ni 0xfe0015226000
rtwn0: r92ce_dump_tx_desc: len 42, off 64, flags0 8D, dw: 1 00041201, 2 
, 3  (seq ), 4 0180, 5 1F00, 6 , size 002A, pad 
, addr: 382306E8 (64: ), next: 050B1080 (64: ), rsvd: 
   
rtwn0: rtwn_pci_intr: status , tx_rings 

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

[Andriy Voskoboinyk]

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 anything and I got this warning, not sure if it’s relevant


rtwn0:  port 0x4000-0x40ff mem 0xf1c0-0xf1c03fff  
at device 0.0 on pci2

rtwn0: r92ce_attach: warning: hardware crypto enabled
rtwn0: MAC/BB RTL8188CE, RF 6052 1T1R
wlan0: Ethernet address: e0:06:e6:c7:54:73
rtwn0: r92ce_post_init: warning: net80211 ratectl is used

Thanks

--
Renato Botelho

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

___
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: urtwn(4) / rtwn(4) drivers are merged - call for testing (Was: RTL8812AU / RTL8821AU driver)

[Renato Botelho]

> On 26 Sep 2016, at 16:53, Andriy Voskoboinyk  wrote:
> 
> 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).

I’ve built and loaded it and the error is gone. But ‘list scan’ never show 
anything and I got this warning, not sure if it’s relevant

rtwn0:  port 0x4000-0x40ff mem 0xf1c0-0xf1c03fff at 
device 0.0 on pci2
rtwn0: r92ce_attach: warning: hardware crypto enabled
rtwn0: MAC/BB RTL8188CE, RF 6052 1T1R
wlan0: Ethernet address: e0:06:e6:c7:54:73
rtwn0: r92ce_post_init: warning: net80211 ratectl is used

Thanks

--
Renato Botelho

___
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: urtwn(4) / rtwn(4) drivers are merged - call for testing (Was: RTL8812AU / RTL8821AU driver)

[Andriy Voskoboinyk]

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 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 bugfixes  
/

code deduplication, there some new features too:

1) multi-vap support (one any wireless interface + one STA interface +
any number of monitor mode interfaces).
2) few new sysctls:
* dev.rtwn.#.crypto - controls how to use hardware crypto acceleration
* dev.rtwn.#.ratectl_selected
* dev.rtwn.#.ratectl - selects current 'rate control' algorithm
(currently only 'none' and 'net80211' are supported; RTL8192CE needs  
testing

with the last).
3) (incomplete) power management support for RTL8188EU (requires  
firmware).

4) Short Guard Interval support.

It's known to work with RTL8188CUS, RTL8188EU and RTL8821AU; however,
it was never tested with RTL8192CE or RTL8812AU.

How-to-build:
1) download / checkout the repository.
2) apply 'patch-usbdevs.diff' against '/usr/src'
3) build and install rtwn module:
 cd $repository/sys/modules/rtwn && make && make install
4) build and install rtwn_usb/rtwn_pci:
 cd ../rtwn_usb && make && make install
 cd ../rtwn_pci && make && make install
5) unload previous && load current drivers:
 kldunload if_urtwn if_rtwn
 kldload /boot/modules/if_rtwn.ko /boot/modules/if_rtwn_usb.ko  
/boot/modules/if_rtwn_pci.ko

6) Use.


I have a Thinkpad T430 with a PCIe RTL8188CE. It fails waying I didn’ t  
load a firmware that doesn’ t exist:


rtwn0:  port 0x4000-0x40ff mem 0xf1c0-0xf1c03fff  
at device 0.0 on pci2

rtwn0: r92ce_attach: warning: hardware crypto enabled
rtwn0: MAC/BB RTL8188CE, RF 6052 1T1R
wlan0: Ethernet address: e0:06:e6:c7:54:73
rtwn-rtl8192cfwE_B: could not load firmware image, error 2
rtwn0: failed loadfirmware of file rtwn-rtl8192cfwE_B

I’ve loaded rtwn-rtl8192cfwU_B.ko, never heard of rtwn-rtl8192cfwE_B.ko

--
Renato Botelho

___
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: urtwn(4) / rtwn(4) drivers are merged - call for testing (Was: RTL8812AU / RTL8821AU driver)

[Renato Botelho]

> 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 bugfixes /
> code deduplication, there some new features too:
> 
> 1) multi-vap support (one any wireless interface + one STA interface +
> any number of monitor mode interfaces).
> 2) few new sysctls:
> * dev.rtwn.#.crypto - controls how to use hardware crypto acceleration
> * dev.rtwn.#.ratectl_selected
> * dev.rtwn.#.ratectl - selects current 'rate control' algorithm
> (currently only 'none' and 'net80211' are supported; RTL8192CE needs testing
> with the last).
> 3) (incomplete) power management support for RTL8188EU (requires firmware).
> 4) Short Guard Interval support.
> 
> It's known to work with RTL8188CUS, RTL8188EU and RTL8821AU; however,
> it was never tested with RTL8192CE or RTL8812AU.
> 
> How-to-build:
> 1) download / checkout the repository.
> 2) apply 'patch-usbdevs.diff' against '/usr/src'
> 3) build and install rtwn module:
>   cd $repository/sys/modules/rtwn && make && make install
> 4) build and install rtwn_usb/rtwn_pci:
>   cd ../rtwn_usb && make && make install
>   cd ../rtwn_pci && make && make install
> 5) unload previous && load current drivers:
>   kldunload if_urtwn if_rtwn
>   kldload /boot/modules/if_rtwn.ko /boot/modules/if_rtwn_usb.ko 
> /boot/modules/if_rtwn_pci.ko
> 6) Use.

I have a Thinkpad T430 with a PCIe RTL8188CE. It fails waying I didn’ t load a 
firmware that doesn’ t exist:

rtwn0:  port 0x4000-0x40ff mem 0xf1c0-0xf1c03fff at 
device 0.0 on pci2
rtwn0: r92ce_attach: warning: hardware crypto enabled
rtwn0: MAC/BB RTL8188CE, RF 6052 1T1R
wlan0: Ethernet address: e0:06:e6:c7:54:73
rtwn-rtl8192cfwE_B: could not load firmware image, error 2
rtwn0: failed loadfirmware of file rtwn-rtl8192cfwE_B

I’ve loaded rtwn-rtl8192cfwU_B.ko, never heard of rtwn-rtl8192cfwE_B.ko

--
Renato Botelho

___
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"

Jenkins build is back to normal : FreeBSD_HEAD #710

[jenkins-admin]

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.

[John Baldwin]

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/biosdisk.c (for non-EFI) and
sys/boot/efi/libefi/efipart.c are good places to start.

On Wednesday, September 21, 2016 03:12:05 PM Murthy Bhat wrote:
> Hi,
> 
> I checked both FreeBSD 11 RC2 and RC3 latest stable releases. Same issue 
> exists. When loading the kernel from USB pen drive at boot prompt, system 
> gets switched off.
> 
> Could you please help?
> 
> Regards/Ram
> 
> -Original Message-
> From: Murthy Bhat 
> Sent: Tuesday, August 30, 2016 8:03 PM
> To: 'John Baldwin' 
> Cc: freebsd-current@freebsd.org; FreeBSD-current@FreeBSD.org
> Subject: RE: FreeBSD 11.0-RC1 boot prompt kernel load issue.
> 
> Hi John,
> 
> Thanks for your quick response.
> 
> I did the same exercise on a super micro(X59SRL model) server, to segregate 
> the issue. The same issue is reproduced again.
> 
> So IMHO this may not be the system UEFI firmware issue due to following two 
> reasons.
> 1."load kernel" does not work on 2 different hardware platforms.
> 2.On FreeBSD 10.3 and 10.2, both the hardware platforms (HP ProLiant 
> ML110 Gen9 and Super micro X59SRL) work without problem.
> 
> Could you please advise some work around or any other exercise to narrow down 
> the issue.
> 
> Regards/Ram
> 
> 
> -Original Message-
> From: John Baldwin [mailto:j...@freebsd.org]
> Sent: Tuesday, August 30, 2016 3:57 AM
> To: Murthy Bhat 
> Cc: freebsd-current@freebsd.org; FreeBSD-current@FreeBSD.org
> Subject: Re: FreeBSD 11.0-RC1 boot prompt kernel load issue.
> 
> EXTERNAL EMAIL
> 
> 
> On Monday, August 29, 2016 05:37:57 PM Murthy Bhat wrote:
> > Thanks for the response.
> >
> > It is UEFI boot. As such there is no stack dumped on the console 
> > during crash. System restarts from the FreeBSD boot prompt without any 
> > message on the console. Still I have a picture where monitor goes off 
> > during data load. PFA(sorry for the flash)
> 
> Ugh.  I don't have a good suggestion on debugging this besides adding printfs 
> to the EFI loader code and/or moving an infinite loop around in the code to 
> narrow down exactly when it resets.  It is quite possibly specific to the EFI 
> firmware on your machine (at least, reproducing the issue might be).
> 
> > Regards/Murthy Bhat
> >
> > -Original Message-
> > From: John Baldwin [mailto:j...@freebsd.org]
> > Sent: Monday, August 29, 2016 10:52 PM
> > To: freebsd-current@freebsd.org
> > Cc: Murthy Bhat ; 
> > FreeBSD-current@FreeBSD.org
> > Subject: Re: FreeBSD 11.0-RC1 boot prompt kernel load issue.
> >
> > EXTERNAL EMAIL
> >
> >
> > On Wednesday, August 24, 2016 01:35:08 PM Murthy Bhat wrote:
> > >
> > > Hi,
> > >
> > > This is regarding issue faced during OS(FreeBSD 11.0-RC1) installation on 
> > > the storage behind our smartpqi storage controller.
> >
> > Are you using EFI or legacy boot?  Also, can you capture a screenshot of 
> > the crash messages?  If it is not EFI, we probably crashed in the BIOS 
> > routines used to read data from the USB drive.  It may be a BIOS bug (which 
> > isn't easily fixable), but we would need the register dump from the crash 
> > to figure anything out.
> >
> > --
> > John Baldwin
> 
> 
> --
> John Baldwin


-- 
John Baldwin
___
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"

Build failed in Jenkins: FreeBSD_HEAD #709

[jenkins-admin]

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_format_zip_msdos  
->  passed  [0.095s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_format_zip_nested  
->  passed  [0.090s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_zip_nofiletype  ->  passed  
[0.094s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_format_zip_padded1 
 ->  passed  [0.088s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_format_zip_padded2 
 ->  passed  [0.093s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_format_zip_padded3 
 ->  passed  [0.092s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_format_zip_sfx  -> 
 passed  [0.091s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_zip_traditional_encryption_data 
 ->  passed  [0.094s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_zip_winzip_aes128  ->  passed  
[0.116s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_zip_winzip_aes256  ->  passed  
[0.132s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_zip_winzip_aes256_large  ->  
passed  [0.160s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_zip_winzip_aes256_stored  ->  
passed  [0.141s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_format_zip_zip64a  
->  passed  [0.103s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_format_zip_zip64b  
->  passed  [0.092s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_large  ->  passed  
[0.511s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_pax_truncated  ->  
passed  [0.803s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_position  ->  
passed  [0.084s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_set_format  ->  
passed  [0.087s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_set_wrong_format  
->  passed  [0.085s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_too_many_filters  
->  passed  [0.091s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_truncated  ->  
passed  [0.146s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_truncated_filter_bzip2  ->  passed  
[0.662s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_truncated_filter_compress  ->  passed  
[0.273s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_truncated_filter_gzip  ->  passed  
[0.320s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_truncated_filter_lzip  ->  passed  
[0.918s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_truncated_filter_lzma  ->  passed  
[0.913s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_truncated_filter_lzop  ->  passed  
[0.100s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_truncated_filter_xz  ->  passed  
[0.977s]
[192.168.10.2] out: lib/libarchive/functional_test:test_sparse_basic  ->  
passed  [0.143s]
[192.168.10.2] out: lib/libarchive/functional_test:test_tar_filenames  ->  
passed  [0.232s]
[192.168.10.2] out: lib/libarchive/functional_test:test_tar_large  ->  passed  
[0.162s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_ustar_filename_encoding_CP1251_UTF8  ->  
passed  [0.098s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_ustar_filename_encoding_CP932_UTF8  ->  
passed  [0.095s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_ustar_filename_encoding_EUCJP_CP932  ->  
passed  [0.100s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_ustar_filename_encoding_EUCJP_UTF8  ->  
passed  [0.096s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_ustar_filename_encoding_KOI8R_CP866  ->  
passed  [0.100s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_ustar_filename_encoding_KOI8R_UTF8  ->  
passed  [0.093s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_ustar_filename_encoding_Russian_Russia  ->  
passed  [0.098s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_ustar_filename_encoding_UTF8_CP866  ->  
passed  [0.086s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_ustar_filename_encoding_ru_RU_CP1251  ->  
passed  [0.088s]
[192.168.10.2] out: lib/libarchive/functional_test:test_ustar_filenames  ->  
passed  [0.105s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_warn_missing_hardlink_target  ->  passed  
[0.086s]
[192.168.10.2] out: lib/libarchive/functional_test:test_write_disk  ->  passed  
[0.107s]
[192.168.10.2] out: lib/libarchive/functional_test:test_write_disk_appledouble  
->  passed  [0.085s]
[192.168.10.2] out: lib/libarchive/functional_test:test_write_disk_failures  -> 
 passed  [0.092s]
[192.168.10.2] out: 

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

[David Wolfskill]

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) reads:
> 
> Seems like my fault with r306337. Bruce also has some issues/concerns
> with it. I've reverted it for now with r306348 as I don't have time to
> deal with it right now.

OK; After (hand-)applying r306348 & rebuilding, I'm able to boot to
multi-user mode & login:

FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #118  
r306337M/306337:1200010: Mon Sep 26 09:31:45 PDT 2016 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

Thanks for the fix!

> Apologies for the trouble.

It's head; I expect a certain amount of turbulence on (a rare) occasion.

At least it actually built! :-)

> Cheers,
> Hiren

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

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

[hiren panchasara]

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
with it. I've reverted it for now with r306348 as I don't have time to
deal with it right now.

Apologies for the trouble.

Cheers,
Hiren


pgpGNumM9_to4.pgp
Description: PGP signature

Re: Destroy GPT partition scheme absolutely, how?

[Ngie Cooper]

> 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 all data on $disk!"
> echo "Press CTRL+C to abort!"
> sleep 10
> diskinfo ${disk} | while read disk sectorsize size sectors other
> do
> # Delete MBR and partition table.
> dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} count=1
> # Delete GEOM metadata.
> dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} oseek=`expr $sectors - 2` 
> count=2
> done

Why not just use "gpart destroy -F provider"?

Cheers,
-Ngie
___
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: Destroy GPT partition scheme absolutely, how?

[Nikolai Lifanov]

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(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 CURRENT, recently built as of this morning) complains about
>>> the second GPT header isn't in the last LBA. Sometimes, my PCengines
>>> APU2 doesn't boot then, a relief is to issue the command > > gpart recover 
>>> da1  
 (in that case, the USB flash drive or SD flash is recognized  
>>> as /dev/da1).  
 But I run into a nasty situation, if the image put to the flash is  
>>> somehow corrupted. Then I tried to write a second, repaired image over
>>> the first one using dd(1) again and do a recovering as mentioned above
>>> - but this is fatal in two ways. First, the corrupted/broken GPT seems
>>> to be "recovered" and put in replacement of the correct one - so I
>>> guess. Performing no recover leaves the image on flash corrupted
>>> anyway.  
 Well, to be honest, I didn't exactly know what is going on here. The  
>>> phenomenon is that I had a problem creating a NANO_DATASIZE= DATA
>>> partition with an empty NANO_DATASIZE which somehow corrupted the
>>> whole image. The image then never booted, complaining,
>>> that /foo/bar/_.mnt was unmounted unleanly.  
 This happened multiple times, even if I tried to overwrite the SD or  
>>> USB flash with /dev/zero or /dev/random data, but I do stop such a dd
>>> after a couple f minutes, since the SD is 32GB in size and the USB
>>> flash drive is 32 GB, 64 GB and 128 GB - a pain in the ass if you want
>>> to write via USB 2.0. But even with overwriting with a good image then
>>> results in a corrupt image on flash drive, complaining about the GPT
>>> second header not in last LBA and the issue with the uncleanly
>>> unmount _.mnt (from the creation process of the NanoBSD image)! > > So I 
>>> guess there is something magic happening. Some informations are
>>> not lost and I suspect the "recovery" moving those foul data into
>>> active places.  
 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 last couple of bytes on such 
>>> a flash drive
>>> by letting dd(1) counting backwards, but I couldn't figure out how to
>>> let dd(1) do such a procedure. The nightmare didn't end, while trying,
>>> the SD flash card died :-(  
 thank you very much for your help and thoughts.
 Kind regards, thanks in advance,

>> 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 all data on $disk!"
>> echo "Press CTRL+C to abort!"
>> sleep 10
>> diskinfo ${disk} | while read disk sectorsize size sectors other
>> do
>>   # Delete MBR and partition table.
>>   dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} count=1
>>   # Delete GEOM metadata.
>>   dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} oseek=`expr $sectors - 2` 
>> count=2
>> done
>>
> 
> I'm surprised that this script works without
>   sysctl kern.geom.debugflags=16
> 

You could just gpart destroy/create/destroy instead of doing arithmetic.

- Nikolai Lifanov

___
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: Destroy GPT partition scheme absolutely, how?

[Gary Jennejohn]

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 are
> > usually much smaller than the overall capacity of the USB or SD, the OS
> > (FreeBSD CURRENT, recently built as of this morning) complains about
> > the second GPT header isn't in the last LBA. Sometimes, my PCengines
> > APU2 doesn't boot then, a relief is to issue the command > > gpart recover 
> > da1  
> > > (in that case, the USB flash drive or SD flash is recognized  
> > as /dev/da1).  
> > > But I run into a nasty situation, if the image put to the flash is  
> > somehow corrupted. Then I tried to write a second, repaired image over
> > the first one using dd(1) again and do a recovering as mentioned above
> > - but this is fatal in two ways. First, the corrupted/broken GPT seems
> > to be "recovered" and put in replacement of the correct one - so I
> > guess. Performing no recover leaves the image on flash corrupted
> > anyway.  
> > > Well, to be honest, I didn't exactly know what is going on here. The  
> > phenomenon is that I had a problem creating a NANO_DATASIZE= DATA
> > partition with an empty NANO_DATASIZE which somehow corrupted the
> > whole image. The image then never booted, complaining,
> > that /foo/bar/_.mnt was unmounted unleanly.  
> > > This happened multiple times, even if I tried to overwrite the SD or  
> > USB flash with /dev/zero or /dev/random data, but I do stop such a dd
> > after a couple f minutes, since the SD is 32GB in size and the USB
> > flash drive is 32 GB, 64 GB and 128 GB - a pain in the ass if you want
> > to write via USB 2.0. But even with overwriting with a good image then
> > results in a corrupt image on flash drive, complaining about the GPT
> > second header not in last LBA and the issue with the uncleanly
> > unmount _.mnt (from the creation process of the NanoBSD image)! > > So I 
> > guess there is something magic happening. Some informations are
> > not lost and I suspect the "recovery" moving those foul data into
> > active places.  
> > > 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 last couple of bytes on such 
> > a flash drive
> > by letting dd(1) counting backwards, but I couldn't figure out how to
> > let dd(1) do such a procedure. The nightmare didn't end, while trying,
> > the SD flash card died :-(  
> > > thank you very much for your help and thoughts.
> > > Kind regards, thanks in advance,
> > >
> 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 all data on $disk!"
> echo "Press CTRL+C to abort!"
> sleep 10
> diskinfo ${disk} | while read disk sectorsize size sectors other
> do
>   # Delete MBR and partition table.
>   dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} count=1
>   # Delete GEOM metadata.
>   dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} oseek=`expr $sectors - 2` 
> count=2
> done
> 

I'm surprised that this script works without
sysctl kern.geom.debugflags=16

-- 
Gary Jennejohn
___
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: Destroy GPT partition scheme absolutely, how?

[Ernie Luzar]

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, the OS
(FreeBSD CURRENT, recently built as of this morning) complains about
the second GPT header isn't in the last LBA. Sometimes, my PCengines
APU2 doesn't boot then, a relief is to issue the command 


gpart recover da1

(in that case, the USB flash drive or SD flash is recognized
as /dev/da1).

But I run into a nasty situation, if the image put to the flash is
somehow corrupted. Then I tried to write a second, repaired image over
the first one using dd(1) again and do a recovering as mentioned above
- but this is fatal in two ways. First, the corrupted/broken GPT seems
to be "recovered" and put in replacement of the correct one - so I
guess. Performing no recover leaves the image on flash corrupted
anyway.

Well, to be honest, I didn't exactly know what is going on here. The
phenomenon is that I had a problem creating a NANO_DATASIZE= DATA
partition with an empty NANO_DATASIZE which somehow corrupted the
whole image. The image then never booted, complaining,
that /foo/bar/_.mnt was unmounted unleanly.

This happened multiple times, even if I tried to overwrite the SD or
USB flash with /dev/zero or /dev/random data, but I do stop such a dd
after a couple f minutes, since the SD is 32GB in size and the USB
flash drive is 32 GB, 64 GB and 128 GB - a pain in the ass if you want
to write via USB 2.0. But even with overwriting with a good image then
results in a corrupt image on flash drive, complaining about the GPT
second header not in last LBA and the issue with the uncleanly
unmount _.mnt (from the creation process of the NanoBSD image)! 


So I guess there is something magic happening. Some informations are
not lost and I suspect the "recovery" moving those foul data into
active places.

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 last couple of bytes on such a flash drive
by letting dd(1) counting backwards, but I couldn't figure out how to
let dd(1) do such a procedure. The nightmare didn't end, while trying,
the SD flash card died :-(

thank you very much for your help and thoughts.

Kind regards, thanks in advance,

 


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 all data on $disk!"
echo "Press CTRL+C to abort!"
sleep 10
diskinfo ${disk} | while read disk sectorsize size sectors other
do
 # Delete MBR and partition table.
 dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} count=1
 # Delete GEOM metadata.
 dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} oseek=`expr $sectors 
- 2` count=2

done

___
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: Destroy GPT partition scheme absolutely, how?

[Miroslav Lachman]

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 last couple of bytes on such a flash drive
by letting dd(1) counting backwards, but I couldn't figure out how to
let dd(1) do such a procedure. The nightmare didn't end, while trying,
the SD flash card died :-(


I use dd if=/dev/zero almost everytime when I need to install system on 
used HDD.


I rewrite about 10MB on its start and then about 10MB on the end.
I have some script to do this - simply takes media size from diskinfo 
command, substract 10MB and then dd with seek


Hope that it will help you

Miroslav Lachman

___
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"

Destroy GPT partition scheme absolutely, how?

[Hartmann, O.]

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 CURRENT, recently built as of this morning) complains about
the second GPT header isn't in the last LBA. Sometimes, my PCengines
APU2 doesn't boot then, a relief is to issue the command 

gpart recover da1

(in that case, the USB flash drive or SD flash is recognized
as /dev/da1).

But I run into a nasty situation, if the image put to the flash is
somehow corrupted. Then I tried to write a second, repaired image over
the first one using dd(1) again and do a recovering as mentioned above
- but this is fatal in two ways. First, the corrupted/broken GPT seems
to be "recovered" and put in replacement of the correct one - so I
guess. Performing no recover leaves the image on flash corrupted
anyway.

Well, to be honest, I didn't exactly know what is going on here. The
phenomenon is that I had a problem creating a NANO_DATASIZE= DATA
partition with an empty NANO_DATASIZE which somehow corrupted the
whole image. The image then never booted, complaining,
that /foo/bar/_.mnt was unmounted unleanly.

This happened multiple times, even if I tried to overwrite the SD or
USB flash with /dev/zero or /dev/random data, but I do stop such a dd
after a couple f minutes, since the SD is 32GB in size and the USB
flash drive is 32 GB, 64 GB and 128 GB - a pain in the ass if you want
to write via USB 2.0. But even with overwriting with a good image then
results in a corrupt image on flash drive, complaining about the GPT
second header not in last LBA and the issue with the uncleanly
unmount _.mnt (from the creation process of the NanoBSD image)! 

So I guess there is something magic happening. Some informations are
not lost and I suspect the "recovery" moving those foul data into
active places.

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 last couple of bytes on such a flash drive
by letting dd(1) counting backwards, but I couldn't figure out how to
let dd(1) do such a procedure. The nightmare didn't end, while trying,
the SD flash card died :-(

thank you very much for your help and thoughts.

Kind regards, thanks in advance,

oliver
___
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"

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

[David Wolfskill]

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,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
Feeding entropy: .
Starting Network: lo0 re0.
lo0: flags=8049 metric 0 mtu 16384
options=63
inet6 ::1 prefixlen 128 
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 
inet 127.0.0.1 WARNING: attempt to domain_add(bluetooth) after 
domainfinalize()
netmask 0xffWARNING: attempt to domain_add(netgraph) after domainfinalize()
00 
nd6 options=21
groups: lo 
re0: flags=8843 metric 0 mtu 1500

options=8209b 

I can leave the machine in this state & perform "directed pokes" at it,
given appropriate clues.

I'm about to try rebooting laptop (just finished similar upgrade);
I'll report back whether it behaves similarly or not, but I don't
expect to be able to leave it panicked (as I use it to access
everything else ).

...

Eh; I decided to defer sending this until I tried the laptop: it
had a similar panic, just after starting powerd.  On the laptop,
when it's running stable/11, the next things to pop up are the
startup messages for hald (which the build machine does not have)
and then sshd (which each machine runs).

The build machine runs a GENERIC kernel; laptop runs a slightly-customized
kernel (includes GENERIC & tweaks from there).

I tried "panic" at the laptop's "db> " prompt, but I have no crash dump.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

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

[O. Hartmann]

-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 NFS connection works, the folder can be mount by the client, but the log is 
flooded.

Regards,

Oliver
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJX6MmZAAoJEOgBcD7A/5N8N9oIAIZ68xwGMTPWmkTYvkPFRrtY
jP/jkcioGJ9+LA+BY756bA0/T6NvLuURFIBbWCGnj80Kx/5/mgUMn6qVBajep3b4
9mWbzSfTRENzf07OkTrGojgaVWpWRwr5Zec1z9Kg2SJGq3z2fF6fX3Vn1ASuPbD3
U/exzjq0ZXHvIlTHuiUWr/zw/epwvwbxPYhk3rN5kTvneseNQpKA54XktyZS04Tb
WfyoAqPm7myIE044XF4PR4SA4m9vPbkqJHsYMw9bCavvHAgA44dYgXu360tFJQYm
agcgUvZ0a1TLZUR6m+7KuCmVdepYwlO6MVKzTr0yP/gmRXayJl2aUflYjuDVx0U=
=rAOr
-END PGP SIGNATURE-
___
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"