automount usb msdosfs no partition table

2017-10-08 Thread Tomasz CEDRO
Hello world :-)

I need to configure automount for a testing machine. It seems to work
fine, except for two issues:

1. Mount point does not disappear after device disappears, what makes
things harder to script when device is gone. automount -c does not
remove the mountpoint, only restarting the service does. It is a bug
or feature?

2. Automounter does not mount USB Pendrive / MSDOSFS devices that does
not have a parition table. Some USB Drives does not have valid
partition table, they appear as /dev/da0 and can be mounted with
mount_msdosfs /dev/da0 /mnt, but they are not recognised by
automounter.. how can I make it work with such devices?

Any hints appreciated :-)
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: 10.4 release - is the binary update corrupt?

2017-10-08 Thread Dr Josef Karthauser
> On 8 Oct 2017, at 12:04, Matthew Seaman  wrote:
> 
>> Am Sonntag, 8. Oktober 2017 schrieb Dr Josef Karthauser:
>>> Hi,
>>> 
>>> I’m having trouble upgrading a 10.3 machine to 10.4: looks like something 
>>> is corrupt:
>>> 
>>> Fetching metadata signature for 10.4-RELEASE from update4.freebsd.org... 
>>> done.
>>> Fetching metadata index... done.
>>> Fetching 1 metadata patches. done.
>>> Applying metadata patches... done.
>>> Fetching 1 metadata files... done.
>>> Inspecting system... done.
>>> Fetching files from 10.3-RELEASE for merging... done.
>>> Preparing to download files... done.
>>> Fetching 38573 
>>> patches.102030405060708090100110120130140…
>>> [cut]
>>> Applying patches... done.
>>> Fetching 9266 files...
>>> gunzip: (stdin): unexpected end of file
>>> efb4027db1ae440353955aa1bcfc9c69d1cafbdb53b4bfc6584d64b1e1bfd209 has 
>>> incorrect hash.
>>> 
>>> Has anyone else also seen this?
>>> 
> 
> With luck you've only got a problem with that one patch file, but if the
> corruption is much wider, then moving aside your existing
> /var/db/freebsd-update and starting again from scratch is probably a
> good idea.
> 
> If you consistently get broken patch files from whichever of the update
> servers you get directed to, that probably means that update server
> needs some TLC.  Please do report that to clusteradm@... While waiting
> for them to sort out the problems, you can play with the 'ServerName'
> parameter in /etc/freebsd-update.conf to point yourself towards some
> other server.

I’ve upgrade from 10.1 today to 10.2, then 10.3; and only had this problem
moving to 10.4. I can’t see how a file could have become corrupt in transit
- TCP protects against that kind of thing. :)

I’ll try moving the damaged file aside and see if that fixes anything and
report back.

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

Re: dd: vm_fault: pager read error

2017-10-08 Thread Eugene Grosbein
09.10.2017 1:23, grarpamp пишет:
> Here is a report of a repeatable unrecoverable problem.
> 
> 11.0 release amd64 r306420
> 
> kern.geom.debugflags=0 (unmodified)
> 
> # dd if=/dev/zero of=/dev/ada0s1 seek=2048 count=1 bs=1m
> 1+0 records in
> 1+0 records out
> 1048576 bytes transferred
> 
> # reboot
> # 

The problem is known and already fixed. You should upgrade.


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

dd: vm_fault: pager read error

2017-10-08 Thread grarpamp
Here is a report of a repeatable unrecoverable problem.

11.0 release amd64 r306420

kern.geom.debugflags=0 (unmodified)

# dd if=/dev/zero of=/dev/ada0s1 seek=2048 count=1 bs=1m
1+0 records in
1+0 records out
1048576 bytes transferred

# reboot
# 
The same goes for any other uncached access to the
filesystem in ada0s1a (Note: / is on s1a, dd occurs past
that), ie all first use of commands that read disk.

Repeating scrolling the console...
"
vnode_pager_generic_getpages_done: I/O read error 5
vm_fault: pager read error, pid 1 (init)
"

Requires HW reset button, then after system comes back
up, all layout, filesystems, and data are fine.

Repeatable every time.

Also,

# echo '' | dd of=/dev/ada0s1 seek=2048 count=1 bs=1m conv=sync

does get written to disk and is readable upon reboot,

# dd if=/dev/ada0s1 skip=2048 count=1 bs=1m
# 

wherein that read does not trigger the fault,
only the write of the string does.

