The officially official Devuan Forum!

You are not logged in.

#1 Re: ARM Builds » Raspberry Pi 2 Model B does not boot » 2020-05-21 17:01:54

hello mmaglis,
this image is known to work with your Raspberry Pi version( RPI 2B )
http://arm-files.devuan.org/devuan_beow … 0.3.img.xz

user     :password

devuan:devuan
root      :toor


You just need to add a udev rule, so that the ethernet interface don't get named to a strange name..

cat - <<EOF >> /etc/udev/rules.d/70-persistent-net.rules 
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="yours_maccaddress", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
EOF

Substitute 'yours_maccaddress' with your macaddress..
You cave 3 forms to get it..
boot with that image, attache a display, and a keyboard, and do a ifconfig
or
boot with another image and do a 'ifconfig', and its there,
Or
Use a usb-serial cable attached to the ttyAMA0 uart, and power up the pi and see what comes in the uart smile

#2 Re: Devuan Derivatives » [NEW]-FluXuan Linux-[RELEASE] » 2020-05-21 02:20:10

Hello,
It seems the nice fit for a arm desktop version,
In the meantime,
Downloading for my i686 machine smile

Congratz & thanks for this amazing work!

#3 Re: ARM Builds » [ ARMHF ] build for Olimex OlinuXino Lime2 » 2020-05-20 04:33:56

The '/etc/update-motd.d/20-monitor', for OLime2
This piece of the puzzle was still missing smile
Yeah UPS working..
Discharging:
monitor.png
Charging:
monitor1.png
Full:
monitor2.png
Battery Disconnected:
monitor3.png

#4 Re: ARM Builds » Is any work planned for devuan on the raspberry pi 4? » 2020-05-19 04:16:05

pAul wrote:

wanted to test your image, however the upload is corrupt, and is only 107B

Hello pAul,
You forgot about the intructions for download smile

(Remove .sha at the end for the actual image. Home server, so be kind...)

You need to copy the link, paste it and remove '.sha' from the name, before continue to download.. smile
or get it here( I removed the '.sha' )

That image is by MetaYan, you can also find him in the irc chanel #devuan-arm

Best Regards,
tux

#5 Re: ARM Builds » Devuan and Raspberry Pi 3B+ hardware » 2020-05-17 06:28:11

Hello,
modules can be loaded in: /etc/modules

then you can pass some information for a module via sysfs in /etc/rc.local or other place, if you find appropriate in a daemon.. smile
well they are just creating a layer above another layer of complexity, and then mixing in another mammoth atop( systemd )

And they thing its the greatest thing in the universe..
its that and flying Unicorns big_smile

#6 Re: ARM Builds » Devuan v9 for ARMv7 AllWinner - generic Libre kernel v5.3.1 » 2020-05-17 06:18:48

bimon wrote:

Can anyone please suggest a good small and light boot loader to choose a kernel like GRUB on X86?

You can use extlinux, its small, and you only need its config in place:
/boot/extlinux/extlinux.conf

Uboot will pick him

#7 Re: ARM Builds » [ ARM64 ] build, for Pine64 RockPro64 » 2020-05-12 19:26:58

PWM is configurable with values [ 250 - 255 ].
250 - Fan Off.
255 - Fan at maximum power..

The Fan behavior, suggests( after several tests...), that we have 5 levels of power.. 25{1,2,3,4,5}.

'echo 251 > /sys/class/hwmon/hwmon2/pwm1' - activates Fan in the lower power applied, if you have a not so efficient Cooling system,
The value 251, maybe not sufficient, and so maybe you need to try levels above( 252-255 ).

#8 Re: ARM Builds » RPi3A+/3B/3B+/(4B) » 2020-05-06 02:42:29

Hello Camtaf,
Take a look at this image here:
https://dev1galaxy.org/viewtopic.php?id=3209&p=3

see the last 2 posts, and test it on raspberrypi 4 smile

#9 ARM Builds » [ ARM64 ] build, for Pine64 RockPro64 » 2020-05-05 17:27:08

tuxd3v
Replies: 1

Hello All,
This is a preliminary build, for RockPro64
v0.2beta Server build.


Features & Versions:

1) - Arm Trusted Firmware  - v2.3 ( built for arm64 )
     U-boot boot-loader         - v2020.04 ( built for arm64 )
