search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.8k stars 494 forks source link

ASUS Tinkerboard S R2.0 #5379

Closed i0466lt closed 2 years ago

i0466lt commented 2 years ago

Details:

Actual behaviour:

Additional logs:

cp: cannot create regular file '/root/.profile': No such file or directory
MichaIng commented 2 years ago

Many thanks for your report.

Is there a reason you use an ancient Buster image with ancient kernel? I highly recommend to use our ASUS Tinker Board image with recent mainline kernel and Debian Bullseye.

But of course the error shouldn't happen. Since I never faced this, can you check the following:

dpkg -L base-files

This should contain /root, i.e. the directory should have been created during the prior package reinstall so that the default profile copying in /var/lib/dpkg/info/base-files.postinst configure should have succeeded.

These are the steps we do to assure a fresh set of base files:

rm -Rfv /etc/{motd,profile,update-motd.d,issue{,.net}} /root /home /media /var/mail
G_AGI --reinstall base-files # Restore /etc/{update-motd.d,issue{,.net}} /root /home
G_EXEC /var/lib/dpkg/info/base-files.postinst configure # Restore /root/.{profile,bashrc} /etc/{motd,profile} /media /var/mail
  1. Remove all base files
  2. Reinstall the package, which re-creates all base files and directories reported by dpkg -L base-files
  3. Re-configure the package, which creates remaining base-files, which are not static part of the package but only created in postinst on a fresh package install (where it is called with configure argument).
MichaIng commented 2 years ago

Marking as closed due to outstanding reply. Feel free to reopen if required.

openegrid commented 1 year ago

Hi Michalng, Wanted to follow up with you on this comment of yours ---- =>Is there a reason you use an ancient Buster image with ancient kernel? I highly recommend to use our ASUS Tinker Board image with recent mainline kernel and Debian Bullseye.

For ASUS Tinkerboard S R2.0 hardware , I am only able to find an image with Debian Buster (DEBIAN OS) 10.10 on ASUS Website or elsewhere, however, we have applications based on Python3.9 which uses Libc2.29. The LibC packaged with Debian Buster is 2.28 and Python3.9 does not work. Upgrading to Bullseye from Buster is not working for us. Is there some pointers or references with instructions or a pre-built OS image/package that we could download with DEBIAN Bullseye. We seem to have got stuck by ordering 20 of these Hardware units for our lab and we are unable to make progress. Please advice. Upgrade instructions that work would also be helpful. Thanks

MichaIng commented 1 year ago

There are Bookworm images (Python 3.11) from the Armbian community: https://www.armbian.com/tinkerboard-2/

openegrid commented 1 year ago

Hi MichaIng/DietPi, Thanks for your response. This image is for Tinkerboard 2S (64 but). What I have is Tinkerboard S R2. Asus has Buster image for this hardware on their website ( for 16Gb eMMC), not Bullseye. Upgrade to Bullseye with this image does not work — I am following instructions from Debian site for upgrade — not sure what is the problem. Apt updates packages (I updated /etc/apt/sources.list to Bullseye) but apt upgrade just returns silently , no errors. Apt full-upgrade too returns silently. Does not upgrade. I am stuck.

On Sat, Apr 29, 2023 at 6:03 PM MichaIng @.***> wrote:

There are Bookworm images (Python 3.11) from the Armbian community: https://www.armbian.com/tinkerboard-2/

— Reply to this email directly, view it on GitHub https://github.com/MichaIng/DietPi/issues/5379#issuecomment-1528910368, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2VFVV5ODNWDFJEZSORAGWDXDW24JANCNFSM5RXFBKRQ . You are receiving this because you commented.Message ID: @.***>

MichaIng commented 1 year ago

Ah, so it is ASUS Tinker Board 1, just a newer revision. Our ASUS Tinker Board image does not boot on this revision?

openegrid commented 1 year ago

They call it Tinkerboard S R2 ( not same as older Tinkerboard S that Asus released in 2018). Your Tinkerboard -2 image does not boot on this hardware.

S R2 is not 64 bit.

Thanks

On Sun, Apr 30, 2023 at 7:33 AM MichaIng @.***> wrote:

Ah, so it is ASUS Tinker Board 1, just a newer revision. Our ASUS Tinker Board image does not boot on this revision?

— Reply to this email directly, view it on GitHub https://github.com/MichaIng/DietPi/issues/5379#issuecomment-1529039054, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2VFVV4RIJ6FI4SN3YWHTF3XDZZ25ANCNFSM5RXFBKRQ . You are receiving this because you commented.Message ID: @.***>

MichaIng commented 1 year ago

Our ASUS Tinker Board image is not 64-bit either. I do not mean the linked Armbian image (mixed up R2 with TB 2), but the one from our download page: https://dietpi.com/#download

openegrid commented 1 year ago

The board did not boot up with this image. I tried. Is this built for “ Tinkerboard S R2 “ or just Tinkerboard S? We are using Tinkerboard S R2.

Thanks Prabhakar

On Sun, Apr 30, 2023 at 7:42 AM MichaIng @.***> wrote:

Our ASUS Tinker Board image is not 64-bit either. I do not mean the linked Armbian image (mixed up R2 with TB 2), but the one from our download page: https://dietpi.com/#download

— Reply to this email directly, view it on GitHub https://github.com/MichaIng/DietPi/issues/5379#issuecomment-1529041048, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2VFVV2LKF7IYWQUMQ4HON3XDZ24XANCNFSM5RXFBKRQ . You are receiving this because you commented.Message ID: @.***>

MichaIng commented 1 year ago

It is build for ASUS Tinker Board (v1) S and non-S.

Hmm, comparing the specs:

Based on this thread, generally it should boot with Armbian bootloader and kernel (which we use): https://forum.armbian.com/topic/27147-tinkerboard-s-r20-patch-to-disable-u-boot-console-logo/ How do you know that it does not boot?

openegrid commented 1 year ago

Hi, I am using win32diskimager app to burn the image to mSD card (which is 32 Gb in size). I use the same app to burn the image from ASUS website and the S R2.0 Buster boots up without issues. I just cannot upgrade to Bullseye -- not sure why , if this had worked, it would have solved my problem.

I image I got from DietPi was burnt onto mSD similarly , but it does not boot up. I checked its content on another linux system by mounting the single partition and I see /boot and other directories (including etc/debian_version) and also Python3 version etc. The image on the mSD looks good, but the unit does not boot up with this image. Let me try once again since you are confirming that the image should boot on S R2. Will let you know. Thanks

On Sun, Apr 30, 2023 at 10:29 AM MichaIng @.***> wrote:

It is build for ASUS Tinker Board (v1) S and non-S.

Hmm, comparing the specs:

Based on this thread, generally it should boot with Armbian bootloader and kernel (which we use): https://forum.armbian.com/topic/27147-tinkerboard-s-r20-patch-to-disable-u-boot-console-logo/ How do you know that it does not boot?

— Reply to this email directly, view it on GitHub https://github.com/MichaIng/DietPi/issues/5379#issuecomment-1529087759, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2VFVV5BYAQOWEWZVSHZQ73XD2OQDANCNFSM5RXFBKRQ . You are receiving this because you commented.Message ID: @.***>

MichaIng commented 1 year ago

