Re: [gentoo-user] vsftpd anonymous upload illegal PORT command

[Walter Dnes]

On Mon, Aug 07, 2017 at 03:46:50PM +0100, Mick wrote

> >   I did manage to get the video game transferred with tftp, after a bit
> > of extra work.  I don't know if it's the old OS/2 Warp tftp client, or
> > part of the protocol, but it can only transfer files up to 33553920
> > bytes in size, i.e. 32 * 1024 * 1024 - 512 bytes.  32 megabytes looks
> > like some sort of coded-in limit.  I had to do the transfer in pieces
> > less than 32 megabytes.  I still want to get anonymous ftp working.
> 
> 
> Sounds obvious, but did you try using a different client to connect
> to the ftp server anonymously and see what you get?

  I originally tried with the ancient OS/2 Warp ftp client from inside
the QEMU VM.  Then I switched to testing the connection with net-ftp/ftp
from the Gentoo machine hosting the QEMU VM.  The Gentoo client gives
more verbose error messages, but fails just like the ancient OS/2 Warp
ftp client.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: Install Gentoo on remote server

[Grant]

>> OK you guys win.  Can anyone point me toward docs on the easiest way
>> to set up the connection?
>
> Start by installing app-crypt/easy-rsa.  Follow [1] as literally as it
> makes sense, changing just the names.  In particular, it really lowers
> the confusion if you follow the advice to keep files for each host in
> its own copy of the easy-rsa tree (or you can go all the way and
> actually install easy-rsa on each host, but I didn't).
>
> When you have the keys on each host, install net-vpn/openvpn and start
> following [2], again as closely as possible.  Skip the parts of [2] that
> explain how to generate the keys - you have already done that.
>
> I'll let someone else fill in the VM detail.
>
> [1]
> https://github.com/OpenVPN/easy-rsa/blob/master/README.quickstart.md
>
> [2]
> https://openvpn.net/index.php/open-source/documentation/howto.html


Thank you but I may have found a way to boot a CD after all:

http://knowledgelayer.softlayer.com/learning/what-media-data-transfer-service

- Grant

Re: [gentoo-user] Issues updating world on new install (gmp symptom)

[Jigme Datse Yli-RAsku]

On 2017-08-07 14:50, Alan McKinnon wrote:
> On 07/08/2017 23:47, Jigme Datse Rasku wrote:
> > I have been working with trying to get a new system installed, and the
> > first problem I run into is that it fails on the configure stage of gmp.
> >
>
> [snip]
>
> > # emerge -pqv '=dev-libs/gmp-6.1.2::gentoo'
> > [ebuild U ] dev-libs/gmp-6.1.2 [6.1.0] USE="asm cxx -doc -pgo
> > -static-libs" ABI_X86="(64) -32 (-x32*)"
>
> In the two attachments, the build log says it's a FLAGS/ABI error.
> Your env file has this:
> using ABI="64"
>   CC="x86_64-pc-linux-gnux32-gcc"
>   CFLAGS="-march=native -O2 -pipe"
>   CPPFLAGS=""
>   CXX="x86_64-pc-linux-gnux32-g++"
>   CXXFLAGS="-march=native -O2 -pipe"
>   MPN_PATH=" x86_64/k8 x86_64 generic"
>
> emerge output above says ABI_X86="x32" is switched OFF.
>
> You need to switch it on.
> ABI_X86 config is covered in detail at wiki.gentoo.org.
>
Thank you,

I could see that was possibly a problem, but it wasn't something which I 
intentionally changed, and trying to get what looked like the problem fixed, 
seems to have had no effect whatsoever.  I'll go look at the wiki see if it 
explains it better. 

Jigme Datse Yli-Rasku

-- 
Jigme Datse Yli-Rasku
jigme.da...@datsemultimedia.com (Preferred address for new messages)

Jigme Datse Yli-Rasku
PO Box 270
Rossland, BC V0G 1Y0
Canada

...
... This message should be electronically signed, and if the sender ...
... has your public key, may also be encrypted. ...
... If you have any questions about this, please email, or call. ...
...






signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Issues updating world on new install (gmp symptom)

[Alan McKinnon]

On 07/08/2017 23:47, Jigme Datse Rasku wrote:
> I have been working with trying to get a new system installed, and the
> first problem I run into is that it fails on the configure stage of gmp.
> 

[snip]

> # emerge -pqv '=dev-libs/gmp-6.1.2::gentoo'
> [ebuild U ] dev-libs/gmp-6.1.2 [6.1.0] USE="asm cxx -doc -pgo
> -static-libs" ABI_X86="(64) -32 (-x32*)"

In the two attachments, the build log says it's a FLAGS/ABI error.
Your env file has this:
using ABI="64"
  CC="x86_64-pc-linux-gnux32-gcc"
  CFLAGS="-march=native -O2 -pipe"
  CPPFLAGS=""
  CXX="x86_64-pc-linux-gnux32-g++"
  CXXFLAGS="-march=native -O2 -pipe"
  MPN_PATH=" x86_64/k8 x86_64 generic"

emerge output above says ABI_X86="x32" is switched OFF.

You need to switch it on.
ABI_X86 config is covered in detail at wiki.gentoo.org.

-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] Illegal State in Chroot Environment

[Neil Bothwick]

On Mon, 7 Aug 2017 13:29:03 -0400, P Levine wrote:

> > Currently I am rebuilding the whole system using `emerge -e world` and
> > everything is failing as early as the unpack phase.
> > Do I have to download stage from the beginning for the 3rd time!
> >  
> 
> The problem is it looks like you built and installed bzip2 with the
> incompatible CFLAGS.  Because this is used by portage to unpack tar.bz2
> files during the unpack phase, emerge can't really proceed.  Unless you
> have a binary package for bzip2 built with good CFLAGS lying around in
> you system, you should start again.

You might get away with copying bzip2 and libbz2.* from the stage 3 to
your filesystem, then re-emerge bzip2 with same flags.


-- 
Neil Bothwick

Plagarism prohibited. Derive carefully.


pgpY7rT74GUAS.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Illegal State in Chroot Environment

[P Levine]

On Mon, Aug 7, 2017 at 10:11 AM, symack  wrote:
>
> Currently I am rebuilding the whole system using `emerge -e world` and
> everything is failing as early as the unpack phase.
> Do I have to download stage from the beginning for the 3rd time!
>

The problem is it looks like you built and installed bzip2 with the
incompatible CFLAGS.  Because this is used by portage to unpack tar.bz2
files during the unpack phase, emerge can't really proceed.  Unless you
have a binary package for bzip2 built with good CFLAGS lying around in you
system, you should start again.

Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

[R0b0t1]

On Mon, Aug 7, 2017 at 10:41 AM,   wrote:
> Hi,
>
>
> On 08/06 07:04, R0b0t1 wrote:
>> 2) You can calibrate the oscillator using instructions in this
>> application note:
>> http://www.atmel.com/Images/Atmel-2555-Internal-RC-Oscillator-Calibration-for-tinyAVR-and-megaAVR-Devices_ApplicationNote_AVR053.pdf.
>> This process still might not get you close enough.
>
>   I have no oscilloscope nor a frequency counter.
>   That is above my financial possibilities...
>

I forgot to mention, one (or more) of the timers can be used as a
frequency counter (in multiple ways). My searching turned up a related
application note, you might want to look at the code associated with
http://www.atmel.com/Images/doc2563.pdf (application note AVR054) if
you want to get your ATtiny85s working.

Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

[R0b0t1]