2) - Linux Kernel                  - Stable 5.6.10 ( built for arm64 )
3) - UserSpace                    - Devuan Beowulf ( for arm64 )
4) - ChangeLog                  - update kernel,correct ethernet, hdmi, initial bringup of sound via hdmi
5) - Problems & to be done - After coming to Beowulf, its impossible to auto-mount zramfs as swap, automatically, sound via 3.5mm Jack still not possible usig codec HIFI ES8316...


1) BootLoader( ATF + u-boot )

Disk Partitioning scheme:

# parted /dev/mmcblk1
(...)                                                         
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      64s      8063s     8000s                  idbloader
 2      16384s   24575s    8192s                  uboot
 3      24576s   32767s    8192s                  none
 4      32768s   262143s   229376s   ext2         boot       boot, esp
 5      262144s  3743744s  3481601s  ext4         rootfs

a)   - Bootloader( Arm Trusted Firmware + U-Boot ), starting at sector 64( 1st partition.. ), and ending at sector 32767( 3rd partition.. )
  a1) - The Bootloader will search for a file called 'boot.scr'( in 4th partition ), and after initialize the u-boot environment, will execute that script..
  a2) - In  'boot.scr', for this image, it will point to 'RockPro64 v2.1' Device Tree Binary File by default( was tested there.. )..
  a3) - If you have "RockPro64 v2", please Read Bellow in the 'Notes Section'..   
b)  - 4th Partition( after BootLoader ) is mounted as  '/boot'
c)  - 5ft Partition is mounted as rootfs '/'

NOTA!
The Bootloader in a) usually takes ~1MiB..
Each time a bootloader is built, all area [ 64s - 32767s ], needs to be clean first( so that you can flash the new bootloader.. because could still be there any bits of the previous one.. which could lead to unpredictable consequences.. ).

If you have Other Board than "RockPro64 v2.1'''( RockPro64 v2' ), situation described in a3):
The 'boot.cmd' script( format, Human Readable ):

setenv macaddr da 19 c8 7a 6d f4

#setenv devtype mmc
#setenv devnum 1

#part uuid ${devtype} ${devnum}:1 idbloaderuuid
#part uuid ${devtype} ${devnum}:2 ubootuuid
#part uuid ${devtype} ${devnum}:3 noneuuid
#part uuid ${devtype} ${devnum}:4 bootuuid
#part uuid ${devtype} ${devnum}:5 rootfsuuid

setenv bootargs "earlyprintk debug=on earlycon=uart8250,mmio32,0xff1a0000  console=tty1 console=ttyS2,1500000n8 root=/dev/mmcblk1p5 rw rootfstype=ext4 fsck.repair=yes net.ifnames=0 video=eDP-1:1680x1050@60 video=HDMI-1:1680x1050@60 bootsplash.bootfile=dev1-arm16.png"
# ubootpart=${bootuuid}
setenv fdtfile rockchip/rk3399-rockpro64.dtb

if load ${devtype} ${devnum}:4 ${kernel_addr_r} vmlinuz; then
  if load ${devtype} ${devnum}:5 ${fdt_addr_r} usr/lib/linux-image-5.6.10/${fdtfile}; then
    fdt addr ${fdt_addr_r}
    fdt resize 65536
    fdt set /ethernet@fe300000 local-mac-address "[${macaddr}]"
    booti ${kernel_addr_r} - ${fdt_addr_r};
  fi;
fi

Write this Image, to a sd-card, then mount it, and change the 'boot.cmd' script to point to your board..
# You can find a list of supported boards in: '/usr/lib/linux-image-5.6.10/rockchip'
# Edit the file 'boot.cmd', with 'vi' for example.
# change the line:
'setenv fdtfile rockchip/rk3399-rockpro64.dtb'
to
'setenv fdtfile rockchip/rk3399-rockpro64-v2.dtb'

Save the file,
# Generate the real script file( binary ), 'boot.scr'

mkimage -C none -A arm64 -T script -d boot.cmd boot.scr

2) - Linux Kernel

Packages:

There are 3 packages installed( in the future will be at least Userspace Panfrost mesa-3d graphics drivers more.. for a desktop version..):

