Jump to content
  • 0

Orange PI Win+ - apt upgrade issue


t-bob
 Share

Question

Hi,

 

I was just wondering if anyone else out there with a Win+ has this issue .... when I install from an image file all works well, WIFI etc all good. But when I upgrade the install wlan0 etc has gone. ifconfig doesnt show it, lsmod shows the brcmfmac/cfg80211

 

I've tried it with a few of the recent image files

 

systemctl status systemd-modules-load
        systemd-modules-load[1693]: Failed to find module 'lp'
        systemd-modules-load[1693]: Failed to find module 'ppdev'
        systemd-modules-load[1693]: Failed to find module 'parport_pc'

 

root@zoot: lsmod
Module                  Size  Used by
ipt_MASQUERADE         16384  1
nf_nat_masquerade_ipv4    16384  1 ipt_MASQUERADE
iptable_nat            16384  1
nf_conntrack_ipv4      16384  2
nf_defrag_ipv4         16384  1 nf_conntrack_ipv4
nf_nat_ipv4            16384  1 iptable_nat
nf_nat                 28672  2 nf_nat_masquerade_ipv4,nf_nat_ipv4
nf_conntrack          118784  5 nf_conntrack_ipv4,ipt_MASQUERADE,nf_nat_masquerade_ipv4,nf_nat_ipv4,nf_nat
libcrc32c              16384  2 nf_conntrack,nf_nat
brcmfmac              212992  0
brcmutil               16384  1 brcmfmac
cfg80211              266240  1 brcmfmac
rfkill                 28672  2 cfg80211
root@zoot:~# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 02:ba:0e:f7:30:ef  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

eth0:avahi Link encap:Ethernet  HWaddr 02:ba:0e:f7:30:ef  
          inet addr:169.254.10.39  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1423 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1423 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:116295 (116.2 KB)  TX bytes:116295 (116.2 KB)

 

Link to comment
Share on other sites

13 answers to this question

Recommended Posts

  • 0

You want to use those images? Don't. If you are experimenting, if you are using it for no purpose, than it's o.k. You just found one of many bugs, which are in automated built experimental images. The bug might be new, might be already solved in the mean time or some workaround exists - today's or tomorrow update might fix this or it might take more time. Those images comes as is. 

Hint for future: if you find some experimental image working, go to armbian-config and "freeze kernel and BSP upgrades" and your system won't receive kernel upgrades when doing "apt upgrade" until you unfreeze it again.

Link to comment
Share on other sites

Check forum guidelines to use maximum potential!

  • 0

Igor, yes i understand that they are very beta but I wasnt sure if it was a me issue or one that effected everyone. So far I have experienced only small issues which is really nice. armbian is pretty dang good !!!

 

I have found several other issues/'features' ... do i post them here or is there somewhere else to log them ?

 

I wouldnt mind having having the hamradio stuff setup in the kernel as a default ... with whom do i speak with about that ?

 

sshd no longer accepts ssh-dss keys
        echo "PubkeyAcceptedKeyTypes=+ssh-dss" >> /etc/ssh/sshd_config; /etc/init.d/sshd restart
iptables not installed by default

 

Link to comment
Share on other sites

  • 0
8 hours ago, t-bob said:

 

Igor, yes i understand that they are very beta but I wasnt sure if it was a me issue or one that effected everyone. So far I have experienced only small issues which is really nice. armbian is pretty dang good !!!

 

I have found several other issues/'features' ... do i post them here or is there somewhere else to log them ?

 

I wouldnt mind having having the hamradio stuff setup in the kernel as a default ... with whom do i speak with about that ?

 


Thank you :)

I used to operate in hamradio field back in the old days, but I have no idea about current needs in kernel. If you provide a list of options (open a new issue at Github), we can include them in no time. Like this one. The same goes for other options you might miss in the kernel.

Link to comment
Share on other sites

  • 0

I was an rpm distro guy but armbian has pushed me to really like debian based systems.

 

It's a new thing I'm playing with so hopefully that plus all the radio programs already compiled will make life easier. Some of the morse->text and morse->text are very nice.

 

Where do i log the other issues ?

Link to comment
Share on other sites

  • 0

I tried the armbian-config "hold kernel updates" but the upgrade issue still occurred. if i do:

apt-mark hold linux-u-boot-orangepiwin-dev linux-xenial-root-dev-orangepiwin linux-dtb-dev-sun50iw2 linux-headers-dev-sun50iw2 linux-image-dev-sun50iw2 armbian-firmware
 

then it's OK so i expect the issue  is in armbian-firmware

Link to comment
Share on other sites

  • 0
10 hours ago, t-bob said:

then it's OK so i expect the issue  is in armbian-firmware

Nightly / WIP / preview / development firmware (must) have bugs, otherwise we would call it "stable" :) We provide those builds with purpose of bug hunting and since people expect that they should work (before job is done), we will stop providing them. We waste a lot of time explaining, that it's normal that things breaks, than fixing an actual problem. I made quick check, but can't find where is the problem.

 

Last time I was testing this feature, it worked as expected - from armbian-config, which does this: https://github.com/armbian/config/blob/dev/debian-config#L601-L615 when issuing "freeze kernel".

Link to comment
Share on other sites

  • 0

the only fix is to re-image the system and start again.

 

do the apt-mark command above and then you should be able to upgrade without zapping your Win once you've re-imaged

 

i was wondering if there is or has been proposed having a status page for boards that are beta (attached to both the main board page & the download page) ? users would then know which bits didnt work and wouldnt need to raise the issue here avoiding developer user fatigue ....

 

something like:

   wifi - working since 1/6/2017

   usb - working since 1/4/2017

   bluetooth - NOT working. No ETA. Developer assigned

   hdmi - Not working. No ETA. See https://linux-sunxi.org/blahblah for more information

   gpio - not working. no eta. no developer assigned

   12c - not working. no eta. no developer assigned

 

and so on for the major parts that interest devs/users ....

 

and yes i understand this would be additional work but i think it would be worth it in the long run

 

you could even do sumthing similar with a bug/issue tracking system like bugzilla/RT/MantisBT/Redmine/Trac ... create the tickets and then as developers update them users would know more & the boards 'owner' could update the status page.

Link to comment
Share on other sites

  • 0
6 hours ago, t-bob said:

something like:

   wifi - working since 1/6/2017

   usb - working since 1/4/2017

   bluetooth - NOT working. No ETA. Developer assigned

   hdmi - Not working. No ETA. See https://linux-sunxi.org/blahblah for more information

   gpio - not working. no eta. no developer assigned

   12c - not working. no eta. no developer assigned


This job is for anyone with minimal inside knowledge. Related or unrelated to Armbian.

 

Again - "no support" means we will not provide any information regarding state and problems of moving experimental things. It's expensive and provide negative results. Double negative from our perspective.

 

When things are good enough for bare server usage, similar kind of report is found at download page - this and that is not working, ... Currently there are too much problems and no one out of five active developers would like to have yet another burden. We don't want that experimental images are used by end users in first place. Some even use those unfinished work in production and are saying that we are losers and idiots, because upgrade break their wonderfully working system. Yes it happens. It happens way to often and there is no compensation. They don't support as in any way but expect full support from us.

 

We came to conclusion that we will not share any information (for end users) regarding WIP work. Developers can find and acquire information from Github commits, from ours an upstream. Everything relevant is written there, but to write a summary ... anyone can.

Link to comment
Share on other sites

  • 0

The gpio/i2c were just there as examples not as the truth :)

 

OK, let me think further on this and i'll see if i can come up with something that may be usable .. then put it up for comment. I would like to help but I'm not really a kernel coder ... sysadmin/dba/integrator yes ....

 

I know that one of the 'problems' is that users keep asking the same question over & over ... in general terms is it more about the status of X or 'this doesnt work' ?

 

Again, not trying to be annoying but trying to find out where I can help. Do you have any suggestions as to where I could help to make your lives easier ?

 

Yes, I have several users here I'd pay to be sent to a CIA re-education camp ;) Perhaps we can get a bulk booking discount :)

 

With users downloading WIP images, if when they click on the link to get the image could you put a dialog window that says something like "This is an unstable image and should not be used for anything other than testing. Somethings may work or not blah blah blah. Press 'I understand the risks' " ? I've found you really have to get in their faces with stuff as they dont read the page, they just want the image to run on their board.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...