On Mon, Aug 7, 2017 at 11:29 AM, Stefan Mark  wrote:
> On Mon, 7 Aug 2017 08:48:50 -0500
> R0b0t1  wrote:
>
>> On Mon, Aug 7, 2017 at 4:29 AM, Stefan Mark  wrote:
>> > On Sun, 6 Aug 2017 19:04:09 -0500
>> > R0b0t1  wrote:
>> >
>> >> On Sun, Aug 6, 2017 at 11:50 AM,   wrote:
>> >> > When I plug in such a little board into my PC, demesg
>> >> > reports:
>> >> > [ 1429.834140] usb 7-4: new low-speed USB device number 15 using
>> >> > ohci-pci [ 1429.965142] usb 7-4: device descriptor read/64, error
>> >> > -62 [ 1430.203151] usb 7-4: device descriptor read/64, error -62
>> >> > [ 1430.438161] usb 7-4: new low-speed USB device number 16 using
>> >> > ohci-pci [ 1430.569151] usb 7-4: device descriptor read/64, error
>> >> > -62 [ 1430.803174] usb 7-4: device descriptor read/64, error -62
>> >> > [ 1431.038184] usb 7-4: new low-speed USB device number 17 using
>> >> > ohci-pci [ 1431.456157] usb 7-4: device not accepting address 17,
>> >> > error -62 [ 1431.582204] usb 7-4: new low-speed USB device number
>> >> > 18 using ohci-pci [ 1432.000209] usb 7-4: device not accepting
>> >> > address 18, error -62 [ 1432.000244] usb usb7-port4: unable to
>> >> > enumerate USB device
>> >>
>> >> >
>> >> > My first thought was: The micronucleus bootloaed is missing or
>> >> > is defective...
>> >> >
>> >> > But plugging in the board into my Android tablet (the tablet runs
>> >> > Lollipop and is nothing special at all beside being rooted) via
>> >> > an OTG cable and using lsusb after that, it shows
>> >> > Bus 001 Device 003 ID 16d0:0753 MCS Digistump DigiSpark
>> >> >
>> >>
>> >> What the dmesg output is saying is that your USB hardware has
>> >> reported a communication error to the driver. It is my guess that
>> >> the ATtiny85 is not meeting the timing requirements for USB.
>> >>
>> >> Looking at the board there does not seem to be a crystal oscillator
>> >> which most people would consider necessary for doing USB
>> >> communication. This is an oversight on DigiStump's part and it is
>> >> very likely you will not be able to fix the communication issues.
>> >> You should contact them and tell them that your computer will not
>> >> recognize their device and that you suspect it is because the
>> >> clock is too inaccurate.
>> >>
>> >> >
>> >> > What can I do to make this Digispark being correctly recognized?
>> >> >
>> >> > Thank you VERY much for any help in advance!
>> >> >
>> >>
>> >> Three things:
>> >>
>> >> 1) Return the one you bought and get a new one. The ATtiny85's
>> >> internal oscillator might be at the end of the bell curve but
>> >> within manufacturer tolerance, which isn't enough to produce a USB
>> >> signal close enough to the specified frequency. Expect the seller
>> >> to pay for return shipping.
>> >>
>> >> 2) You can calibrate the oscillator using instructions in this
>> >> application note:
>> >> http://www.atmel.com/Images/Atmel-2555-Internal-RC-Oscillator-Calibration-for-tinyAVR-and-megaAVR-Devices_ApplicationNote_AVR053.pdf.
>> >> This process still might not get you close enough.
>> >>
>> >> 3) Add a crystal oscillator to the ATtiny85 and change its fuses to
>> >> use the oscillator. You will need to recompile the firmware if the
>> >> crystal is a different frequency from the internal oscillator.
>> >>
>> >> It might work on your phone and not your desktop because of
>> >> differences in the USB hardware (your phone's serial decoder in the
>> >> USB hardware performs clock recovery but your PC does not) or
>> >> because there are multiple things on a USB hub in your PC and the
>> >> ATtiny85 is less accurate than those already present devices.
>> >> Admittedly I'm surprised it gets most of the way to registering as
>> >> a device and then fails, but I don't think the problem is with the
>> >> drivers or your kernel.
>> > USB uses a variant of non-return-to-zero for clock synchronisation,
>> > that should™ take care of timing issues.
>> > Actually, using microcontrollers without crystal for soft-usb is
>> > fairly common (i have a bunch myself). As far as i understand (but
>> > im no expert), trouble usually arises more from the improvised
>> > level shifters than timing issues.
>> > Anyway, i neither think there is a driver problem, i had a fair bit
>> > of the messages myself, usually fixed by fixing the level shifter.
>>
>> An NRZ signal is part of the reason USB is so finicky. With USB the
>> clock has to be within some tolerance of the bus speed (the
>> justification being that there are multiple devices on the bus that
>> need to read the bus at all times) and this is fairly inflexible. With
>> other protocols, like most USART transceivers, the hardware can
>> recover the sender's frequency and compensate if it is wrong.
> As far as i had understand it, the idea of NRZ is to compensate minor
> drifts between the two clocks. If not that, what its then for?
> Strangely, i had often trouble with uart 

Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

[R0b0t1]

Hello,

Your posts are kind of hard to reply to, sorry if I miss something.
I'll try to get everything into this message.

On Mon, Aug 7, 2017 at 10:41 AM,   wrote:
> Hi,
>
>
> On 08/06 07:04, R0b0t1 wrote:
>> On Sun, Aug 6, 2017 at 11:50 AM,   wrote:
>> > When I plug in such a little board into my PC, demesg
>> > reports:
>> > [ 1429.834140] usb 7-4: new low-speed USB device number 15 using ohci-pci
>> > [ 1429.965142] usb 7-4: device descriptor read/64, error -62
>> > [ 1430.203151] usb 7-4: device descriptor read/64, error -62
>> > [ 1430.438161] usb 7-4: new low-speed USB device number 16 using ohci-pci
>> > [ 1430.569151] usb 7-4: device descriptor read/64, error -62
>> > [ 1430.803174] usb 7-4: device descriptor read/64, error -62
>> > [ 1431.038184] usb 7-4: new low-speed USB device number 17 using ohci-pci
>> > [ 1431.456157] usb 7-4: device not accepting address 17, error -62
>> > [ 1431.582204] usb 7-4: new low-speed USB device number 18 using ohci-pci
>> > [ 1432.000209] usb 7-4: device not accepting address 18, error -62
>> > [ 1432.000244] usb usb7-port4: unable to enumerate USB device
>> >
>>
>> >
>> > My first thought was: The micronucleus bootloaed is missing or
>> > is defective...
>> >
>> > But plugging in the board into my Android tablet (the tablet runs
>> > Lollipop and is nothing special at all beside being rooted) via
>> > an OTG cable and using lsusb after that, it shows
>> > Bus 001 Device 003 ID 16d0:0753 MCS Digistump DigiSpark
>> >
>>
>> What the dmesg output is saying is that your USB hardware has reported
>> a communication error to the driver. It is my guess that the ATtiny85
>> is not meeting the timing requirements for USB.
>
> The above is the only part of the dmesg log regarding this usb
> "device"...
>
> If I plug it into a usb-port, it "works"... (read: will be recognized
> according to dmesg, but still the udev rules dont get triggered, so
> I still get nothing under /dev/...
>

You should look more closely at the dmesg output, though admittedly
some of this might not be obvious without reading the USB
specification. The computer being unable to read a descriptor or the
device failing to accept an address are things that will prevent the
device from properly registering on the bus. The initial handshake
fails to complete.

>
>> Looking at the board there does not seem to be a crystal oscillator
>> which most people would consider necessary for doing USB
>> communication. This is an oversight on DigiStump's part and it is very
>> likely you will not be able to fix the communication issues. You
>> should contact them and tell them that your computer will not
>> recognize their device and that you suspect it is because the clock is
>> too inaccurate.
>
> ...the board is a thumbnail thing:
> http://digistump.com/products/1
>
> No crystal. It is not an original digistum and had cost me less than 1
> EUR...so not such a painful loss...
>
>
>> >
>> > What can I do to make this Digispark being correctly recognized?
>> >
>> > Thank you VERY much for any help in advance!
>> >
>>
>> Three things:
>>
>> 1) Return the one you bought and get a new one. The ATtiny85's
>> internal oscillator might be at the end of the bell curve but within
>> manufacturer tolerance, which isn't enough to produce a USB signal
>> close enough to the specified frequency. Expect the seller to pay for
>> return shipping.
>
>   Returning the board does cost more than the board and I haven't
>   any hope that this will change anything: I have six of them and none
>   works. "The design can be improved..." to be friendly.
>
>
>> 2) You can calibrate the oscillator using instructions in this
>> application note:
>> http://www.atmel.com/Images/Atmel-2555-Internal-RC-Oscillator-Calibration-for-tinyAVR-and-megaAVR-Devices_ApplicationNote_AVR053.pdf.
>> This process still might not get you close enough.
>
>   I have no oscilloscope nor a frequency counter.
>   That is above my financial possibilities...
>
>> 3) Add a crystal oscillator to the ATtiny85 and change its fuses to
>> use the oscillator. You will need to recompile the firmware if the
>> crystal is a different frequency from the internal oscillator.
>
>   There is not enough space on the board.
>