All the layout offsets and sizes add up sequentially, no overlap,
the relavant portions are below, disk is <~= 250G,
gpart, fdisk, boot0cfg, bsdlabel all concur without error,
and were done with the live release tool versions.

What am I overlooking, or is this kernel behaviour a bug?

=>   63xada0  MBR  (XG)
 63  1  - free -  (512B)
 648388608  ada0s1  freebsd  [active]  (4.0G)
8388672  109051904  ada0s2  freebsd  (52G)

=>  0  8388608   ada0s1  BSD  (4.0G)
0  4194304  ada0s1a  freebsd-ufs  (2.0G) /
  4194304  4194304   - free -  (2.0G)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: console-only freebsd

2017-10-08 Thread Brian Reichert
On Sat, Oct 07, 2017 at 04:43:08PM +0200, Polytropon wrote:
> On Sat, 7 Oct 2017 15:20:19 +0100, tech-lists wrote:
> > what program or port would one use to view a gif or jpg file?
> 
> Additional thought:
> 
> With vt, default text modes are typically much bigger than
> the traditional 80x25 of sc. With the "block graphics" and
> maybe ASCII art + foreground / background color attributes,
> maybe there is a viewer that converts the image into "text
> with control characters" that can be displayed directy in
> the vt text mode, without using any graphics?
> 
> Just a stupid thought... ;-)

I wonder if AA-lib is still viable; it was fun to play with back in
the day: :)

  http://aa-project.sourceforge.net/index.html

> -- 
> Polytropon
> Magdeburg, Germany
> Happy FreeBSD user since 4.0
> Andra moi ennepe, Mousa, ...
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

-- 
Brian Reichert  
BSD admin/developer at large
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: 10.4 release - is the binary update corrupt?