~# dpkg -l |grep -E "(linux-.*(headers|image|libc-dev))"
ii  linux-headers-5.6.10       5.6.10-7                           arm64        Linux kernel headers for 5.6.10 on arm64
ii  linux-image-5.6.10         5.6.10-7                           arm64        Linux kernel, version 5.6.10
ii  linux-libc-dev:arm64       5.6.10-7                           arm64        Linux support headers for userspace development

The target will be to reach, ideally, full usability of all characteristics..


3) - UserSpace -Users & Passwords:

1) root      - password 'toor'
2) devuan - password 'devuan'

NOTA!
SSH is enabled, so that you can login, but root login, is disabled, you should login as 'devuan', only then switch to 'root', if you want to.. for that,
After Login as 'devuan', issue:

sudo su -

And type your 'devuan' password, that's it..


4) - Changelog

a) - Kernel update to 5.6.10,
b) - Ethernet working ok
c) - HDMI is working ok, but still needs to be enabled sooner in the boot process..
d) - Panfrost kernel Driver
e) - DVFS - Dynamic Voltage Frequency Scalling working ok
f) - { IR, RTC, SPDIF } Kernel Driver test Handlers, including decoders for RAW IR( NEC, RC5(x/sz), RC6, JVC, Sony. SANYO, Sharp, MCE Keyboard/mouse, XMP )
g) - Its now possible to boot, without assigning '/dev/urandom' to crng( but there are still a warning message in the boot process... ).
h) - reboot now works OK.
i) - Fan PWM works, but always at 255( max power.. )
j) - Sound via HIFI ES8316, to 3.5mm Jack still not possible( Codec added )..
k) - Sound via HDMI, works OK!!
l) - USB Ports work, but still a warning message about usb-otg..


5) - Problems and testings to be done..

a) - After migration to beowulf, its impossible, for now, to automount zramfs as swap, automatically.. you need to issue

swapon -a

it could be related with several packages, including those(  most probably): init init-system-helpers initscripts insserv eudev mawk sed( this problem doesn't occurr in the RPi1 Image..armel )

b) - Testing is needed, on camera interfaces
c) - testing is needed in LVDS panels
d) - Test IR driver shipped, tests needed
e) - Compile UserSpace Mesa Panfrost Driver stack( userspace counterpart for kernel space one.. )
f) - Try to tune Fan PWM( if possible will be added ATS to control fan ), Right npw,
     the most pratical solution would be to add;
    echo 251 > /sys/class/hwmon/hwmon2/pwm1 to /etc/rc.local
g) - solve Sound via HIFI ES8316..
h) - improve Sound Quality via HDMI.. Solved!!
i) - investigate usb-otg warning
j) - other minor warnings..

For this image, to reach more Supported Hardware and Users, your help is also needed smile
Testing devuan-beowulf-rockpro64-arm64-0.2.img, and posting your feedback.

SHA256sum:

4$ sha256sum devuan-beowulf-rockpro64-arm64-0.2.img.tar.xz 
ab0f9547de0d92f1516a2bbde944606043ce88a30aa098a72734782b12dbd9a3  devuan-beowulf-rockpro64-arm64-0.2.img.tar.xz

Best Regards,
tux

#10 Re: ARM Builds » ascii installer-ARM64 question » 2020-05-03 04:57:34

You welcome,
The important thing is that you managed to take some conclusions from it, and see the limitations you have on your config.. smile

I also tested a lot, but with the power supply I have.. no way( I need to find another way.. ), I have rpi1, which I believe is more limited than rpi3..
The hard-drives disks, don't spin.. sad


An example case:
I have a NAS( 3 Seagate Ironworlf disks ),
After startup, power consumption goes around 22-25Watts( normal operation ),
But when disks start spinning at beginning... I see in my PowerMeter spikes of around ~60Watts.. which is more than 2x the power consumption in operation..
Yes they are brief, but they are there..
Then around 40watts, after that they start consuming ~20-25watts( normal operation )..

My NAS disks are 3.5"( with 2.5"  disks numbers are off-course a lot lower accordingly.. ), but it gives me the notion of power needed to start a drive vs normal utilization( after spinning up the plates )..



The USB 2.0 Specification says that is can deliver "5 units of 100mA each", so by the Specification we are talking about 500mA Max( I believe its per port.. ).
One thing are Specifications, other thing is the real hardware around which is made to be cheap, so it can be competitive..
chargers,power regulators, usb hubs, circuitry limitation designs, Lots of factors..

Yeah,
I would say that, if it has a Global limitation of 600mA,
The best option would be to find a hard drive that is very very low power( which nowadays will be each time more difficult to find.. ).

If you find a very low power harddrive, that works well on this devices,
Please let us know smile

#11 Re: ARM Builds » ascii installer-ARM64 question » 2020-05-02 23:17:19

You welcome,
yeah it seems to be compiled in the kernel.. smile

unfortunatly you couldn't check '/proc/config.gz' because its not present.. sad

your HD disk is 2.5"?
insert it with both USB ports(including) the power supply, and do a dmesg, to check if its controller is detected.

check with: 'sg_scan -i' and 'sg_map -sd', probably it will appears as '/dev/sg0' and would be mapped to '/dev/sda'
check also with 'lsblk'

It could be the same problem I have( in my case I suspect of power supply because my board is badly powered.. that's why I also tested with a pendrive.. )

You have I think 4x usb2.0,
If you had at least a real usb3.0( since it can negotiate more power deliver ), but then again, if power supply for the base board is not enough, having usb3.0 will not help because the power will end delivered in all by the power supply first..

My USB Harddrive adapter controller is detected,
But not enough power for him and also to power the disk sad

In your config you have 2 things:
1) a USB<->Sata adapter
2) a Harddrive

both consume power, the harddrive should consume more, and so maybe you get the USB<->Sata adapter, detected, but not the disk sad

This is what hapens in my case:

[34772.896837] usb 1-1.2: Manufacturer: ASMedia
[34772.901150] usb 1-1.2: SerialNumber: 00000000000000000000
[34772.919034] usb-storage 1-1.2:1.0: USB Mass Storage device detected
[34772.932325] scsi host0: usb-storage 1-1.2:1.0
[34773.955039] scsi 0:0:0:0: Direct-Access     ASMT     2105             0    PQ: 0 ANSI: 5
[34773.975426] sd 0:0:0:0: [sda] Attached SCSI removable disk
[34773.984745] sd 0:0:0:0: Attached scsi generic sg0 type 0
[34793.627510] usb 1-1.2: USB disconnect, device number 7
[34803.653748] usb 1-1.2: new high-speed USB device number 8 using dwc2
[34804.107548] usb 1-1.2: New USB device found, idVendor=174c, idProduct=5106, bcdDevice= 0.01
[34804.116038] usb 1-1.2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[34804.123406] usb 1-1.2: Product: AS2105
[34804.127295] usb 1-1.2: Manufacturer: ASMedia
[34804.131600] usb 1-1.2: SerialNumber: 00000000000000000000
[34804.147473] usb-storage 1-1.2:1.0: USB Mass Storage device detected
[34804.163076] scsi host0: usb-storage 1-1.2:1.0
[34805.235612] scsi 0:0:0:0: Direct-Access     ASMT     2105             0    PQ: 0 ANSI: 5
[34805.256014] sd 0:0:0:0: [sda] Attached SCSI removable disk
[34805.265445] sd 0:0:0:0: Attached scsi generic sg0 type 0

In my case it has only power to conect to the USB<->Sata controller, but not to provide the suficient power to the disk controllers and mottors to spin the disks.. so dmesg ends like that..
Regards,

#12 Re: ARM Builds » ascii installer-ARM64 question » 2020-05-02 22:11:02

hello Altoid,

It could be..
But I would experiment in the rpi3 with a flash pen drive, just in case, to check if it works..

Anyway,
You can sort that out, maybe( if the config is present in the kernel.. )..

zgrep -Ei "_USB_STORAGE|_BLK_DEV_SD" /proc/config.gz

1) If its not present then its what we were expecting..
You will need that module..

2) If everything seems ok to you,
With is been available, compiled not as a module[ =y ]
then I advice to test with a usb pendrive

Check if it was compiled in the kernel smile

#13 Re: ARM Builds » ascii installer-ARM64 question » 2020-05-02 18:14:20

hello,
You can test it with a usb pen drive, and Eliminate the power consumption variable of the hard drive smile

I, for instance, with this Image on rpi1, and a pendrive inserted, have this on dmesg output:

root@stealth:~# dmesg|grep -Ei "usb-storage|scsi|sd" --color
[    0.116884] SCSI subsystem initialized
[    1.614692] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
[    1.669305] Loading iSCSI transport class v2.0-870.
[    1.670782] usbcore: registered new interface driver usb-storage
[    1.674223] sdhci: Secure Digital Host Controller Interface driver
[    1.674248] sdhci: Copyright(c) Pierre Ossman
[    1.775904] sdhost-bcm2835 20202000.mmc: loaded - DMA enabled (>1)
[    1.776342] sdhci-pltfm: SDHCI platform and OF driver helper
[    2.079053] mmc0: new high speed SDHC card at address 59b4
[    9.642520] usb-storage 1-1.2:1.0: USB Mass Storage device detected
[    9.662141] scsi host0: usb-storage 1-1.2:1.0
[   10.733319] scsi 0:0:0:0: Direct-Access     ASMT     2105             0    PQ: 0 ANSI: 5
[   10.760260] sd 0:0:0:0: [sda] Attached SCSI removable disk
[   10.854416] sd 0:0:0:0: Attached scsi generic sg0 type 0
[11946.453478] usb-storage 1-1.2:1.0: USB Mass Storage device detected
[11946.469115] scsi host0: usb-storage 1-1.2:1.0
[11947.535614] scsi 0:0:0:0: Direct-Access     Generic  Flash Disk       8.07 PQ: 0 ANSI: 4
[11947.551405] sd 0:0:0:0: [sda] 15769600 512-byte logical blocks: (8.07 GB/7.52 GiB)
[11947.563219] sd 0:0:0:0: Attached scsi generic sg0 type 0
[11947.575380] sd 0:0:0:0: [sda] Write Protect is off
[11947.580253] sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00
[11947.588448] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[11947.623158]  sda: sda1 sda2
[11947.637772] sd 0:0:0:0: [sda] Attached SCSI removable disk
root@stealth:~# dmesg|grep -Ei "usb-storage|scsi| sd " --color
[    0.116884] SCSI subsystem initialized
[    1.614692] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
[    1.669305] Loading iSCSI transport class v2.0-870.
[    1.670782] usbcore: registered new interface driver usb-storage
[    9.642520] usb-storage 1-1.2:1.0: USB Mass Storage device detected
[    9.662141] scsi host0: usb-storage 1-1.2:1.0
[   10.733319] scsi 0:0:0:0: Direct-Access     ASMT     2105             0    PQ: 0 ANSI: 5
[   10.760260] sd 0:0:0:0: [sda] Attached SCSI removable disk
[   10.854416] sd 0:0:0:0: Attached scsi generic sg0 type 0
[11946.453478] usb-storage 1-1.2:1.0: USB Mass Storage device detected
[11946.469115] scsi host0: usb-storage 1-1.2:1.0
[11947.535614] scsi 0:0:0:0: Direct-Access     Generic  Flash Disk       8.07 PQ: 0 ANSI: 4
[11947.551405] sd 0:0:0:0: [sda] 15769600 512-byte logical blocks: (8.07 GB/7.52 GiB)
[11947.563219] sd 0:0:0:0: Attached scsi generic sg0 type 0
[11947.575380] sd 0:0:0:0: [sda] Write Protect is off
[11947.580253] sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00
[11947.588448] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[11947.637772] sd 0:0:0:0: [sda] Attached SCSI removable disk

But I also doesn't have the usb-storage module,
Because it was built in[ =Y ]( not compiled has a module.. ).

And it works..

Now, when I attach a 2.5" disk, I see it as a /dev/sg0,
and I can run

# sg_map -sd
/dev/sg0  /dev/sda

also 'sg_scan -i',
But it doesn't appear as a block device, only the controller is detected, I suspect of a power supply problem..

#14 Re: ARM Builds » Installer images for armel, armhf and ppc64 need testing » 2020-05-02 17:41:55

garyz.dev1 wrote:

thank you, @tuxd3v - I now have network access and also terminal login

you welcome,
nice you succeded smile

garyz.dev1 wrote:

'
okay - took the beowulff image http://arm-files.devuan.org/devuan_beow … 0.3.img.xz
****
this file does not exist, but I created it
/etc/udev/rules.d/70-persistent-net.rules
.    put in the mac address per your guidance
****
added this to my /etc/inittab
T0:2345:respawn:/sbin/agetty -L ttyAMA0 115200 dumb
****
changed my /etc/network/interfaces to just use 'eth0' dhcp
.  dropping the predictable naming

yeah the udev rule is not shipped by default,
Because its very difficult to create a udev rule for all boards..
Each one is using a different mac-address and the static udev rule would fail.. sad

yup with eth0,
Now everything should work ok( even firewall( iptables ) will work now ).. smile

garyz.dev1 wrote:

.notice they rename eth0 to a 'predictable network interface names'  WHO IS THEY???
*****

It was an attempt to generate a always persistent name between reboots, to machines that have several Ethernet Ports..
But in RaspberryPi is gets ugly,
And doesn't make sense, since we only have one Ethernet port, it will always be 'eth0', no need for generating names.. smile

Also, the automatic persistent names generation,
Breaks compatibility with lots of software( you were experiencing that.. )

Almost everyone out there is experiencing problems with that, at some point..


Regards,

#15 Re: ARM Builds » ascii installer-ARM64 question » 2020-05-02 06:07:51

hello Altoid,
when you insert the drives in the usb, powered with the 5v, everything ok, what you get with 'dmesg' ?

it could be that the module was not compiled for it..
if you do:
modinfo usb-storage

what is the output?

you can also do:
find /lib/modules -name \*usb-storage\*.ko to check..


This si a config for sub-storage, on kernel 5.4.x:
[

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
CONFIG_USB_STORAGE_REALTEK=m
CONFIG_REALTEK_AUTOPM=y
CONFIG_USB_STORAGE_DATAFAB=m
CONFIG_USB_STORAGE_FREECOM=m
CONFIG_USB_STORAGE_ISD200=m
CONFIG_USB_STORAGE_USBAT=m
CONFIG_USB_STORAGE_SDDR09=m
CONFIG_USB_STORAGE_SDDR55=m
CONFIG_USB_STORAGE_JUMPSHOT=m
CONFIG_USB_STORAGE_ALAUDA=m
CONFIG_USB_STORAGE_ONETOUCH=m
CONFIG_USB_STORAGE_KARMA=m
CONFIG_USB_STORAGE_CYPRESS_ATACB=m
CONFIG_USB_STORAGE_ENE_UB6250=m
CONFIG_USB_UAS=m

you need also the SCSI sg driver..
I see it there but not been used..

regards,

#16 Re: ARM Builds » Installer images for armel, armhf and ppc64 need testing » 2020-05-02 05:34:16

garyz.dev1 wrote:

@tux3dv
I have the debug output from the pi2B, but not an active terminal - some confusion as to how/what to call it

notice they rename eth0 to a 'predictable network interface names'

Predictable?
that name is everything but not predictable( 'enxb827eb14085f' ).. big_smile
your madaddress is: b8:27:eb:14:08:5f

Remember to change it in the heredocument.. like this:

cat - <<EOF > /etc/udev/rules.d/70-persistent-net.rules 
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="b8:27:eb:14:08:5f", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
EOF

After this you should get the network name correctly( 'eth0' ),
reboot the system and check..

Also to get a login prompt via serial, you need in the '/etc/inittab' something like:
T0:23:respawn:/sbin/agetty -L ttyAMA0 115200 vt100

restart the system and check if you get a login tty via serial..

garyz.dev1 wrote:

'
stock /etc/network/interfaces  (partial)
allow hotplug eth0
iface eth0 inet dhcp
allow hotplug enxb827eb14085f
iface enxb827eb14085f inet dhcp
------
ifconfig -a
shows the enxb827eb14085f  device but no IP address
     as the lo iface shows "inet 127.etc...."

ps. will do some more seach to turn on the debug port as a serial device
maybe I can get some dmesg  data that way

you can bringup the ethernet with that "marvelous" name, with:
ifdown enxb827eb14085f && ifup enxb827eb14085f
but that should not be needed, after the udev rule in place..

After renaming the Ethernet to a sane name,  you should only maintain in '/etc/network/interfaces' ,
(...)
allow hotplug eth0
iface eth0 inet dhcp

you need a login tty in the inittab, for serial login
its above the line you need smile

#17 Re: ARM Builds » Is any work planned for devuan on the raspberry pi 4? » 2020-05-01 15:16:00

yan wrote:

I've managed to build an image using beowulf and kernel 4.19, which gives:

I hope someone with a rpi4 tests your build smile

#18 Re: ARM Builds » Installer images for armel, armhf and ppc64 need testing » 2020-05-01 04:13:54

garyz.dev1 wrote:

the one at the top of the page,

Issue is network configuration -- can't get DHCP address,
my attempts at Static IP failed also
'
not sure what network manager they use.
nmcli is not part of the Synaptic packages

it would be configured to work with dhcp I guess.
it could be the strange naming of the network..

do a 'ifconfig', and post the result..
A 'dmesg' would also be great smile

it could be that you need to rename the interface, try with this:

cat - <<EOF >> /etc/udev/rules.d/70-persistent-net.rules 
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="yours_maccaddress", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
EOF
garyz.dev1 wrote:

also tried this one - network seems [iirc] to be an issue  http://arm-files.devuan.org/devuan_beow … 0.3.img.xz

You have a rpi2B right?
this image is known to work well with rpi1..
It would be interesting to get a 'dmesg'  output from this image, running in your board,
Also a 'cat /proc/cpuinfo'

You can access it via serial right?

#19 Re: ARM Builds » [Solved] Devuan Raspbian images » 2020-04-30 18:51:23

Altoid wrote:

Hello:

I'm currently waiting for delivery of a Raspberry Pi 3B+ to use with my coffee roasting setup.
In the meanwhile (lots of it) I'm reading up on what's going on with Raspberry/Raspbian and I came across this page on the official Raspberry Pi web site.

What called my attention, knowing there are Devuan Raspbian images available, was that their availability was not listed on the page under the Third Party Operating System Images section along with Ubuntu and others.

Is there a sound reason for that or is it because of the systemd thing? (spelt it right this time ...)

Thanks in advance,

A.

Hello Altoid,
Raspbian images is a thing from RaspberryPi Foundation..

Devuan has Devuan Images..
You can find rpi3 arm64 images for devuan for example  here ..

Also you can find a arm64 Image for RPi4 by MetaYan here( scroll to the last post by yan ) smile

#20 Re: ARM Builds » ascii installer-ARM64 question » 2020-04-30 18:44:56

Altoid wrote:

Hello:
Yes.
That is how it is done if you want to install Devuan/Raspbian.

And there are Raspbian image files available in the downloads section at Dev1.

There are there arm64 devuan images for rpi3 smile

Like this one

#21 Re: ARM Builds » Installer images for armel, armhf and ppc64 need testing » 2020-04-30 18:35:05

garyz.dev1 wrote:

Yeee Haaaaw !  big_smile
armel works on my rPi2B , right from the git-go

Hello garyz.dev1,
What armel image does you tested? smile

#22 Re: ARM Builds » Raspberry Pi Zero W - Wireless Networking » 2020-04-12 17:39:59

arilogue wrote:

Sorry but i couldn't try suggestions of you and fm81 because i was too busy and still i am.
I think in a few days i will try them.
Thanks for now : )