Well, if you can't do any of those and if the board doesn't have level
shifters that might be affecting the signal then you probably won't be
able to use the board. If you send the hardware developer a message
that the board has failed to work with a device you will be doing them
a favor.


On Mon, Aug 7, 2017 at 10:51 AM,   wrote:
> I ordered a similiar board yesterday, with a more reasonable setup:
> ATmega32u4 and a attached sdcard slot for the flash memory.
> The ATmega32u4 has a fully fledged USB 2.0 stack (is it called a "stack"?)
> and does not bitbang the whole stuff but "talks USB natively".
> I have gathered some hope so far, that this thingy will
> a) work with USB < 3.0
> b) is more stable and more 

Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

[Stefan Mark]

On Mon, 7 Aug 2017 08:48:50 -0500
R0b0t1  wrote:

> On Mon, Aug 7, 2017 at 4:29 AM, Stefan Mark  wrote:
> > On Sun, 6 Aug 2017 19:04:09 -0500
> > R0b0t1  wrote:
> >  
> >> On Sun, Aug 6, 2017 at 11:50 AM,   wrote:  
> >> > When I plug in such a little board into my PC, demesg
> >> > reports:
> >> > [ 1429.834140] usb 7-4: new low-speed USB device number 15 using
> >> > ohci-pci [ 1429.965142] usb 7-4: device descriptor read/64, error
> >> > -62 [ 1430.203151] usb 7-4: device descriptor read/64, error -62
> >> > [ 1430.438161] usb 7-4: new low-speed USB device number 16 using
> >> > ohci-pci [ 1430.569151] usb 7-4: device descriptor read/64, error
> >> > -62 [ 1430.803174] usb 7-4: device descriptor read/64, error -62
> >> > [ 1431.038184] usb 7-4: new low-speed USB device number 17 using
> >> > ohci-pci [ 1431.456157] usb 7-4: device not accepting address 17,
> >> > error -62 [ 1431.582204] usb 7-4: new low-speed USB device number
> >> > 18 using ohci-pci [ 1432.000209] usb 7-4: device not accepting
> >> > address 18, error -62 [ 1432.000244] usb usb7-port4: unable to
> >> > enumerate USB device  
> >>  
> >> >
> >> > My first thought was: The micronucleus bootloaed is missing or
> >> > is defective...
> >> >
> >> > But plugging in the board into my Android tablet (the tablet runs
> >> > Lollipop and is nothing special at all beside being rooted) via
> >> > an OTG cable and using lsusb after that, it shows
> >> > Bus 001 Device 003 ID 16d0:0753 MCS Digistump DigiSpark
> >> >  
> >>
> >> What the dmesg output is saying is that your USB hardware has
> >> reported a communication error to the driver. It is my guess that
> >> the ATtiny85 is not meeting the timing requirements for USB.
> >>
> >> Looking at the board there does not seem to be a crystal oscillator
> >> which most people would consider necessary for doing USB
> >> communication. This is an oversight on DigiStump's part and it is
> >> very likely you will not be able to fix the communication issues.
> >> You should contact them and tell them that your computer will not
> >> recognize their device and that you suspect it is because the
> >> clock is too inaccurate.
> >>  
> >> >
> >> > What can I do to make this Digispark being correctly recognized?
> >> >
> >> > Thank you VERY much for any help in advance!
> >> >  
> >>
> >> Three things:
> >>
> >> 1) Return the one you bought and get a new one. The ATtiny85's
> >> internal oscillator might be at the end of the bell curve but
> >> within manufacturer tolerance, which isn't enough to produce a USB
> >> signal close enough to the specified frequency. Expect the seller
> >> to pay for return shipping.
> >>
> >> 2) You can calibrate the oscillator using instructions in this
> >> application note:
> >> http://www.atmel.com/Images/Atmel-2555-Internal-RC-Oscillator-Calibration-for-tinyAVR-and-megaAVR-Devices_ApplicationNote_AVR053.pdf.
> >> This process still might not get you close enough.
> >>
> >> 3) Add a crystal oscillator to the ATtiny85 and change its fuses to
> >> use the oscillator. You will need to recompile the firmware if the
> >> crystal is a different frequency from the internal oscillator.
> >>
> >> It might work on your phone and not your desktop because of
> >> differences in the USB hardware (your phone's serial decoder in the
> >> USB hardware performs clock recovery but your PC does not) or
> >> because there are multiple things on a USB hub in your PC and the
> >> ATtiny85 is less accurate than those already present devices.
> >> Admittedly I'm surprised it gets most of the way to registering as
> >> a device and then fails, but I don't think the problem is with the
> >> drivers or your kernel.  
> > USB uses a variant of non-return-to-zero for clock synchronisation,
> > that should™ take care of timing issues.
> > Actually, using microcontrollers without crystal for soft-usb is
> > fairly common (i have a bunch myself). As far as i understand (but
> > im no expert), trouble usually arises more from the improvised
> > level shifters than timing issues.
> > Anyway, i neither think there is a driver problem, i had a fair bit
> > of the messages myself, usually fixed by fixing the level shifter.  
> 
> An NRZ signal is part of the reason USB is so finicky. With USB the
> clock has to be within some tolerance of the bus speed (the
> justification being that there are multiple devices on the bus that
> need to read the bus at all times) and this is fairly inflexible. With
> other protocols, like most USART transceivers, the hardware can
> recover the sender's frequency and compensate if it is wrong.
As far as i had understand it, the idea of NRZ is to compensate minor
drifts between the two clocks. If not that, what its then for?
Strangely, i had often trouble with uart when i dont used crystal. The
connection always failed after a while. Never had that with vusb.

> The level shifters might be causing timing 

Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

[Stefan Mark]

On Mon, 7 Aug 2017 17:44:31 +0200
tu...@posteo.de wrote:

> On 08/07 11:29, Stefan Mark wrote:
> > On Sun, 6 Aug 2017 19:04:09 -0500
> > R0b0t1  wrote:
> >   
> > > On Sun, Aug 6, 2017 at 11:50 AM,   wrote:  
> > > > When I plug in such a little board into my PC, demesg
> > > > reports:
> > > > [ 1429.834140] usb 7-4: new low-speed USB device number 15 using
> > > > ohci-pci [ 1429.965142] usb 7-4: device descriptor read/64,
> > > > error -62 [ 1430.203151] usb 7-4: device descriptor read/64,
> > > > error -62 [ 1430.438161] usb 7-4: new low-speed USB device
> > > > number 16 using ohci-pci [ 1430.569151] usb 7-4: device
> > > > descriptor read/64, error -62 [ 1430.803174] usb 7-4: device
> > > > descriptor read/64, error -62 [ 1431.038184] usb 7-4: new
> > > > low-speed USB device number 17 using ohci-pci [ 1431.456157]
> > > > usb 7-4: device not accepting address 17, error -62
> > > > [ 1431.582204] usb 7-4: new low-speed USB device number 18
> > > > using ohci-pci [ 1432.000209] usb 7-4: device not accepting
> > > > address 18, error -62 [ 1432.000244] usb usb7-port4: unable to
> > > > enumerate USB device   
> > >   
> > > >
> > > > My first thought was: The micronucleus bootloaed is missing or
> > > > is defective...
> > > >
> > > > But plugging in the board into my Android tablet (the tablet
> > > > runs Lollipop and is nothing special at all beside being
> > > > rooted) via an OTG cable and using lsusb after that, it shows
> > > > Bus 001 Device 003 ID 16d0:0753 MCS Digistump DigiSpark
> > > >
> > > 
> > > What the dmesg output is saying is that your USB hardware has
> > > reported a communication error to the driver. It is my guess that
> > > the ATtiny85 is not meeting the timing requirements for USB.
> > > 
> > > Looking at the board there does not seem to be a crystal
> > > oscillator which most people would consider necessary for doing
> > > USB communication. This is an oversight on DigiStump's part and
> > > it is very likely you will not be able to fix the communication
> > > issues. You should contact them and tell them that your computer
> > > will not recognize their device and that you suspect it is
> > > because the clock is too inaccurate.
> > >   
> > > >
> > > > What can I do to make this Digispark being correctly recognized?
> > > >
> > > > Thank you VERY much for any help in advance!
> > > >
> > > 
> > > Three things:
> > > 
> > > 1) Return the one you bought and get a new one. The ATtiny85's
> > > internal oscillator might be at the end of the bell curve but
> > > within manufacturer tolerance, which isn't enough to produce a
> > > USB signal close enough to the specified frequency. Expect the
> > > seller to pay for return shipping.
> > > 
> > > 2) You can calibrate the oscillator using instructions in this
> > > application note:
> > > http://www.atmel.com/Images/Atmel-2555-Internal-RC-Oscillator-Calibration-for-tinyAVR-and-megaAVR-Devices_ApplicationNote_AVR053.pdf.
> > > This process still might not get you close enough.
> > > 
> > > 3) Add a crystal oscillator to the ATtiny85 and change its fuses
> > > to use the oscillator. You will need to recompile the firmware if
> > > the crystal is a different frequency from the internal oscillator.
> > > 
> > > It might work on your phone and not your desktop because of
> > > differences in the USB hardware (your phone's serial decoder in
> > > the USB hardware performs clock recovery but your PC does not) or
> > > because there are multiple things on a USB hub in your PC and the
> > > ATtiny85 is less accurate than those already present devices.
> > > Admittedly I'm surprised it gets most of the way to registering
> > > as a device and then fails, but I don't think the problem is with
> > > the drivers or your kernel.  
> > USB uses a variant of non-return-to-zero for clock synchronisation,
> > that should™ take care of timing issues.
> > Actually, using microcontrollers without crystal for soft-usb is
> > fairly common (i have a bunch myself). As far as i understand (but
> > im no expert), trouble usually arises more from the improvised
> > level shifters than timing issues.
> > Anyway, i neither think there is a driver problem, i had a fair bit
> > of the messages myself, usually fixed by fixing the level shifter.  
> 
> 
> Level shifters? What level shifters??? ;)
Oh, i see. Then i have to correct me, it seems that your board runs on
3v3 anyway (Which means i did not know those, only ones that look much
alike). A level shifter wont be necessary then.


pgpDHhkuI2fdO.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

[Stefan Mark]

On Mon, 7 Aug 2017 17:53:35 +0200
tu...@posteo.de wrote:

> On 08/07 11:21, Stefan Mark wrote:
> > On Sun, 6 Aug 2017 18:50:07 +0200
> > tu...@posteo.de wrote:
> >   
> > > Hi,
> > > 
> > > sorry, this will become a little longish...
> > > 
> > > Background: To program an ATMEL ATtiny85 via USB
> > > without a dedicated USB chip there is a bootloader
> > > called "micornucleys", which bitbangs the USB protocoll.
> > > This mechanism is used in Digistupms Digispark ATTtiny
> > > developmnent board (http://digistump.com/products/1).
> > > 
> > > So far so nice?
> > > 
> > > When I plug in such a little board into my PC, demesg 
> > > reports:
> > > [ 1429.834140] usb 7-4: new low-speed USB device number 15 using
> > > ohci-pci [ 1429.965142] usb 7-4: device descriptor read/64, error
> > > -62 [ 1430.203151] usb 7-4: device descriptor read/64, error -62
> > > [ 1430.438161] usb 7-4: new low-speed USB device number 16 using
> > > ohci-pci [ 1430.569151] usb 7-4: device descriptor read/64, error
> > > -62 [ 1430.803174] usb 7-4: device descriptor read/64, error -62
> > > [ 1431.038184] usb 7-4: new low-speed USB device number 17 using
> > > ohci-pci [ 1431.456157] usb 7-4: device not accepting address 17,
> > > error -62 [ 1431.582204] usb 7-4: new low-speed USB device number
> > > 18 using ohci-pci [ 1432.000209] usb 7-4: device not accepting
> > > address 18, error -62 [ 1432.000244] usb usb7-port4: unable to
> > > enumerate USB device
> > > 
> > > or similiar. lsusb does not show anything related at all.
> > >   
> > That usually happens when the improvised USB is not good enough.
> > Try a different port, maybe put a USB Hub between. Check if the
> > resistors and diodes for the level shifting are the right ones
> > (measure the resistors, especially if you are not using 5% types).
> > If that does not work, try a different diode/resistor combination
> > (For example, usbasp uses 5v6 zener and 68/2k2 resistor, littlewire
> > 3v6 zener and 27/1k2 resistor. I have seen others too. I had at
> > least one which never worked with my laptop).  
> 
> The board is THAT tiny (http://digistump.com/products/1) that even
> a single proble will short circuit one half of the board... :)
Yeah, i know them. You need a smaller probe ;)
But i can understand that, i would not like to change parts on those.
Then better try other Ports :)


pgpEaF_puh301.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

[tuxic]

On 08/07 11:21, Stefan Mark wrote:
> On Sun, 6 Aug 2017 18:50:07 +0200
> tu...@posteo.de wrote:
> 
> > Hi,
> > 
> > sorry, this will become a little longish...
> > 
> > Background: To program an ATMEL ATtiny85 via USB
> > without a dedicated USB chip there is a bootloader
> > called "micornucleys", which bitbangs the USB protocoll.
> > This mechanism is used in Digistupms Digispark ATTtiny
> > developmnent board (http://digistump.com/products/1).
> > 
> > So far so nice?
> > 
> > When I plug in such a little board into my PC, demesg 
> > reports:
> > [ 1429.834140] usb 7-4: new low-speed USB device number 15 using
> > ohci-pci [ 1429.965142] usb 7-4: device descriptor read/64, error -62
> > [ 1430.203151] usb 7-4: device descriptor read/64, error -62
> > [ 1430.438161] usb 7-4: new low-speed USB device number 16 using
> > ohci-pci [ 1430.569151] usb 7-4: device descriptor read/64, error -62
> > [ 1430.803174] usb 7-4: device descriptor read/64, error -62
> > [ 1431.038184] usb 7-4: new low-speed USB device number 17 using
> > ohci-pci [ 1431.456157] usb 7-4: device not accepting address 17,
> > error -62 [ 1431.582204] usb 7-4: new low-speed USB device number 18
> > using ohci-pci [ 1432.000209] usb 7-4: device not accepting address
> > 18, error -62 [ 1432.000244] usb usb7-port4: unable to enumerate USB
> > device
> > 
> > or similiar. lsusb does not show anything related at all.
> > 
> That usually happens when the improvised USB is not good enough. Try a
> different port, maybe put a USB Hub between. Check if the resistors and
> diodes for the level shifting are the right ones (measure the
> resistors, especially if you are not using 5% types). If that does not
> work, try a different diode/resistor combination (For example, usbasp
> uses 5v6 zener and 68/2k2 resistor, littlewire 3v6 zener and 27/1k2
> resistor. I have seen others too. I had at least one which never
> worked with my laptop).

The board is THAT tiny (http://digistump.com/products/1) that even
a single proble will short circuit one half of the board... :)

> 
> > As recommended on related pages on the internet, I installed
> > dedicated udev rules to show the needed ttyACM device. But 
> > since the kernel itsself fails to accept the device, the best
> > udev rules will not work.
> > 
> > My first thought was: The micronucleus bootloaed is missing or
> > is defective...
> > 
> > But plugging in the board into my Android tablet (the tablet runs 
> > Lollipop and is nothing special at all beside being rooted) via
> > an OTG cable and using lsusb after that, it shows
> > Bus 001 Device 003 ID 16d0:0753 MCS Digistump DigiSpark
> Some ports are more forgiving than others. These soft-usb-thingies tend
> to be a bit rough, especially the level conversion seems to be a bit
> icky :)
> I have a usbasp which works always and everywhere i tested it just
> perfectly. One of my littlewires is a bit wonky (it sometimes looses
> connection and needs a few tries until it works again). Another one
> works fine, but not on every device.

Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

