ARM6 version - random MAC on Raspberry Pi 1B

Hi again!

I took the ARM6 LXQT image with upstream kernel from here

and booted 2 raspi 1b’s, both are getting on EACH boot new, random MAC addresses assigned to eth0, which is a nightmare in a network with static ARP and reserved IP’s based on MAC.

Any hint where to stop this? :wink:

Many thanks in advance!

PS: This LLADDR-thingy in /etc/sysconfig/network/ifcfg-eth0 described here doesn’t help!-fixing-the-MAC-Address …is simply ignored on boot.

The first Google hit:

Yeah, but that’S Debian/Raspian, I want suse! Have to correct me, tried a second time and now the LLADDR fix is doing fine. Work arround was to fix the IP, didn’t like that, however…

Interesting issue.
I can see why this has to happen by default so that more than one RPi on the network launching from the same image will be guaranteed a unique MAC address.

I would think there should be a way to disable the behavior, though… Maybe the code should have been made “run once”

In any case, after inspecting the referenced raspbian thread,
It looks to me that the last post in the thread which describes editing /etc/network/interfaces should work.


Hmmm, on Raspian the MAC is persistent with the hardware (!).

I can simply copy (dd, win32diskimager) an installation of Raspian to a new SD-card, boot and have copy of the fully configured system, however, the MAC is strictly bound to the hardware I use, so I get my reserved IPs (based on MAC) no matter which SD-cad I’m booting…

Copying SD-cards is quite comfortable if you use identical configs on let’s say, 4-5 raspis. And MAC is inside the hardware, normally.

Could be raspbian has long been fixed… after all, the referenced forum thread is 3 years old.

I don’t know the procedure for how the openSUSE RPi kernels are built… They’re “community supported” and the current TW kernel (4.1.x) is pretty far behind the current raspbian (4.4.x), it’s pretty hard to identify what is upstream and downstream in both branches. The TW kernel should still be pretty good, though…


eehm, I have a raspi 1b here greeting with

Welcome to openSUSE 20160621 "Tumbleweed" - Kernel 4.6.2-1-default (ttyAMA0).

A raspi 2b on TW, however, states


Quite stable! I built a NAS with software RAID1 with that. Quite nice!

And the latest TW for raspi 3 (arm8 aarch64) states on boot , but I can’t make this one to recognize any monitor correctly on boot and VNC is too unstable to run it headless…


Have no idea where this “community” is, developing these releases. GIThub?

Wow, that’s great!
And, I just looked at the ARM repos a couple days ago…


Hi again!

Yesterday I downloaded


and booted a Raspi 2b with that, this pretty annoying random MAC is back and this time the LLADDR hack referenced above does not help. Does anybody have a clue how to set a fixed (best: HARDWARE-based MAC) on Tumbleweed for Raspberry?

This is really not funny anymore…

  • Downstream kernels booted through GRUB might get a random MAC address.
    Workaround: edit GRUB menu entry or create a boot.scr script.

Why do I get the feeling nobody really wants to help and this ARM opensuse is freak-only?

…today on aarch64 TW from here:

1003 updates. Afterwards the install is *******ed up with the same random-MAC nonsense! I can’t believe it!

And on reddit they caaaaaannnnn’t believe that someone tested their raspi stuff and only found non-functional garbage. OMG.>:(

…although there is absolutely nothing comparable to this here

in the NetworkManager config, the hardware-MAC is back after switching to Wicked and reboot. Now I have no icon in the taskbar for the connection. :frowning:

Musing a bit…
Before I get a chance to do some testing (Maybe someone else can test this before I can get to it)

Setting LLADRESS is normally done by editing the interface file (This sets a persistent configuration) but might also be done as a sysconfig command (This would reload rather than persist).

However people might be trying to set the MAC address, the other method could be tried…
Also, if Network Manager is used, oftentimes setting by either of the above methods over-rides whatever might be in NM.


Nope, not phunny at all. This is the ifcfg-eth0 file on the machine


Doesn’t change anything, though…