Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update from DietPi version 6.2 to 6.35 generate issue #4385

Closed
orotarobas opened this issue May 17, 2021 · 32 comments
Closed

Update from DietPi version 6.2 to 6.35 generate issue #4385

orotarobas opened this issue May 17, 2021 · 32 comments
Labels
Bug 🐞 Solution available 🥂 Definite solution has been done
Milestone
v7.2

Comments

@orotarobas
Copy link

Creating a bug report/issue

Required Information

I'm using NanPi Neo Core for our industrial embedded application, I can succesfuly install the dietpi image provided on the manufacturer repo here https://drive.google.com/file/d/1FTJpsptgWkUFHprD1RLUBXOSCXyVaLWH/view?usp=sharing.

If I perform the installaton without any network connection, and the system boots properly.
Since at boot the tool dietpi-software gets automatically invoked, if i connect the network interface the dietpi gets updated to the newer version 6.35, but after that after login i start getting this message:

"DietPi-Login | Waiting for DietPi-RAMDISK to finish mounting DietPi to RAM..."

this keeps going in an infinite loop till i press control-C.

Since the application needs to be autolaunched after board boot this behaviour is not acceptable, so i would like to know how to prevent dietpi-software to be automatically invoked.

I tried also to use the new dietpi version built for Nanopi Neo, but that version has issues with audio drivers that the 6.2/6.35 doesn't have.
@Joulinar
Copy link
Collaborator

Joulinar commented May 17, 2021 •
edited
Loading

Hi,

by default DietPi will perform an update to latest version always on first boot. For this a valid internet connection is required to complete first initial setup. Once initial setup completes, the SBC can be operated without network connection as well.

But if I understood correctly,. initial setup did not complete. Correct?

@MichaIng
Copy link
Owner

Many thanks for your report. Is there a reboot done after/during the automated update?

@orotarobas
Copy link
Author

orotarobas commented May 17, 2021 via email

@Joulinar
Copy link
Collaborator

You need a valid internet connection to complete initial setup, otherwise it will re-run on every reboot trying to complete the setup

@orotarobas
Copy link
Author

orotarobas commented May 17, 2021 via email

@MichaIng
Copy link
Owner

MichaIng commented May 17, 2021 •
edited
Loading

The image is ancient, so not sure whether the update path is still intact. Let me explain what "should" happen:

  • On first login, DietPi-Software should start and in case after a few initial prompts about password and serial console, DietPi-Update should be invoked.
  • The update should update the DietPi scripts/core files, then "incremental patches" should start, DietPi-RAMdisk should be disabled and removed as first step, then you should see a dialogue saying "The system will now reboot to finish this update.". This reboot is essential to load the new versions of the scripts, since the update system has been reworked in the meantime and the RAMdisk removal.
  • After the reboot and login, DietPi-Update should run again and this time finish the update to DietPi v7.1.2.
  • Then DietPi-Software should start, allowing you to finish initial installs.

In your case it didn't seem to happen like that, so please tell us how it differs, at best with the related console output, copy&pasted here, or as screenshot, or the log file: /var/tmp/dietpi/logs/dietpi-firstrun-setup.log

@MichaIng
Copy link
Owner

Actually, your NanoPi NEO image should support the NEO Core as well. Not 100% sure if the internal eMMC as system partition works, but worth to give it a try, have much newer Linux and Debian version and avoid the ancient update path: https://dietpi.com/downloads/images/DietPi_NanoPiNEO-ARMv7-Buster.7z

@orotarobas
Copy link
Author

orotarobas commented May 17, 2021 via email

@MichaIng
Copy link
Owner

MichaIng commented May 17, 2021 •
edited
Loading

I'd go with the new image and debugging the sound card issue. Does it have an onboard sound chip or is it an attached USB DAC? I see it has audio I/O pins, but not sure whether this means onboard chip or not.

The other issue with the ancient image is that it's Debian Stretch, where we drop support for this year. But if you have the console output or log, we could have a look into this as well, as if there is a bug in the update path, it would be good to fix it.

@orotarobas
Copy link
Author

orotarobas commented May 17, 2021 via email

@ravenclaw900
Copy link
Collaborator

Could you post the logfile at /var/tmp/dietpi/logs/dietpi-firstrun-setup.log?

@orotarobas
Copy link
Author

orotarobas commented May 17, 2021 via email

@Joulinar
Copy link
Collaborator

Pls can you attach the log on GitHub directly as it is missing if you send it via email. Thx

@orotarobas
Copy link
Author

dietpi-firstrun-setup.log

Hope this works

@MichaIng
Copy link
Owner

Okay and when you login now, you still see the "DietPi-Login | Waiting for DietPi-RAMDISK to finish mounting DietPi to RAM..." message?
Because the log file indicates that the code is up-to-date, which means that there should be no check the RAMdisk anymore 🤔.

@orotarobas
Copy link
Author

orotarobas commented May 17, 2021 via email

@MichaIng
Copy link
Owner

Ah okay, no all fine then, lets check the audio issue. As it's the H3 onboard chip, the kernel should contain the driver. Can you please the output of:

aplay -l
dmesg | grep -E '(audio|snd|sound)'

MichaIng added a commit that referenced this issue May 18, 2021
@MichaIng
v7.2
b1de551 
+ DietPi-Patch | Fix update path for DietPi versions prior to v6.17: #4385
@MichaIng
Copy link
Owner

MichaIng commented May 18, 2021 •
edited
Loading

Fixed the issue with old images. Basically all DietPi versions prior to v6.17 had unintentionally v7 applied as core version, before doing any incremental patches, so that no new update was found on update restart: b1de551
Changelog: c7dc7f0

@orotarobas
Copy link
Author

orotarobas commented May 18, 2021 via email

@orotarobas
Copy link
Author

orotarobas commented May 18, 2021 via email

@MichaIng
Copy link
Owner

MichaIng commented May 18, 2021 •
edited
Loading

okay i'll try to install the old version then to check if everything is
smooth.

No wait this won't work yet! It will work when v7.2 has been released. And while it's good to have this fixed, it's not worth to actively install a Debian Stretch based image. Let's see if we can get audio working on the new one.

@orotarobas
Copy link
Author

orotarobas commented May 18, 2021 via email

@MichaIng
Copy link
Owner

Okay, please edit /boot/armbianEnv.txt and append analog-codec to the overlays= line, then reboot. Onboard audio seems to be disabled by default on H3 boards with this kernel/device tree setup, the related device tree overlay enables it.

You find all device tree overlays in /boot/dtb/overlay/, the ones with sun8i-h3- prefix, enabling further features. Add the name without prefix and file extension to the /boot/armbianEnv.txt overlays line, so e.g. "uart1" to enable the 1st UART device for serial console or such.

You seem to know the board already, but for others, here is the GPIO/pin layout: http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Core#Layout

@orotarobas
Copy link
Author

orotarobas commented May 18, 2021 via email

@MichaIng
Copy link
Owner

/var/lib/dietpi/dietpi-autostart/custom.sh should actually run interdependently of the login. It might be a coincidence that it ran afterwards, but when you wait a little longer it should run by itself. It is an own systemd service (systemctl status dietpi-autostart_custom) that runs independently from the login.

Option 7 still requires you to manually login? Or do you speak of SSH? Note that this means login at local terminal console TTY1, so the one you reach when connecting a screen and keyboard. SSH autologin would need to be configured with the SSH client, the server has no charge on this. When choosing option 7, away from option 14, the custom script service is removed, so that is expected, but as said, autologin is not required for it to start.

If the task you need to run is not a long-term background job, you can have it executed as well by adding a script to /var/lib/dietpi/postboot.d. This can be also the custom.sh you used before:

mv /var/lib/dietpi/dietpi-autostart/custom.sh /var/lib/dietpi/postboot.d/custom.sh

The changing MAC address is indeed something common on those Allwinner SoCs: #3618
First please try to set it via boot config by adding the following two lines to /boot/armbianEnv.txt:

ethaddr <mac_address>
eth1addr <mac_address>

Replacing <mac_address> with the actual one you want to have, at best the currently used one so that it's assured to be a valid mac. Then reboot.

If those have no effect, then there is a second solution:

echo 'SUBSYSTEM=="net", KERNEL=="eth0", ACTION=="add", RUN+="ip l set dev eth0 address <mac_address>"' > /etc/udev/rules.d/99-eth0-mac.rules

Same here, replacing <mac_address> with the actual one you want to have.

@orotarobas
Copy link
Author

orotarobas commented May 22, 2021 via email

@MichaIng
Copy link
Owner

MichaIng commented May 22, 2021 •
edited
Loading

2)i'm using debug terminal consolle on TTYS0, the default one, and
option 7 doesn't work, do not allow me to autologin

Okay that makes sense. The console autologin sets this up on tty1 only, not ttyS0. But you could manually setup autologin there:

mkdir -p /etc/systemd/system/serial-getty@ttyS0.service.d
cat << '_EOF_' > /etc/systemd/system/serial-getty@ttyS0.service.d/autologin.conf
[Service]
ExecStart=
ExecStart=-/sbin/agetty -a root -J -s %I 115200,57600,38400,9600 $TERM
_EOF_

But this has no effect on any dietpi-autostart option.

3)i checked mac setup as you suggested and i can confirm it works

Did editing /boot/armbianEnv.txt alone fix the MAC address already or was the udev rule required? I remember a previous case where indeed ethaddr/eth1addr entries in /boot/armbianEnv.txt didn't have an effect, so they can be removed again. The udev rule should work in every case and does override any previously set MAC address.

This was referenced May 22, 2021
Merged
Closed
Merged
@MichaIng MichaIng added this to the v7.2 milestone Jun 2, 2021
@MichaIng
Copy link
Owner

MichaIng commented Jun 2, 2021

The upgrade issue for old images has been solved. I'm marking this hence as closed. Feel free to reopen if required.

@MichaIng MichaIng closed this as completed Jun 2, 2021
@orotarobas
Copy link
Author

orotarobas commented Jun 11, 2021 via email

@MichaIng
Copy link
Owner

Can you share the output of the install process up to where it failed?

@orotarobas
Copy link
Author

Here are all the logs files.

dietpi-firstrun-setup.log
dietpi-ramdisk.log
dietpi-ramlog.log
dietpi-software_apt.log
dietpi-update.log
fs_expand.log
fs_partition_resize.log

@MichaIng
Copy link
Owner 

[ INFO ] DietPi-Update | Getting repository version: https://raw.githubusercontent.com/MichaIng/DietPi/master/.update/version
[FAILED] DietPi-Update | Unable to get repository version. Please check your network connection, then rerun dietpi-update.

The download if the version file failed, but there is no related curl error message. From the error prompt, you should be able to exit to the shell. Would be interesting to try manually downloading this file from there:

cd /tmp
curl -sSfL https://raw.githubusercontent.com/MichaIng/DietPi/master/.update/version -o version
echo $? # check exit code

@Joulinar Joulinar mentioned this issue Aug 6, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug 🐞 Solution available 🥂 Definite solution has been done
Projects
None yet
Milestone
v7.2
Development

No branches or pull requests
4 participants
@MichaIng @Joulinar @ravenclaw900 @orotarobas