[tuxic]

On 08/07 08:48, R0b0t1 wrote:
> On Mon, Aug 7, 2017 at 4:29 AM, Stefan Mark  wrote:
> > On Sun, 6 Aug 2017 19:04:09 -0500
> > R0b0t1  wrote:
> >
> >> On Sun, Aug 6, 2017 at 11:50 AM,   wrote:
> >> > When I plug in such a little board into my PC, demesg
> >> > reports:
> >> > [ 1429.834140] usb 7-4: new low-speed USB device number 15 using
> >> > ohci-pci [ 1429.965142] usb 7-4: device descriptor read/64, error
> >> > -62 [ 1430.203151] usb 7-4: device descriptor read/64, error -62
> >> > [ 1430.438161] usb 7-4: new low-speed USB device number 16 using
> >> > ohci-pci [ 1430.569151] usb 7-4: device descriptor read/64, error
> >> > -62 [ 1430.803174] usb 7-4: device descriptor read/64, error -62
> >> > [ 1431.038184] usb 7-4: new low-speed USB device number 17 using
> >> > ohci-pci [ 1431.456157] usb 7-4: device not accepting address 17,
> >> > error -62 [ 1431.582204] usb 7-4: new low-speed USB device number
> >> > 18 using ohci-pci [ 1432.000209] usb 7-4: device not accepting
> >> > address 18, error -62 [ 1432.000244] usb usb7-port4: unable to
> >> > enumerate USB device
> >>
> >> >
> >> > My first thought was: The micronucleus bootloaed is missing or
> >> > is defective...
> >> >
> >> > But plugging in the board into my Android tablet (the tablet runs
> >> > Lollipop and is nothing special at all beside being rooted) via
> >> > an OTG cable and using lsusb after that, it shows
> >> > Bus 001 Device 003 ID 16d0:0753 MCS Digistump DigiSpark
> >> >
> >>
> >> What the dmesg output is saying is that your USB hardware has reported
> >> a communication error to the driver. It is my guess that the ATtiny85
> >> is not meeting the timing requirements for USB.
> >>
> >> Looking at the board there does not seem to be a crystal oscillator
> >> which most people would consider necessary for doing USB
> >> communication. This is an oversight on DigiStump's part and it is very
> >> likely you will not be able to fix the communication issues. You
> >> should contact them and tell them that your computer will not
> >> recognize their device and that you suspect it is because the clock is
> >> too inaccurate.
> >>
> >> >
> >> > What can I do to make this Digispark being correctly recognized?
> >> >
> >> > Thank you VERY much for any help in advance!
> >> >
> >>
> >> Three things:
> >>
> >> 1) Return the one you bought and get a new one. The ATtiny85's
> >> internal oscillator might be at the end of the bell curve but within
> >> manufacturer tolerance, which isn't enough to produce a USB signal
> >> close enough to the specified frequency. Expect the seller to pay for
> >> return shipping.
> >>
> >> 2) You can calibrate the oscillator using instructions in this
> >> application note:
> >> http://www.atmel.com/Images/Atmel-2555-Internal-RC-Oscillator-Calibration-for-tinyAVR-and-megaAVR-Devices_ApplicationNote_AVR053.pdf.
> >> This process still might not get you close enough.
> >>
> >> 3) Add a crystal oscillator to the ATtiny85 and change its fuses to
> >> use the oscillator. You will need to recompile the firmware if the
> >> crystal is a different frequency from the internal oscillator.
> >>
> >> It might work on your phone and not your desktop because of
> >> differences in the USB hardware (your phone's serial decoder in the
> >> USB hardware performs clock recovery but your PC does not) or because
> >> there are multiple things on a USB hub in your PC and the ATtiny85 is
> >> less accurate than those already present devices. Admittedly I'm
> >> surprised it gets most of the way to registering as a device and then
> >> fails, but I don't think the problem is with the drivers or your
> >> kernel.
> > USB uses a variant of non-return-to-zero for clock synchronisation,
> > that should™ take care of timing issues.
> > Actually, using microcontrollers without crystal for soft-usb is fairly
> > common (i have a bunch myself). As far as i understand (but im no
> > expert), trouble usually arises more from the improvised level shifters
> > than timing issues.
> > Anyway, i neither think there is a driver problem, i had a fair bit of
> > the messages myself, usually fixed by fixing the level shifter.
> 
> An NRZ signal is part of the reason USB is so finicky. With USB the
> clock has to be within some tolerance of the bus speed (the
> justification being that there are multiple devices on the bus that
> need to read the bus at all times) and this is fairly inflexible. With
> other protocols, like most USART transceivers, the hardware can
> recover the sender's frequency and compensate if it is wrong.
> 
> The level shifters might be causing timing problems, seeing as some
> hardware does recognize the ATtiny85 and the levels might be right. It
> seems less likely that a voltage difference would be OK between two
> pieces of hardware to me.
> 
> There's a lot of old advice related to microcontrollers that says you
> need to use crystals when you actually don't with modern 

Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

[tuxic]

On 08/07 11:29, Stefan Mark wrote:
> On Sun, 6 Aug 2017 19:04:09 -0500
> R0b0t1  wrote:
> 
> > On Sun, Aug 6, 2017 at 11:50 AM,   wrote:
> > > When I plug in such a little board into my PC, demesg
> > > reports:
> > > [ 1429.834140] usb 7-4: new low-speed USB device number 15 using
> > > ohci-pci [ 1429.965142] usb 7-4: device descriptor read/64, error
> > > -62 [ 1430.203151] usb 7-4: device descriptor read/64, error -62
> > > [ 1430.438161] usb 7-4: new low-speed USB device number 16 using
> > > ohci-pci [ 1430.569151] usb 7-4: device descriptor read/64, error
> > > -62 [ 1430.803174] usb 7-4: device descriptor read/64, error -62
> > > [ 1431.038184] usb 7-4: new low-speed USB device number 17 using
> > > ohci-pci [ 1431.456157] usb 7-4: device not accepting address 17,
> > > error -62 [ 1431.582204] usb 7-4: new low-speed USB device number
> > > 18 using ohci-pci [ 1432.000209] usb 7-4: device not accepting
> > > address 18, error -62 [ 1432.000244] usb usb7-port4: unable to
> > > enumerate USB device 
> > 
> > >
> > > My first thought was: The micronucleus bootloaed is missing or
> > > is defective...
> > >
> > > But plugging in the board into my Android tablet (the tablet runs
> > > Lollipop and is nothing special at all beside being rooted) via
> > > an OTG cable and using lsusb after that, it shows
> > > Bus 001 Device 003 ID 16d0:0753 MCS Digistump DigiSpark
> > >  
> > 
> > What the dmesg output is saying is that your USB hardware has reported
> > a communication error to the driver. It is my guess that the ATtiny85
> > is not meeting the timing requirements for USB.
> > 
> > Looking at the board there does not seem to be a crystal oscillator
> > which most people would consider necessary for doing USB
> > communication. This is an oversight on DigiStump's part and it is very
> > likely you will not be able to fix the communication issues. You
> > should contact them and tell them that your computer will not
> > recognize their device and that you suspect it is because the clock is
> > too inaccurate.
> > 
> > >
> > > What can I do to make this Digispark being correctly recognized?
> > >
> > > Thank you VERY much for any help in advance!
> > >  
> > 
> > Three things:
> > 
> > 1) Return the one you bought and get a new one. The ATtiny85's
> > internal oscillator might be at the end of the bell curve but within
> > manufacturer tolerance, which isn't enough to produce a USB signal
> > close enough to the specified frequency. Expect the seller to pay for
> > return shipping.
> > 
> > 2) You can calibrate the oscillator using instructions in this
> > application note:
> > http://www.atmel.com/Images/Atmel-2555-Internal-RC-Oscillator-Calibration-for-tinyAVR-and-megaAVR-Devices_ApplicationNote_AVR053.pdf.
> > This process still might not get you close enough.
> > 
> > 3) Add a crystal oscillator to the ATtiny85 and change its fuses to
> > use the oscillator. You will need to recompile the firmware if the
> > crystal is a different frequency from the internal oscillator.
> > 
> > It might work on your phone and not your desktop because of
> > differences in the USB hardware (your phone's serial decoder in the
> > USB hardware performs clock recovery but your PC does not) or because
> > there are multiple things on a USB hub in your PC and the ATtiny85 is
> > less accurate than those already present devices. Admittedly I'm
> > surprised it gets most of the way to registering as a device and then
> > fails, but I don't think the problem is with the drivers or your
> > kernel.
> USB uses a variant of non-return-to-zero for clock synchronisation,
> that should™ take care of timing issues.
> Actually, using microcontrollers without crystal for soft-usb is fairly
> common (i have a bunch myself). As far as i understand (but im no
> expert), trouble usually arises more from the improvised level shifters
> than timing issues.
> Anyway, i neither think there is a driver problem, i had a fair bit of
> the messages myself, usually fixed by fixing the level shifter.