No problem arilogue
you welcome..

When you can smile

#23 Re: ARM Builds » Raspberry Pi 2 Model B does not boot » 2020-04-12 17:37:34

the usb-serial adapter is conected to usb port, and then to the GPIO uart pins:
for instance take a look at the rpi GPIO:
https://www.raspberrypi.org/documentation/usage/gpio/

Ground - GPIO 6
Tx         - GPIO 8
RX        - GPTI 10

then use for example picocom to connect to the uart:
apt-get install picocom

#picocom /dev/your_tty_device -b 115200

And only then apply power to the board.. and see wat is comming in the uart, its the best tool for debug smile

remember:
Tx means board TX( which means it needs to be conected to usb-serial RX )
Rx means board RX( which means it needs to be conected to usb-serial TX )

in the meantime you can try the image I proposed smile
and say something about it smile

Best Regards,
tux

#24 Re: ARM Builds » Raspberry Pi 2 Model B does not boot » 2020-04-11 13:43:44

hello mmaglis,
Does you have a usb-serial cable to do some debug on that Image?

Does you experimented the image here: http://arm-files.devuan.org/

#25 Re: ARM Builds » Raspberry Pi Zero W - Wireless Networking » 2020-04-10 03:20:40

hello arilogue,
Does you solved your problem?

The driver for what I could see, times out sad
brcmfmac lines of dmesg ..

Does you experimented with other image?

best regards,

Board footer

Forum Software