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

Open beta v6.17 | Please help to improve stability before next release #2140

Closed
5 tasks done
MichaIng opened this issue Oct 14, 2018 · 17 comments
Closed
5 tasks done

Open beta v6.17 | Please help to improve stability before next release #2140

MichaIng opened this issue Oct 14, 2018 · 17 comments
Assignees
@Fourdee @MichaIng
Labels
Beta 🧪 Issues specific to the Beta branch testing Information ℹ️
Milestone
v6.17

Comments

@MichaIng
Copy link
Owner

MichaIng commented Oct 14, 2018 •
edited
Loading

New open beta launched: Please help bullet-prove testing the upcoming DietPi release!

€€: Beta v6.17.9 is up with several fixes: https://github.com/Fourdee/DietPi/pull/2166 https://github.com/Fourdee/DietPi/pull/2167

€: Beta v6.17.7 is up, which fixed a few issues and resolved the need to manually rerun dietpi-update to apply v6.16 => v6.17 patch, see below.
Related PR: https://github.com/Fourdee/DietPi/pull/2150

We just started public beta testing:

We hope much of you can help to test v6.17 before we push it to release branch. Note that the new "beta" branch can be considered as stable as the prior "master" (release) branch. We internally run the same careful tests before pushing changes from active development into beta branch. So the purpose of the new system is not to outsource in-dev testing, but to further improve release stability and avoid hotfix releases, like sometimes needed in the past.
The vast possible combinations of SBC devices, distro versions, configurations and installed software titles has grown too large to internally test every single of them.

Of course we appreciate, if testers have a special eye on the features we add/change with this release. Check out the current changelog: https://github.com/Fourdee/DietPi/blob/beta/CHANGELOG.txt

How to apply the beta branch on your system: https://github.com/Fourdee/DietPi/blob/beta/BRANCH_SYSTEM.md

If you find any bugs, please open a separate issue, mentioning "beta" in the header, e.g.
Beta v6.17 | Software title foo fails to install

Use this thread for general feedback or questions about our new beta program.

Happy testing 🥂!

Known issues

Urgent

DietPi functionality

DietPi visual

SBC/device related

Software title related

Open for discussion
@MichaIng MichaIng added Testing/testers required 🔽 Information ℹ️ Beta 🧪 Issues specific to the Beta branch testing labels Oct 14, 2018
@MichaIng MichaIng added this to the v6.17 milestone Oct 14, 2018
@MichaIng MichaIng mentioned this issue Oct 14, 2018
Closed
@Millichrome
Copy link

I will this a go on my test 3B+ board.

@MichaIng
Copy link
Owner Author

@Fourdee
I summed up all open bugs/known issues above.
Since we are in open beta phase, besides recent/urgent and newly reported issues, we could also have a look on older issues with lower priority.

Either stop with new features/larger enhancements until release, or do not merge them into current beta. So we use the beta phase to calm down dev a bid and instead concentrate on stability, testing and fixing. What you think?

@Millichrome
Copy link

I successfully updated my ASUS tinker board to 16.17 beta. It runs PLEX, qbittorrent, Samba and Pi-hole. Not seeing any issues so far, all applications are working well.

I did have an issue when installing a fresh image of 16.17 beta on my 3B+. I downloaded the latest Raspberry Pi image and changed the channel to "beta" in dietpi.txt. However, when I connected via SSH, the terminal showed that I was running 16.16 beta:

firstboot

I updated to 16.17 beta without any issues. Haven't got a chance to test out any applications, but I was thinking of running a home media centre off the Pi.

@MichaIng
Copy link
Owner Author

MichaIng commented Oct 15, 2018 •
edited
Loading

@Millichrome
Thanks for this report.

Indeed I imagine an issue when installing a fresh image and directly switch to beta branch:

  • Currently when updating pre-v6.17 to v6.17, dietpi-update needs to be rerun manually to apply the new versioning system.
  • The new DietPi code is already in place then, but the incremental patches were not yet done. So we manually set version string to v6.16.0 to allow second dietpi-update run applying the incremental patches as well.
  • When flashing a pre-v6.17 image, on first boot dietpi-update will automatically run, but of course the second manual run is still outstanding. Since dietpi-software will pop up already and offer configuration/software install, even that incremental patches are missing, this can lead to issues.

@Fourdee
We need to do a version check on first run after initial dietpi-update run. If subversion string is (still) lower than 17, we either need to automatically do a second update or prompt info to user to do so.

  • I would prefer to do that automatically. Actually first run update could simply be a while loop that rechecks available update until none available any more. Only risk is for some reason a unlimited loop, if something goes wrong with version string/var update 🤔.
  • Hmm also practically not trivial to implement, since new code is only in place, after first run update already done and install stage already set to 1 (finished). Checked the code. Should be possible to set .update_stage to -1 (when .install_stage < 1) when patch_file applies now versioning system. Since dietpi-update is terminated, it does not apply value 0, so dietpi-software does not apply value 1, so first run update is re-triggered. But hmm, no reboot triggered then, dietpi-software first-run install can be done, which is not good 🤔.
  • Actually best would be, if we could somehow trigger a second dietpi-update 1 run without reboot between both. When applying new versioning system and (( $(</DietPi/dietpi/.install_stage) < 1 )), do sed -i '\|/DietPi/dietpi/dietpi-update 1|a\/DietPi/dietpi/dietpi-update 1' /DietPi/dietpi/dietpi-software. Hmm does not work, since current dietpi-software code already loaded of course 🤔.
    - Ah waaaaait: G_EXIT_CUSTOM in patch_file can be added to restart dietpi-update. Since /tmp/DietPi-Update has already removed prior to G_EXIT_CUSTOM, this will work. We can use this also for interactive (non-firstrun) updates to v6.17 😃! We could pgrep for "dietpi-update 1" to decide if we run it forcefully (non-interactively) as well or not.     €: Fixed, was finally not too hard: https://github.com/Fourdee/DietPi/pull/2145

Check why (beta) is shown in DietPi banner:

  • It is somehow right, because at least beta code is already applied, but somehow wrong because incremental patches still missing. And looks confusing because there is no v6.16.0 beta 😆.
  • https://github.com/Fourdee/DietPi/blob/beta/dietpi/patch_file#L46-L49
    Perhaps we should skip those G_GIT* value estimation. The values from dietpi.txt are "target" values, not "current" values. dietpi-globals will apply "Fourdee" and "master" as default init, which leads to no branch is shown in banner, so no confusion. dietpi-update of course will still apply the branch, configured in dietpi.txt, so it's really just about the visual strings shown in banner and during update and does not affect anything else. €: Included in: https://github.com/Fourdee/DietPi/pull/2145

@Millichrome
Copy link

I see, so it's a purely visual thing. I do remember thinking that the installation process felt a bit more involved than a stable image. :)

@MichaIng
Copy link
Owner Author

@Millichrome
Jep issues are unlikely, but theoretically possible, especially when you choose several software titles for install on first login and/or the image has a very old DietPi version. Also if I checked to code right, currently a reboot after first run update is missing.
So theoretically code with missing incremental patches can lead to issues during dietpi-software applying initial setup and installs.

But I found a solution I guess, that even allows to skip the manual second update run, when applying beta on fully installed systems. Will play around with this now 😃.

@MichaIng MichaIng mentioned this issue Oct 16, 2018
Closed
@Millichrome
Copy link

Possible bug:
WiFi installation doesn't start with a fresh beta image on my 3B+. The device didn't appear on the router WiFi client list during multiple checks after initialization.

Beta image installation via etherenet works great. I can switch to WiFi only after completing the installation via ethernet.

Trying a fresh Etcher image didn't help. I have previously installed DietPi via WiFi with older stable releases.

QOL issue?
After installing a fresh beta image via ethernet for a second time, I noticed that the installation takes a while to initialize. I believe it took at least 10 min for my device to appear on the etherent client list. No idea if this is related to my setup or something about DietPi. I think it's fine if this is related to beta processes, but it felt long for a stable release.

@MichaIng
Copy link
Owner Author

MichaIng commented Oct 16, 2018 •
edited
Loading

@Millichrome
As of what I mentioned above and added to OT: Did you try to install via WiFi but master branch first, then apply beta update after first run setup?

It's too late now for me to go through it, but since we did some changes about WiFi with the last two releases, I think the missing reboot after initial update might lead to code inconsistencies.

About second Ethernet attempt:

  • Did you use DietPi-Automation actually (configure dietpi.txt to automatically install software on first boot)?
  • Do you have a chance to follow the init process on screen? Would be helpful to know which step exactly takes so long.

Btw, I finished a PR to apply the second dietpi-update execution automatically: https://github.com/Fourdee/DietPi/pull/2145
This should avoid mentioned potential issues.