Level shifters? What level shifters??? ;)
This board is THAT tiny...even the voltage regulator is bigger
than the MCU (http://digistump.com/products/1).

I am not that confident into my soldering-fu to rearrange 
anything on this board :)

Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

[tuxic]

Hi,


On 08/06 07:04, R0b0t1 wrote:
> On Sun, Aug 6, 2017 at 11:50 AM,   wrote:
> > When I plug in such a little board into my PC, demesg
> > reports:
> > [ 1429.834140] usb 7-4: new low-speed USB device number 15 using ohci-pci
> > [ 1429.965142] usb 7-4: device descriptor read/64, error -62
> > [ 1430.203151] usb 7-4: device descriptor read/64, error -62
> > [ 1430.438161] usb 7-4: new low-speed USB device number 16 using ohci-pci
> > [ 1430.569151] usb 7-4: device descriptor read/64, error -62
> > [ 1430.803174] usb 7-4: device descriptor read/64, error -62
> > [ 1431.038184] usb 7-4: new low-speed USB device number 17 using ohci-pci
> > [ 1431.456157] usb 7-4: device not accepting address 17, error -62
> > [ 1431.582204] usb 7-4: new low-speed USB device number 18 using ohci-pci
> > [ 1432.000209] usb 7-4: device not accepting address 18, error -62
> > [ 1432.000244] usb usb7-port4: unable to enumerate USB device
> >
> 
> >
> > My first thought was: The micronucleus bootloaed is missing or
> > is defective...
> >
> > But plugging in the board into my Android tablet (the tablet runs
> > Lollipop and is nothing special at all beside being rooted) via
> > an OTG cable and using lsusb after that, it shows
> > Bus 001 Device 003 ID 16d0:0753 MCS Digistump DigiSpark
> >
> 
> What the dmesg output is saying is that your USB hardware has reported
> a communication error to the driver. It is my guess that the ATtiny85
> is not meeting the timing requirements for USB.
 
The above is the only part of the dmesg log regarding this usb
"device"...

If I plug it into a usb-port, it "works"... (read: will be recognized
according to dmesg, but still the udev rules dont get triggered, so 
I still get nothing under /dev/...


> Looking at the board there does not seem to be a crystal oscillator
> which most people would consider necessary for doing USB
> communication. This is an oversight on DigiStump's part and it is very
> likely you will not be able to fix the communication issues. You
> should contact them and tell them that your computer will not
> recognize their device and that you suspect it is because the clock is
> too inaccurate.

...the board is a thumbnail thing:
http://digistump.com/products/1

No crystal. It is not an original digistum and had cost me less than 1
EUR...so not such a painful loss...


> >
> > What can I do to make this Digispark being correctly recognized?
> >
> > Thank you VERY much for any help in advance!
> >
> 
> Three things:
> 
> 1) Return the one you bought and get a new one. The ATtiny85's
> internal oscillator might be at the end of the bell curve but within
> manufacturer tolerance, which isn't enough to produce a USB signal
> close enough to the specified frequency. Expect the seller to pay for
> return shipping.

  Returning the board does cost more than the board and I haven't
  any hope that this will change anything: I have six of them and none
  works. "The design can be improved..." to be friendly.


> 2) You can calibrate the oscillator using instructions in this
> application note:
> http://www.atmel.com/Images/Atmel-2555-Internal-RC-Oscillator-Calibration-for-tinyAVR-and-megaAVR-Devices_ApplicationNote_AVR053.pdf.
> This process still might not get you close enough.

  I have no oscilloscope nor a frequency counter. 
  That is above my financial possibilities...

> 3) Add a crystal oscillator to the ATtiny85 and change its fuses to
> use the oscillator. You will need to recompile the firmware if the
> crystal is a different frequency from the internal oscillator.

  There is not enough space on the board.

> It might work on your phone and not your desktop because of
> differences in the USB hardware (your phone's serial decoder in the
> USB hardware performs clock recovery but your PC does not) or because
> there are multiple things on a USB hub in your PC and the ATtiny85 is
> less accurate than those already present devices. Admittedly I'm
> surprised it gets most of the way to registering as a device and then
> fails, but I don't think the problem is with the drivers or your
> kernel. It's also not very likely to be a problem with the USB code
> unless it was reimplemented for DigiStump's product (check against
> these libraries
> http://www.fourwalledcubicle.com/files/LUFA/Doc/120219/html/_page__alternative_stacks.html).
> 
> R0b0t1.
> 

Re: [gentoo-user] vsftpd anonymous upload illegal PORT command

[Mick]

On Monday 07 Aug 2017 02:24:57 Walter Dnes wrote:
> On Fri, Aug 04, 2017 at 02:23:08PM +0200, David Haller wrote
> 
> > Hello,
> > 
> > On Thu, 03 Aug 2017, Walter Dnes wrote:
> > >On Thu, Aug 03, 2017 at 04:09:15PM +0100, Mick wrote
> > >
> > >> On Thursday 03 Aug 2017 08:13:18 Walter Dnes wrote:
> > >> > anon_root=/home/ftp
> > >> 
> > >> Is this writeable?
> > >> 
> > >  If I do make it writeable, I get...
> > >
> > >500 OOPS: vsftpd: refusing to run with writable root inside chroot()
> > 
> > # mkdir /home/ftp/incoming
> > # chown ftp.ftp /home/ftp/incoming
> > # chmod 1777 /home/ftp/incoming
> > # chmod 555 /home/ftp
> 
>   I did the above (copy+paste; *WITHOUT* the "#", in case anyone asks).
> Here's what happens.  Question... why is it prompting me with "530 Please
> login with USER and PASS." *AFTER* I give username "anonymous".  BTW, if
> I try any username, other than anonymous, it dies with a message about
> being only an anonymous ftp server.
> 
> [i3][waltdnes][~/downloads] ftp -p 192.168.123.251
> Connected to 192.168.123.251 (192.168.123.251).
> 220 (vsFTPd 3.0.2)
> Name (192.168.123.251:waltdnes): anonymous
> 530 Please login with USER and PASS.
> SSL not available
> 331 Please specify the password.
> Password:
> 230 Login successful.
> Remote system type is UNIX.
> Using binary mode to transfer files.
> ftp> put install-x86-minimal-20170207.iso
> local: install-x86-minimal-20170207.iso remote:
> install-x86-minimal-20170207.iso 227 Entering Passive Mode
> (192,168,123,251,117,59).
> 553 Could not create file.
> ftp> bye
> 221 Goodbye.
> 
>   I did manage to get the video game transferred with tftp, after a bit
> of extra work.  I don't know if it's the old OS/2 Warp tftp client, or
> part of the protocol, but it can only transfer files up to 33553920
> bytes in size, i.e. 32 * 1024 * 1024 - 512 bytes.  32 megabytes looks
> like some sort of coded-in limit.  I had to do the transfer in pieces
> less than 32 megabytes.  I still want to get anonymous ftp working.


Sounds obvious, but did you try using a different client to connect to the ftp 
server anonymously and see what you get?
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Illegal State in Chroot Environment

[symack]

On Sun, Aug 6, 2017 at 11:58 PM, P Levine  wrote:

>
>
> On Sun, Aug 6, 2017 at 9:17 PM, symack  wrote:
>>
>> >>> Installing (4 of 199) app-arch/bzip2-1.0.6-r8::gentoo
>> bash: line 1: 26183 Illegal instruction 
>> ${PORTAGE_BUNZIP2_COMMAND:-${PORTAGE_BZIP2_COMMAND}
>> -d} -c -- /var/db/pkg/app-arch/bzip2-1.0.6-r8/environment.bz2 >
>> /var/tmp/portage/._unmerge_/app-arch/bzip2-1.0.6-r8/temp/environment
>> ​​
>>
> CFLAGS="-O2 -pipe -fomit-frame-pointer -mcx16 -msahf -maes
>> ​​
>> -mpclmul -mpopcnt -mabm -mlwp -mavx -march=native"
>>
>> ​One or more "-m" flags in CFLAGS isn't valid for the host processor​.
> Why have them in the first place if you've enabled -march=native?
>


Hello,

Thank you for your response. I have changed the CFLAGS to look like the
following:

CFLAGS="-O2 -pipe -fomit-frame-pointer -march=native"

Anything I do within chroot is returning `Illegal State` and made the
change from the livecd
environment.

Currently I am rebuilding the whole system using `emerge -e world` and
everything is failing as early as the unpack phase.
Do I have to download stage from the beginning for the 3rd time!

Any help to recover this instance is greatly appreciated.

Re: [gentoo-user] Gnutls / Google Chrome

[Mike Gilbert]

On Thu, Aug 3, 2017 at 3:56 PM, siefke_lis...@web.de
 wrote:
> Hello,
>
> I have updated gnutls v. 3.5.13 and after rebuild google-chrome want not
> started.
>
> Okay link check
>
> sisibox lib64 # ldd /opt/google/chrome/chrome | grep gnu
> libstdc++.so.6 => 
> /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/libstdc++.so.6 (0x7fd05e7db000)
> libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/libgcc_s.so.1 
> (0x7fd05e5c4000)
> libgnutls.so.28 => not found
>
> So Gnutls missed, I reinstall chrome and become same. I understand not
> why because on my package Server:
>
> (amd64) ks3374456 www-client # ldd /opt/google/chrome/chrome | grep gnu
> libstdc++.so.6 => 
> /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/libstdc++.so.6 (0x7f339c499000)
> libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/libgcc_s.so.1 
> (0x7f339c282000)
> libgnutls.so.30 => /usr/lib64/libgnutls.so.30 (0x7f3399ac9000)
>
> all work. I have deinstall and install, I have use "Source" and Binary
> Package. What can do now?

google-chrome does not depend on gnutls directly.

Use the lddtree utility from app-misc/pax-utils to determine what
library is pulling it in.

% lddtree /opt/google/chrome/chrome

Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

[R0b0t1]

On Mon, Aug 7, 2017 at 4:29 AM, Stefan Mark  wrote:
> On Sun, 6 Aug 2017 19:04:09 -0500
> R0b0t1  wrote:
>
>> On Sun, Aug 6, 2017 at 11:50 AM,   wrote:
>> > When I plug in such a little board into my PC, demesg
>> > reports:
>> > [ 1429.834140] usb 7-4: new low-speed USB device number 15 using
>> > ohci-pci [ 1429.965142] usb 7-4: device descriptor read/64, error
>> > -62 [ 1430.203151] usb 7-4: device descriptor read/64, error -62
>> > [ 1430.438161] usb 7-4: new low-speed USB device number 16 using
>> > ohci-pci [ 1430.569151] usb 7-4: device descriptor read/64, error
>> > -62 [ 1430.803174] usb 7-4: device descriptor read/64, error -62
>> > [ 1431.038184] usb 7-4: new low-speed USB device number 17 using
>> > ohci-pci [ 1431.456157] usb 7-4: device not accepting address 17,
>> > error -62 [ 1431.582204] usb 7-4: new low-speed USB device number
>> > 18 using ohci-pci [ 1432.000209] usb 7-4: device not accepting
>> > address 18, error -62 [ 1432.000244] usb usb7-port4: unable to
>> > enumerate USB device
>>
>> >
>> > My first thought was: The micronucleus bootloaed is missing or
>> > is defective...
>> >
>> > But plugging in the board into my Android tablet (the tablet runs
>> > Lollipop and is nothing special at all beside being rooted) via
>> > an OTG cable and using lsusb after that, it shows
>> > Bus 001 Device 003 ID 16d0:0753 MCS Digistump DigiSpark
>> >
>>
>> What the dmesg output is saying is that your USB hardware has reported
>> a communication error to the driver. It is my guess that the ATtiny85
>> is not meeting the timing requirements for USB.
>>
>> Looking at the board there does not seem to be a crystal oscillator
>> which most people would consider necessary for doing USB
>> communication. This is an oversight on DigiStump's part and it is very
>> likely you will not be able to fix the communication issues. You
>> should contact them and tell them that your computer will not
>> recognize their device and that you suspect it is because the clock is
>> too inaccurate.
>>
>> >
>> > What can I do to make this Digispark being correctly recognized?
>> >
>> > Thank you VERY much for any help in advance!
>> >
>>
>> Three things:
>>
>> 1) Return the one you bought and get a new one. The ATtiny85's
>> internal oscillator might be at the end of the bell curve but within
>> manufacturer tolerance, which isn't enough to produce a USB signal
>> close enough to the specified frequency. Expect the seller to pay for
>> return shipping.
>>
>> 2) You can calibrate the oscillator using instructions in this
>> application note:
>> http://www.atmel.com/Images/Atmel-2555-Internal-RC-Oscillator-Calibration-for-tinyAVR-and-megaAVR-Devices_ApplicationNote_AVR053.pdf.
>> This process still might not get you close enough.
>>
>> 3) Add a crystal oscillator to the ATtiny85 and change its fuses to
>> use the oscillator. You will need to recompile the firmware if the
>> crystal is a different frequency from the internal oscillator.
>>
>> It might work on your phone and not your desktop because of
>> differences in the USB hardware (your phone's serial decoder in the
>> USB hardware performs clock recovery but your PC does not) or because
>> there are multiple things on a USB hub in your PC and the ATtiny85 is
>> less accurate than those already present devices. Admittedly I'm
>> surprised it gets most of the way to registering as a device and then
>> fails, but I don't think the problem is with the drivers or your
>> kernel.
> USB uses a variant of non-return-to-zero for clock synchronisation,
> that should™ take care of timing issues.
> Actually, using microcontrollers without crystal for soft-usb is fairly
> common (i have a bunch myself). As far as i understand (but im no
> expert), trouble usually arises more from the improvised level shifters
> than timing issues.
> Anyway, i neither think there is a driver problem, i had a fair bit of
> the messages myself, usually fixed by fixing the level shifter.

An NRZ signal is part of the reason USB is so finicky. With USB the
clock has to be within some tolerance of the bus speed (the
justification being that there are multiple devices on the bus that
need to read the bus at all times) and this is fairly inflexible. With
other protocols, like most USART transceivers, the hardware can
recover the sender's frequency and compensate if it is wrong.

The level shifters might be causing timing problems, seeing as some
hardware does recognize the ATtiny85 and the levels might be right. It
seems less likely that a voltage difference would be OK between two
pieces of hardware to me.

There's a lot of old advice related to microcontrollers that says you
need to use crystals when you actually don't with modern parts, so I
think it reasonable that your advice will work. I hope Meino gets back
to us.

Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

[Stefan Mark]

On Sun, 6 Aug 2017 19:04:09 -0500
R0b0t1  wrote:

> On Sun, Aug 6, 2017 at 11:50 AM,   wrote:
> > When I plug in such a little board into my PC, demesg
> > reports:
> > [ 1429.834140] usb 7-4: new low-speed USB device number 15 using
> > ohci-pci [ 1429.965142] usb 7-4: device descriptor read/64, error
> > -62 [ 1430.203151] usb 7-4: device descriptor read/64, error -62
> > [ 1430.438161] usb 7-4: new low-speed USB device number 16 using
> > ohci-pci [ 1430.569151] usb 7-4: device descriptor read/64, error
> > -62 [ 1430.803174] usb 7-4: device descriptor read/64, error -62
> > [ 1431.038184] usb 7-4: new low-speed USB device number 17 using
> > ohci-pci [ 1431.456157] usb 7-4: device not accepting address 17,
> > error -62 [ 1431.582204] usb 7-4: new low-speed USB device number
> > 18 using ohci-pci [ 1432.000209] usb 7-4: device not accepting
> > address 18, error -62 [ 1432.000244] usb usb7-port4: unable to
> > enumerate USB device 
> 
> >
> > My first thought was: The micronucleus bootloaed is missing or
> > is defective...
> >
> > But plugging in the board into my Android tablet (the tablet runs
> > Lollipop and is nothing special at all beside being rooted) via
> > an OTG cable and using lsusb after that, it shows
> > Bus 001 Device 003 ID 16d0:0753 MCS Digistump DigiSpark
> >  
> 
> What the dmesg output is saying is that your USB hardware has reported
> a communication error to the driver. It is my guess that the ATtiny85
> is not meeting the timing requirements for USB.
> 
> Looking at the board there does not seem to be a crystal oscillator
> which most people would consider necessary for doing USB
> communication. This is an oversight on DigiStump's part and it is very
> likely you will not be able to fix the communication issues. You
> should contact them and tell them that your computer will not
> recognize their device and that you suspect it is because the clock is
> too inaccurate.
> 
> >
> > What can I do to make this Digispark being correctly recognized?
> >
> > Thank you VERY much for any help in advance!
> >  
> 
> Three things:
> 
> 1) Return the one you bought and get a new one. The ATtiny85's
> internal oscillator might be at the end of the bell curve but within
> manufacturer tolerance, which isn't enough to produce a USB signal
> close enough to the specified frequency. Expect the seller to pay for
> return shipping.
> 
> 2) You can calibrate the oscillator using instructions in this
> application note:
> http://www.atmel.com/Images/Atmel-2555-Internal-RC-Oscillator-Calibration-for-tinyAVR-and-megaAVR-Devices_ApplicationNote_AVR053.pdf.
> This process still might not get you close enough.
> 
> 3) Add a crystal oscillator to the ATtiny85 and change its fuses to
> use the oscillator. You will need to recompile the firmware if the
> crystal is a different frequency from the internal oscillator.
> 
> It might work on your phone and not your desktop because of
> differences in the USB hardware (your phone's serial decoder in the
> USB hardware performs clock recovery but your PC does not) or because
> there are multiple things on a USB hub in your PC and the ATtiny85 is
> less accurate than those already present devices. Admittedly I'm
> surprised it gets most of the way to registering as a device and then
> fails, but I don't think the problem is with the drivers or your
> kernel.
USB uses a variant of non-return-to-zero for clock synchronisation,
that should™ take care of timing issues.
Actually, using microcontrollers without crystal for soft-usb is fairly
common (i have a bunch myself). As far as i understand (but im no
expert), trouble usually arises more from the improvised level shifters
than timing issues.
Anyway, i neither think there is a driver problem, i had a fair bit of
the messages myself, usually fixed by fixing the level shifter.


pgpDVV8T7N82C.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

[Stefan Mark]

On Sun, 6 Aug 2017 18:50:07 +0200
tu...@posteo.de wrote:

> Hi,
> 
> sorry, this will become a little longish...
> 
> Background: To program an ATMEL ATtiny85 via USB
> without a dedicated USB chip there is a bootloader
> called "micornucleys", which bitbangs the USB protocoll.
> This mechanism is used in Digistupms Digispark ATTtiny
> developmnent board (http://digistump.com/products/1).
> 
> So far so nice?
> 
> When I plug in such a little board into my PC, demesg 
> reports:
> [ 1429.834140] usb 7-4: new low-speed USB device number 15 using
> ohci-pci [ 1429.965142] usb 7-4: device descriptor read/64, error -62
> [ 1430.203151] usb 7-4: device descriptor read/64, error -62
> [ 1430.438161] usb 7-4: new low-speed USB device number 16 using
> ohci-pci [ 1430.569151] usb 7-4: device descriptor read/64, error -62
> [ 1430.803174] usb 7-4: device descriptor read/64, error -62
> [ 1431.038184] usb 7-4: new low-speed USB device number 17 using
> ohci-pci [ 1431.456157] usb 7-4: device not accepting address 17,
> error -62 [ 1431.582204] usb 7-4: new low-speed USB device number 18
> using ohci-pci [ 1432.000209] usb 7-4: device not accepting address
> 18, error -62 [ 1432.000244] usb usb7-port4: unable to enumerate USB
> device
> 
> or similiar. lsusb does not show anything related at all.
> 
That usually happens when the improvised USB is not good enough. Try a
different port, maybe put a USB Hub between. Check if the resistors and
diodes for the level shifting are the right ones (measure the
resistors, especially if you are not using 5% types). If that does not
work, try a different diode/resistor combination (For example, usbasp
uses 5v6 zener and 68/2k2 resistor, littlewire 3v6 zener and 27/1k2
resistor. I have seen others too. I had at least one which never
worked with my laptop).

> As recommended on related pages on the internet, I installed
> dedicated udev rules to show the needed ttyACM device. But 
> since the kernel itsself fails to accept the device, the best
> udev rules will not work.
> 
> My first thought was: The micronucleus bootloaed is missing or
> is defective...
> 
> But plugging in the board into my Android tablet (the tablet runs 
> Lollipop and is nothing special at all beside being rooted) via
> an OTG cable and using lsusb after that, it shows
> Bus 001 Device 003 ID 16d0:0753 MCS Digistump DigiSpark
Some ports are more forgiving than others. These soft-usb-thingies tend
to be a bit rough, especially the level conversion seems to be a bit
icky :)
I have a usbasp which works always and everywhere i tested it just
perfectly. One of my littlewires is a bit wonky (it sometimes looses
connection and needs a few tries until it works again). Another one
works fine, but not on every device.


pgpN2HgJhMlGY.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] vsftpd anonymous upload illegal PORT command

[Walter Dnes]

On Fri, Aug 04, 2017 at 02:23:08PM +0200, David Haller wrote
> Hello,
> 
> On Thu, 03 Aug 2017, Walter Dnes wrote:
> >On Thu, Aug 03, 2017 at 04:09:15PM +0100, Mick wrote
> >> On Thursday 03 Aug 2017 08:13:18 Walter Dnes wrote:
> >
> >> > anon_root=/home/ftp
> >> 
> >> Is this writeable?
> >
> >  If I do make it writeable, I get...
> >
> >500 OOPS: vsftpd: refusing to run with writable root inside chroot()
> 
> # mkdir /home/ftp/incoming
> # chown ftp.ftp /home/ftp/incoming
> # chmod 1777 /home/ftp/incoming
> # chmod 555 /home/ftp

  I did the above (copy+paste; *WITHOUT* the "#", in case anyone asks).
Here's what happens.  Question... why is it prompting me with "530 Please
login with USER and PASS." *AFTER* I give username "anonymous".  BTW, if
I try any username, other than anonymous, it dies with a message about
being only an anonymous ftp server.

[i3][waltdnes][~/downloads] ftp -p 192.168.123.251
Connected to 192.168.123.251 (192.168.123.251).
220 (vsFTPd 3.0.2)
Name (192.168.123.251:waltdnes): anonymous
530 Please login with USER and PASS.
SSL not available
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> put install-x86-minimal-20170207.iso
local: install-x86-minimal-20170207.iso remote: install-x86-minimal-20170207.iso
227 Entering Passive Mode (192,168,123,251,117,59).
553 Could not create file.
ftp> bye
221 Goodbye.

  I did manage to get the video game transferred with tftp, after a bit
of extra work.  I don't know if it's the old OS/2 Warp tftp client, or
part of the protocol, but it can only transfer files up to 33553920
bytes in size, i.e. 32 * 1024 * 1024 - 512 bytes.  32 megabytes looks
like some sort of coded-in limit.  I had to do the transfer in pieces
less than 32 megabytes.  I still want to get anonymous ftp working.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications