All Activity

bananaoi-m5, Armbian 25.8.1 bookworm installed I can login via ssh as first user, gene, and sudo -i just fine. Buuuttttttt, at reboot the local screen ask's for the pw for amandabackup, a user lock down tightly which has never had a pw assigned. as its intended to be pw--less for the amanda backup system. What miss-configure can cause this????? Also I ordered 2 more of the keyboard/mouse combo''s which are the same as I'm using with a similar install for klipper running a 3d printer, but the dongle doesn't init when plugged in ack dmesg output, refusing its on discovery assigned address. So no keyboard/mouse is locally possible. I'll unpack the 2nd identical copy and see if its also broken. Switching back to an ultra- micro sized keyboard with a touchpad mouse works fine. And the second keyboard/mouse works as expected. The pw gizmo ask's for amandabackup's pw, I gave it my first user pw which it accepted logging me in normally. So I typed whoami and it responded gene. So wth is confusing the login requester????????? Many Thanks for any assistance. And why do I have to say solved in order to post when its not solved?? Counter productive to other readers.

What a PR is ? Could you be more specific about your suggestion ?

That is basically what I have been doing. I reconstructed image/partitions to have bootfs and rootfs separated. Typically format bootfs as simple FAT where you can fix things even on Windows computers maybe when SD-cards. For new fast SBCs I just have many partitions on NVMe where various Linux distros rootfs are and just copy or rename armbianEnv.txt which is then essentially only a UUID of a rootfs. When I know the SBC well enough, it is more the kernel only that matters, so i made a extlinux.conf generator so I can select a kernel via U-Boot serial console. I don't see what A+B brings me as I use Btrfs for rootfs and use snapper to make 'last-known-good' snapshots and also transfer those to NAS or so. If you want totally unattended, then A+B is an option, look at Android as well I would say. But more towards PC like systems, one can put efi bootloader (efi-grub) on the bootFAT, that allows you to select last-known-good more or less if you deploy snapshots. I usually do update in-place, so more like rolling release, but you can also do updates on a new read-write snapshot and fallback if it would fail to boot, see https://kubic.opensuse.org/documentation/man-pages/transactional-update.8.html for example how that works. U-Boot also has options I think to get to last-known-good automatically, but I don't know how that would work. For my stuff at home, it is good enough that I can quickly go back to older snapshot and that works for more than a decade on my PCs, so I do the same on SBCs/embedded, as long as they have a serial console cable (or HDMI,keyboard). For the NanoPi-NEO I also had Btrfs capable U-Boot, so then U-Boot can directly boot a certain rootfs partition, but it is not really default, so I keep an extra bootFAT.

Fresh Orangepi 5 image, this one: https://netcup-01.armbian.com/incoming/efectn/orangepi5/archive/Armbian_25.8.1_Orangepi5_noble_vendor_6.1.115_gnome_desktop.img.xz Your setup could be broken to some degree, but hard to tell what is missing.

Getting into buildroot and yocto seems a bit too much for me to get an A+B style update possibility. I would like to stick with the quality images provided by Armbian. The following applies to a NanoPi-NEO3 others SBC might have different partition layouts. From what I understood is that uboot looks for /boot in /dev/mmcblk0p1 reads the boot.cmd/scr and armbianEnv.txt and then boots the kernel accordingly. The armbianEnv.txt seems to point the kernel to the root partition using the rootdev directive. If /dev/mmcblk0p1 would now only hold /boot would it be possible to point to a different partition for the rootfs using armbianEnv.txt? If so I could imagine changing the partition layout to the following: /dev/mmcblk0: /dev/mmcblk0p1: boot partition /dev/mmcblk0p2: rootfs partitionA /dev/mmcblk0p3: rootfs partitionB /dev/mmcblk0pX: multiple more partitions that survive updates Too now allow consistency with the rootfs partitions also the boot partition directory structure would slightly change. It would contain 2 directories: /bootA, /bootB AND a hardlink /boot which either points to /bootA or /bootB In the running rootfs the fitting /boot is mounted via a bind mount hoping normal apt-get updates can deal with this. This would allow creating a rootfs by updating and verifying everything works locally and then creating an image from it. Now to OTA a relatively simple script running from rootfsA can download a new rootfs image/file structure and place it in the partition of rootfsB. Same with the new boot partition just into /bootB. The values of the armbianEnv.txt from the new boot image always point to the corresponding rootfs partition either because the image was already built for this or the script dynamically adjusts them. Same goes for fstab, machine-id, ssh identity and other rootfs specifics. The script will then verify that the write worked to avoid sd card issues. The (almost) atomic operation for switching the systems would be changing the hardlink of /boot to the /bootB directory and reboot. This idea will not detect any boot issues and revert automatically back as uboot is not involved. Also this only works if uboot is still compatible with the new boot files provided. But an additional new uboot image could also be provided during the update. Reverting can be done manually (relatively fast) by changing the hardlink back and rewriting a previously created backup copy of a might be updated uboot image. Independent of the fact that buildroot, yocto, rauc, mender… systems have a better feature set, do you think this could work?

Today armbian-config doesn't show other kernels, it's impossible to switch. * Show only mainstream kernels on the list? => no * No other kernels available! => ok

Yes, I did read that. I was also thinking maybe the decompression on-the-fly could be a point of failure. Just now, I installed USBImager and wrote the image to a uSD. No presets applied (.not_looged_in_yet) First boot went smoothly. I updated with armbian-upgrade and rebooted and all looked OK. 🤷🏻‍♂️ Since I changed 2 things (using USBImager and no presets) I can't say what helped.

You need an overlay for that camera and 6.1.115-vendor-rk35xx does not have that AFAIR, older legacy 5.10 has it AFAIR. Look for something called RPi camera v1 or that sensor name.

It would be interesting to compare corrupt and non corrupt cards, including partition tables, etc. Windows might be playing bad with partition tables - if one only inserts ESXi boot disk into windows machine, such disk becomes non bootable. AFAIR this is because ESXi relies on records order in the gpt table of the disk, while windows strips away blank records so that if eg second and third records are blank then windows will move the fourth record to the second place, while ESXi relies on the fourth record in a table. I personally met this issue a few years ago and it took a while to find the solution of reordering gpt table records back to restore ESXi boot.

Why not do a PR and add the needed modules to the EDGE config?

Moved ? where ?

I do agree, that it doesn't. But it looks like Armbian kernel is built with arm-linux-gnueabihf-gcc Taken unalignment problem the same flag was used with which the kernel and headers were built. It doesn't help either.

armbian-config : System > Storage > "STO001 - Install" or directly nand-sata-install You will get │ │ 1 Boot from SD - system on SATA, USB or NVMe │ │ │ │ 2 Boot from eMMC - system on eMMC │ │ │ │ 3 Boot from eMMC - system on SATA, USB or NVMe │ │ │ │ 4 Boot from MTD Flash - system on SATA, USB or NVMe │ │ │ │ 5 Install/Update the bootloader on SD card (/dev/mmcblk1) │ │ if you select boot from eMMC I think the installer will replace RoobiOS u-boot (and I guess Roobi Boot Menu) with Armbian U-Boot. I still need to experiment with Roobi OS (i.e. if there is a bootloader in SPI flash like on PC instead of only on eMMC). But you might want to try "boot from SD - system on NVME" and keep the Armbian bootloader on SD with the SD card kept plugged. If you install the bootloader on the eMMC likely you won't get the Roobi Boot menu anymore. About the boot priority, I guess it is written in the Radxa doc. It depends on how they configured their U-Boot.

Ok, that draft was way more complicated than it should and there's an easier way, also we need to logout and login again for the extension to show. Is it a problem if we restart GNOME shell during install? Here's a better script: 1 #!/bin/bash 2 git clone --depth=1 https://github.com/fthx/no-overview.git 3 NO_OVERVIEW=$(jq -r .uuid no-overview/metadata.json) 4 gnome-extensions pack no-overview 5 gnome-extensions install $NO_OVERVIEW.shell-extension.zip 6 # Restart GNOME shell 7 gnome-extensions enable $NO_OVERVIEW in line 6, I found the following: https://github.com/brunelli/gnome-shell-extension-installer/blob/4357903be8646d940902852bf3e150f625e350e6/gnome-shell-extension-installer#L288 This is not doable in Wayland from what I read around... so this will install, and the user will have to enable it manually.