I want to finish another visual issue with whiptail menus inside patch_file (done) and maybe we manage to fix one or another bug, listed in OT, before merging next RC into beta.

Next beta v6.17.6 is up, OT updated accordingly.

@Millichrome
Copy link

@MichaIng

I was able to do WiFi install using the master branch, but not the beta branch.

The ethernet install was for a clean image. No additional applications or modification other than setting the channel to beta.

I will try out the 6.17.7 version advertised by the dietpi-update and report back.

@Fourdee
Copy link
Collaborator

Fourdee commented Oct 22, 2018

Beta in final stages of testing.

Pending 2+ days of additional testing, we'll release v6.17. Outstanding issues without a quick/viable fix will be moved to v6.18 to prevent delaying v6.17 further.

@dynobot
Copy link

dynobot commented Oct 25, 2018

Tried to run the beta on Odroid C2 in order to see if the Ethernet issues were resolved. No luck.
Once after the install and reboot I lost my network connection via Ethernet. Dead in the water now.

@dynobot
Copy link

dynobot commented Oct 25, 2018

Tried to run the beta on Odroid C2 in order to see if the Ethernet issues were resolved. No luck.
Once after the install and reboot I lost my network connection via Ethernet. Dead in the water now.

Found the problem.....at least for me.

The Ethernet was not broken....it IP address changed !!

I looked on my router and saw a new IP address, I ssh'd into it and behold.....it was the Odroid C2.

Next I tried connecting to wifi using a dongle.....worked fine.

Rebooted and wifi connected no problem
Rebooted again just for kicks and it worked without a hitch.

@dynobot
Copy link

dynobot commented Oct 25, 2018 •
edited
Loading

Spoke too soon....wifi worked long enough for me to ssh into the Odroid then it died. It seems to be coming on and off....not only the wifi but the USB ports. I can see my connected DAC turning on and off too.

Seeing that both the DAC and the Wifi seem to be cycling on and off I unplugged the DAC's power which it gets from the USB ports. Now my wifi seems to be okay. Looks like the Odroid has some power issues concerning its USB ports.

@Fourdee
Copy link
Collaborator

Fourdee commented Oct 25, 2018 •
edited
Loading

@dynobot

Looks like the Odroid has some power issues concerning its USB ports.

Interesting, if you are already running a 5V/2A PSU (official HK, or, RPi), might be worth investing in a mains powered USB hub, eg:
https://www.amazon.co.uk/Belkin-Ultra-Powered-Power-Supply/dp/B0061RSACG

Also, when instability occurs, check dmesg for any errors/issues at the end lines. Might give some more info.

@MichaIng
Copy link
Owner Author

MichaIng commented Oct 25, 2018 •
edited
Loading

@dynobot

IP address changed

Interesting, the Odroid receives its IP via DHCP I believe? This is something the DHCP server decides and there is nothing you can do about it on the client, besides changing the MAC address. But this is nothing we do DietPi side. What we did with v6.13 -> v6.14 patch is resetting the device ID, but this is nothing a DHCP server should even be able to recognize (?).

Usually a DHCP server reserves assigned IPs for a certain lease time. If the DHCP client is up the same IP should be extended automatically. So not sure what could have caused a change in your case. But to be sure you should, if possible, configure your router to assign a fixed IP to the Odroid. In many cases it is as well possible to simply disable the DHCP client and configure the system use a static IP within the DHCP IP range. In my case this works great at least, so one background process less on the machine 🙂.

@Fourdee
Copy link
Collaborator

Fourdee commented Oct 25, 2018

Thanks to everyone for helping with the Beta test, we really appreciate your support!

Marking this as completed, pending v6.17 release today.

@Fourdee Fourdee closed this as completed Oct 25, 2018
@MichaIng
Copy link
Owner Author

NB: The last beta is identical to current master (release), so you don't need to actively change branches and reapply the update.
You will then see an update notification, once we open up the next beta phase. Feel free to re-join next beta phase then by applying the update or switch to master branch to stay with current release and mute beta update notifications.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Fourdee Fourdee

@MichaIng MichaIng

Labels
Beta 🧪 Issues specific to the Beta branch testing Information ℹ️
Projects
None yet
Milestone
v6.17
Development

No branches or pull requests
4 participants
@Fourdee @MichaIng @Millichrome @dynobot