But how do you know that it does not boot up? Does an attached HDMI screen stays black only (this does not necessarily mean that it doesn't boot), or can you also verify that it does not show up on the network, e.g. no new DHCP client visible on router and/or do status LEDs clearly indicate that it never exits early boot stage?

A UART adapter would be of course best to debug it via serial console, if you have one.

openegrid commented 1 year ago

I tried to boot again this image --- https://www.armbian.com/tinkerboard/ https://redirect.armbian.com/tinkerboard/Jammy_current

The board did not boot up -- The green blinking LEDs never lit up with this image. The image is fine, I checked after it burnt onto a mSD (32 Gb ) by mounting read only. The whole image is on a single partition. Then I inserted the mSD card , but the board would not boot up -- the Green LED never lights up or blinks.

I then inserted the mSD card burnt from ASUS Website and it boots right up with Buster.

Thanks

On Sun, Apr 30, 2023 at 12:50 PM MichaIng @.***> wrote:

But how do you know that it does not boot up? Does an attached HDMI screen stays black only (this does not necessarily mean that it doesn't boot), or can you also verify that it does not show up on the network, e.g. no new DHCP client visible on router and/or do status LEDs clearly indicate that it never exits early boot stage?

A UART adapter would be of course best to debug it via serial console, if you have one.

— Reply to this email directly, view it on GitHub https://github.com/MichaIng/DietPi/issues/5379#issuecomment-1529125530, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2VFVV7HMUIRKQVRW6DU4QDXD266ZANCNFSM5RXFBKRQ . You are receiving this because you commented.Message ID: @.***>

MichaIng commented 1 year ago

Okay. I don't know why it does not work in your case while it obviously did work for at least the user on the Armbian forum. The R2 variants were released in 2021 already (or earlier), so if it was ever required to explicitly add support to bootloader and/or kernel, this should be the case already.

Other common reasons for failing boot are insufficient PSU or too long power/USB cable. try to detach everything else, change to stronger PSU or shorter/thicker USB cable. Mainline U-Boot and/or kernel may have a larger power draw peak during boot, so this may be required for mainline kernel images even that the TinkerOS images do boot.

If all does not help, when running into the error in dietpi-imager, open a subshell and create the missing directory via

mkdir -m 0700 /root
exit

the select "Retry". However, as it's Linux 4.4 (right?), some things may not work on Debian Bullseye, typically container engines, at least without applying workarounds for missing modern kernel features. This is likely the reason why ASUS never provided Bullseye images for the Tinker Board 1 series.

openegrid commented 1 year ago

Hi MichaIng/DietPi, Thanks for your reply and evaluating various possible scenarios as to why it is not working. Appreciate it very much. However, the ASUS TinkerOS image with 8 GPT partitions (Board has 16 Gb eMMC) boots up quite well on S R2.0.

We have successfully created 64 bit images and running 32 bit applications on the Tinker 2S boards and works quite well. Bullseye upgrade etc really went quite smoothly with that image -- of course, we had to do all the initial digging and configuration to setup the Bullseye image for this. After that point update/upgrade went through smoothly.

May be Tinkerboard S R2.0 is not ready for Bullseye as you have pointed

out -- so they might have restricted the upgrade. I do not see this documented anywhere though. Thanks for your insights.

Best regards

On Sun, Apr 30, 2023 at 2:09 PM MichaIng @.***> wrote:

Okay. I don't know why it does not work in your case while it obviously did work for at least the user on the Armbian forum. The R2 variants were released in 2021 already (or earlier), so if it was ever required to explicitly add support to bootloader and/or kernel, this should be the case already.

Other common reasons for failing boot are insufficient PSU or too long power/USB cable. try to detach everything else, change to stronger PSU or shorter/thicker USB cable. Mainline U-Boot and/or kernel may have a larger power draw peak during boot, so this may be required for mainline kernel images even that the TinkerOS images do boot.

If all does not help, when running into the error in dietpi-imager, open a subshell and create the missing directory via

mkdir -m 0700 /rootexit

the select "Retry". However, as it's Linux 4.4 (right?), some things may not work on Debian Bullseye, typically container engines, at least without applying workarounds for missing modern kernel features. This is likely the reason why ASUS never provided Bullseye images for the Tinker Board 1 series.

— Reply to this email directly, view it on GitHub https://github.com/MichaIng/DietPi/issues/5379#issuecomment-1529140041, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2VFVVYQVMIZOSPHZGOXC2LXD3IIVANCNFSM5RXFBKRQ . You are receiving this because you commented.Message ID: @.***>

MichaIng commented 1 year ago

May be Tinkerboard S R2.0 is not ready for Bullseye as you have pointed out

The hardware itself cannot be "not ready", it's all about the kernel: The TinkerOS kernel generally can work with Bullseye (it boots, basic functionality works), but some features do not work. Recent mainline kernels work with Bullseye fully featured. It is a known problem that manufacturers usually do not update their vendor kernel sources: They fork and patch an own kernel once, and leave it on the version, so that about 2 years later modern distros won't work with it anymore, at least not fully featured. It is then often volunteers who upstream support for those SBCs into mainline kernel, using backwards engineering etc. Same for the bootloader (usually U-Boot).

However, the ASUS TinkerOS image with 8 GPT partitions (Board has 16 Gb eMMC) boots up quite well on S R2.0.

As said, only because vendor images boot does not mean that the PSU/cable really is sufficient to reliably cover power peaks of the board. We see it regularly that after a kernel upgrade, or when switching from vendor kernel to mainline kernel, SBCs do not boot anymore, but after switching to a stronger PSU (higher quality, keeping voltage in strikter borders) and/or using a better USB cable fixes the issue. Of course the same can be true the other way round, it is just not seen often that people downgrade to and old/vendor kernel from a functional recent mainline kernel.

Which partitioning is supported depends on the bootloader. And our image ships with a U-Boot build which supports a single ext4 partition, including the /boot/boot.scr boot script on it.

Let me open this issue and ask for testers to verify whether or does or does not work for others with R2.0.

Btw, not sure whether I understood correctly: Did it work with dietpi-installer after creating the /root directory? There may be other issues, e.g. if the TinkerOS has unusual kernel and/or bootloader package names. Our script keeps packages named linux-image-* (a common standard naming used by most distros), but manufacturers sometimes use different kernel package names, so that they get removed during the dietpi-installer process and need to be reinstalled before rebooting.