2017-10-08 Thread Matthew Seaman
On 08/10/2017 11:27, Dr. Nikolaus Klepp wrote:
> Hi!
> 
> My notes suggest for this case:
> 
> pkg clean # cleans /var/cache/pkg/
> rm -rf /var/cache/pkg/*   # just remove it all
> pkg update -f # forces update  of repository catalog
> rm /var/db/pkg/repo-*.sqlite  # removes all remote repository catalogs
> pkg bootstrap -f  # forces reinstall of pkg
> 
> Do NOT delete /var/db/pkg/local.sqlite! It contains the database with your 
> installed packages. If you remove it the system will think you have nothing 
> installed. 
> 
> Nik
> 
> Am Sonntag, 8. Oktober 2017 schrieb Dr Josef Karthauser:
>> Hi,
>>
>> I’m having trouble upgrading a 10.3 machine to 10.4: looks like something is 
>> corrupt:
>>
>> Fetching metadata signature for 10.4-RELEASE from update4.freebsd.org... 
>> done.
>> Fetching metadata index... done.
>> Fetching 1 metadata patches. done.
>> Applying metadata patches... done.
>> Fetching 1 metadata files... done.
>> Inspecting system... done.
>> Fetching files from 10.3-RELEASE for merging... done.
>> Preparing to download files... done.
>> Fetching 38573 
>> patches.102030405060708090100110120130140…
>> [cut]
>> Applying patches... done.
>> Fetching 9266 files...
>> gunzip: (stdin): unexpected end of file
>> efb4027db1ae440353955aa1bcfc9c69d1cafbdb53b4bfc6584d64b1e1bfd209 has 
>> incorrect hash.
>>
>> Has anyone else also seen this?
>>
>> Cheers,
>> Joe
>> — 
>> Dr Josef Karthauser
>> Chief Technical Officer
>> (01225) 300371 / (07703) 596893
>> www.truespeed.com 
>>   / theTRUESPEED  
>>   @theTRUESPEED 
>>  
>> This email contains TrueSpeed information, which may be privileged or 
>> confidential. It's meant only for the individual(s) or entity named above. 
>> If you're not the intended recipient, note that disclosing, copying, 
>> distributing or using this information is prohibited. If you've received 
>> this email in error, please let me know immediately on the email address 
>> above. Thank you.
>> We monitor our email system, and may record your emails.

How exactly does blowing away your package cache or destroying your
package DB help with sorting out freebsd-update(8)?  That is fixing the
wrong problem...

To answer the OPs actual query -- yes, something is wrong with at least
one of the patches you have downloaded with freebsd-update(8).  You
should be able to find that broken patch file by name somewhere under
/var/db/freebsd-update -- simply removing that patch file and trying
again with 'freebsd-update fetch' _should_ get you an uncorrupted copy
of that particular patch.  In principle you can check all the patches
for correctness as the patch filename is the SHA hash of the contents,
although you'll have to work out exactly which SHA variant is being
used, and whether the checksum has been calculated on the compressed
patch as downloaded or on the de-compressed content.

With luck you've only got a problem with that one patch file, but if the
corruption is much wider, then moving aside your existing
/var/db/freebsd-update and starting again from scratch is probably a
good idea.

If you consistently get broken patch files from whichever of the update
servers you get directed to, that probably means that update server
needs some TLC.  Please do report that to clusteradm@... While waiting
for them to sort out the problems, you can play with the 'ServerName'
parameter in /etc/freebsd-update.conf to point yourself towards some
other server.

Cheers,

Matthew



signature.asc
Description: OpenPGP digital signature


Re: 10.4 release - is the binary update corrupt?

2017-10-08 Thread Dr. Nikolaus Klepp
Hi!

My notes suggest for this case:

pkg clean   # cleans /var/cache/pkg/
rm -rf /var/cache/pkg/* # just remove it all
pkg update -f   # forces update  of repository catalog
rm /var/db/pkg/repo-*.sqlite# removes all remote repository catalogs
pkg bootstrap -f# forces reinstall of pkg

Do NOT delete /var/db/pkg/local.sqlite! It contains the database with your 
installed packages. If you remove it the system will think you have nothing 
installed. 

Nik

Am Sonntag, 8. Oktober 2017 schrieb Dr Josef Karthauser:
> Hi,
> 
> I’m having trouble upgrading a 10.3 machine to 10.4: looks like something is 
> corrupt:
> 
> Fetching metadata signature for 10.4-RELEASE from update4.freebsd.org... done.
> Fetching metadata index... done.
> Fetching 1 metadata patches. done.
> Applying metadata patches... done.
> Fetching 1 metadata files... done.
> Inspecting system... done.
> Fetching files from 10.3-RELEASE for merging... done.
> Preparing to download files... done.
> Fetching 38573 
> patches.102030405060708090100110120130140…
> [cut]
> Applying patches... done.
> Fetching 9266 files...
> gunzip: (stdin): unexpected end of file
> efb4027db1ae440353955aa1bcfc9c69d1cafbdb53b4bfc6584d64b1e1bfd209 has 
> incorrect hash.
> 
> Has anyone else also seen this?
> 
> Cheers,
> Joe
> — 
> Dr Josef Karthauser
> Chief Technical Officer
> (01225) 300371 / (07703) 596893
> www.truespeed.com 
>   / theTRUESPEED  
>   @theTRUESPEED 
>  
> This email contains TrueSpeed information, which may be privileged or 
> confidential. It's meant only for the individual(s) or entity named above. If 
> you're not the intended recipient, note that disclosing, copying, 
> distributing or using this information is prohibited. If you've received this 
> email in error, please let me know immediately on the email address above. 
> Thank you.
> We monitor our email system, and may record your emails.
> 
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"



-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA, CIA ...
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

10.4 release - is the binary update corrupt?

2017-10-08 Thread Dr Josef Karthauser
Hi,

I’m having trouble upgrading a 10.3 machine to 10.4: looks like something is 
corrupt:

Fetching metadata signature for 10.4-RELEASE from update4.freebsd.org... done.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Fetching 1 metadata files... done.
Inspecting system... done.
Fetching files from 10.3-RELEASE for merging... done.
Preparing to download files... done.
Fetching 38573 
patches.102030405060708090100110120130140…
[cut]
Applying patches... done.
Fetching 9266 files...
gunzip: (stdin): unexpected end of file
efb4027db1ae440353955aa1bcfc9c69d1cafbdb53b4bfc6584d64b1e1bfd209 has incorrect 
hash.

Has anyone else also seen this?

Cheers,
Joe
— 
Dr Josef Karthauser
Chief Technical Officer
(01225) 300371 / (07703) 596893
www.truespeed.com 
  / theTRUESPEED  
  @theTRUESPEED 
 
This email contains TrueSpeed information, which may be privileged or 
confidential. It's meant only for the individual(s) or entity named above. If 
you're not the intended recipient, note that disclosing, copying, distributing 
or using this information is prohibited. If you've received this email in 
error, please let me know immediately on the email address above. Thank you.
We monitor our email system, and may record your emails.

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