.

No, nothing happened. When I tell gnome-extensions list it return empty. On my x86 desktop running Noble Gnome.

thanks @prahal - the only image I was able to successfully create and boot from was the initial image mentioned in my original post. At that stage there was: - eMMC with RoobiOS pre-installed - NVMe with nothing on it - micro SD card with the https://dl.armbian.com/rock-5-itx/Bookworm_vendor_minimal image Because it was booting to the error message of not being able to mount mmcblk01p as the root file system, I'm guessing that means the boot sequence is eMMC, NVMe and then micro SD. So I thought I would double-check, given that I now have a working NVMe installation ... so I reburned the https://dl.armbian.com/rock-5-itx/Bookworm_vendor_minimal image to micro SD card to see if the board would boot to that before the existing OS on the NVMe drive. IT DID! Not only that but it booted cleanly (asked me to create the root password and my user account)! I had used the same image file that I had downloaded for the first installation so I really have no idea why it worked this time. Now I guess I have to work out how to transfer that to the NVMe drive ... I suspect there are plenty of Google answers for that so that's my research for next week.

Hi everyone, and thanks a lot for the help. I found the solution: the problem was Windows 11 on my laptop. After writing the Armbian image, if the SD card stays inserted, it becomes corrupted within a few seconds. This happens only with Armbian and only with R3S images. I have no idea why. So, to get a proper SD card, I need quick hands to remove it immediately after the writing finishes (no matter which software is used to write).

This part didn't work for you? It was cool that if I had Extension Manager running I could see the toggle turning on and off as I enable/disable. Also, I had to fully reboot to see it working.

Hello, I've recently bought a rock 5B plus. I have a brand new crucial P310 nvme 1TB with the goal to boot from it. As the title says, sometimes the nvme drive is properly detected, sometimes not. (Everytime the controller is visible in lspci, but only sometimes shows in lsblk). When the drive is properly detected, I can write to it and it works fine, without issues. I've noticed that it is more likely to be detected on a cold boot (ie. if I turn off the power and come back the next day, the first time it will probably show up). I have the official radxa 65w PD power adapter (although I've also tried a lot more during the process with the same results). I tried with the official radxa debian image, and with armbian, and the results are exactly the same on both. Btw, I would like to mention that armbian noble gnome doesn't boot even from the sd card (blue led but no display output, I let it for over 10 minutes), only the minimal/iot works. I don't know what else to try at this point, I can post any info / logs you may want. Thanks!

Yes, that's the idea I guess. I played around a bit, but could not enable it with the script ... yet.

You don't need that. Most likely unrelated to this problem, but dd does not verify what was written: https://docs.armbian.com/User-Guide_Getting-Started/#flash-to-sd-card Did you try booting with defaults? Agree, that's not normal. We are seeing some regressions on Allwinner related Crust support to https://github.com/armbian/build/commit/e76540693522baec079ec7633a918a9168ce130c (responsible for low level power management operations) Nothing obvious, no quick solutions based from what is seen from the logs.

If you build the module in question on the target machine, why do you use stuff like "ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-"? Doesn't make sense when building natively.

Any luck? my tx1 is in the mail.

@Nick AI tried to extract the dts from the working image, cloud you help me find any clues. Thank you. I was able to gain access to the os that works, this is the dmesg: dmesg | grep eth [ 8.550757] libphy: 5020000.eth: probed [ 8.568109] sunxi-gmac 5020000.eth eth0: eth0: Type(8) PHY ID 001cc916 at 0 IRQ poll (5020000.eth-0:00) [ 12.765916] sunxi-gmac 5020000.eth eth0: Link is Up - 1Gbps/Full - flow control off [ 12.775526] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready I also upload the pic of ethernet chip. dts.zip