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.

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

Open Beta v6.29 | Please help testing and hardening the upcoming release #3452

Closed
MichaIng opened this issue Apr 1, 2020 · 21 comments
Closed
Labels
Beta 🧪 Issues specific to the Beta branch testing Information ℹ️
Milestone

Comments

@MichaIng
Copy link
Owner

MichaIng commented Apr 1, 2020

RC version v6.29.2
Changelog https://github.com/MichaIng/DietPi/blob/beta/CHANGELOG.txt
Code changes master...beta
v6.29.0 to v6.29.1 #3470
v6.29.1 to v6.29.2 #3501
How to apply https://github.com/MichaIng/DietPi/blob/master/BRANCH_SYSTEM.md
Release planned Mid April 2020

Important testing cases:

  • DietPi-RAMdisk has been removed and many API/function changes have been done (see changelog), a special eye hence needs to be kept on the transition/update.
  • Our new error handler/wrapper G_EXEC is a vast rework. If it ever pops up, check if it looks and works as expected.
  • We switched from en_GB.UTF-8 to C.UTF-8 as default locale for our scripts. Since both is English, this should not cause any changes, but if any outputs (only DietPi script internally) looks wrong or strange ordered, please let us know.

Related/solved issues: https://github.com/MichaIng/DietPi/issues?q=is%3Aissue+milestone%3Av6.29


Known issues

DietPi functionality

SBC/device related

Software title related

@MichaIng MichaIng added Information ℹ️ Beta 🧪 Issues specific to the Beta branch testing labels Apr 1, 2020
@MichaIng MichaIng added this to the v6.29 milestone Apr 1, 2020
@MichaIng MichaIng pinned this issue Apr 1, 2020
@Joulinar
Copy link
Collaborator

Joulinar commented Apr 1, 2020

basic update seems fine. let me know of you like to test specific scenarios.

@kinoushe
Copy link

kinoushe commented Apr 2, 2020

Has DietPi-RAMlog been removed or DietPi-RAMdisk, or are they the same?

@MichaIng
Copy link
Owner Author

MichaIng commented Apr 2, 2020

@kinoushe
Ah a mistake in the text (just fixed it), only RAMdisk has been removed, hence the /DietPi tmpfs mountpoint, which is a symlink now to keep it backwards compatible. The /var/log tmpfs mountpoint feature is still available as it is highly useful.

@GvY85
Copy link

GvY85 commented Apr 17, 2020

I have beta 6.29 running for some days now on 2 amd64 intel mini-pc systems (up-squared):
1: Pihole, PiVPN (Wireguard server), Stubby, Samba
2: qBittorrent, Wireguard client, Samba, MiniDLNA

I primairly switched because of the Dietpi-drive_manager timeout issue on externall usb hhd's. That seems to work fine now. correction, all 3 drives I use are not supported by hdparm, it works once but after reboot changes are gone. see 3309 and 3420.

The Intel NUC cpu temp fix works fine, see 3412 and 3172

Also, i cant see any other issues.

@MichaIng
Copy link
Owner Author

MichaIng commented Apr 26, 2020

v6.29.1 has been pushed to beta: #3470

@Joulinar
Copy link
Collaborator

did a test on my RPi3b and a VM. Seems working fine. Tested as well OctoPrint and Koel. The only thing I noticed (but this is behaving same as before) Koel is not successfully installing on my RPi while it finished without issues on my VM. Not sure if the RPi platform is not supported.

[1/4] Resolving packages...
[2/4] Fetching packages...
info fsevents@1.2.9: The platform "linux" is incompatible with this module.
info "fsevents@1.2.9" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
error /mnt/dietpi_userdata/koel/node_modules/cypress: Command failed.
Exit code: 1
Command: node index.js --exec install
Arguments:
Directory: /mnt/dietpi_userdata/koel/node_modules/cypress
Output:
Installing Cypress (version: 3.4.1)

[10:20:41]  Downloading Cypress     [started]
[10:20:43]  Downloading Cypress     [failed]
[10:20:43] → The Cypress App could not be downloaded.

Does your workplace require a proxy to be used to access the Internet? If so, you must configure the HTTP_PROXY environment variable before downloading Cypress. Read more: https://on.cypress.io/proxy-configuration

Otherwise, please check network connectivity and try again:

----------

URL: https://download.cypress.io/desktop/3.4.1?platform=linux&arch=ia32
Error: Failed downloading the Cypress binary.
Response code: 404
Response message: Not Found

----------

Platform: linux (Debian - 10.3)
Cypress Version: 3.4.1
The Cypress App could not be downloaded.

Does your workplace require a proxy to be used to access the Internet? If so, you must configure the HTTP_PROXY environment variable before downloading Cypress. Read more: https://on.cypress.io/proxy-configuration

Otherwise, please check network connectivity and try again:

----------

URL: https://download.cypress.io/desktop/3.4.1?platform=linux&arch=ia32
Error: Failed downloading the Cypress binary.
Response code: 404
Response message: Not Found

----------

Platform: linux (Debian - 10.3)
Cypress Version: 3.4.1

info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
Oops! Koel installation or upgrade didn't finish successfully.
Please try again, or visit https://docs.koel.dev for manual installation.
😥 Sorry for this. You deserve better.

@MichaIng
Copy link
Owner Author

MichaIng commented Apr 27, 2020

@Joulinar
Many thanks for testing. Indeed the attempted download does not exist: https://download.cypress.io/desktop/3.4.1?platform=linux&arch=ia32
Skipping &arch=ia32 and it downloads, but the wong x86_64 arch: https://cdn.cypress.io/desktop/3.4.1/win32-x64/cypress.zip
Actually "ia32" usually means x86 (32bit), hence is wrong as well...

Verified our install method + dependencies still match current Koel docs, so it seems that something is wrong with how composer Node.js resolves or pulls dependencies on ARM, at least cypress.

After our moving, tomorrow we finally get broad band internet installed, which comes very delayed due to corona circumstances... Then I can spin up my server and RPi again to run a test. Meanwhile I'll check in VM ARMv8 container.

@Joulinar
Copy link
Collaborator

@MichaIng

not sure if it is still needed

root@DietPi3:/mnt/dietpi_userdata/koel# composer install -vvv
Reading ./composer.json
Loading config file ./composer.json
Checked CA file /etc/ssl/certs/ca-certificates.crt: valid
Executing command (/mnt/dietpi_userdata/koel): git branch --no-color --no-abbrev -v
Executing command (/mnt/dietpi_userdata/koel): git describe --exact-match --tags
Executing command (/mnt/dietpi_userdata/koel): git log --pretty="%H" -n1 HEAD
Executing command (/mnt/dietpi_userdata/koel): hg branch
Executing command (/mnt/dietpi_userdata/koel): fossil branch list
Executing command (/mnt/dietpi_userdata/koel): fossil tag list
Executing command (/mnt/dietpi_userdata/koel): svn info --xml
Failed to initialize global composer: Composer could not find the config file: /root/.composer/composer.json
To initialize a project, please create a composer.json file as described in the https://getcomposer.org/ "Getting Started" section
Reading /mnt/dietpi_userdata/koel/vendor/composer/installed.json
Loading plugin PackageVersions\Installer
Loading plugin UpdateHelper\ComposerPlugin
Loading plugin cweagans\Composer\Patches
Running 1.10.5 (2020-04-10 11:44:22) with PHP 7.3.14-1~deb10u1 on Linux / 4.19.97-v7+
Do not run Composer as root/super user! See https://getcomposer.org/root for details
Reading ./composer.lock
Gathering patches for root package.
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Reading ./composer.lock
Resolving dependencies through SAT
Looking at all rules.

Dependency resolution completed in 0.021 seconds
Analyzed 343 packages to resolve dependencies
Analyzed 1151 rules to resolve dependencies
Nothing to install or update
Package facebook/webdriver is abandoned, you should avoid using it. Use php-webdriver/webdriver instead.
Generating optimized autoload files
Deprecation Notice: Class phpmock\test\MockNamespaceTest located in ./vendor/php-mock/php-mock/tests/MockNamespaceTest.php does not comply with psr-4 autoloading standard. It will not autoload anymore in Composer v2.0. in phar:///usr/local/bin/composer/src/Composer/Autoload/ClassMapGenerator.php:201
Stack trace:
 phar:///usr/local/bin/composer/src/Composer/Autoload/ClassMapGenerator.php:116
 phar:///usr/local/bin/composer/src/Composer/Autoload/AutoloadGenerator.php:355
 phar:///usr/local/bin/composer/src/Composer/Autoload/AutoloadGenerator.php:341
 phar:///usr/local/bin/composer/src/Composer/Autoload/AutoloadGenerator.php:264
 phar:///usr/local/bin/composer/src/Composer/Installer.php:307
 phar:///usr/local/bin/composer/src/Composer/Command/InstallCommand.php:122
 phar:///usr/local/bin/composer/vendor/symfony/console/Command/Command.php:245
 phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:835
 phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:185
 phar:///usr/local/bin/composer/src/Composer/Console/Application.php:281
 phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:117
 phar:///usr/local/bin/composer/src/Composer/Console/Application.php:113
 phar:///usr/local/bin/composer/bin/composer:61
 /usr/local/bin/composer:24
Carbon 1 is deprecated, see how to migrate to Carbon 2.
https://carbon.nesbot.com/docs/#api-carbon-2
    You can run './vendor/bin/upgrade-carbon' to get help in updating carbon and other frameworks and libraries that depend on it.
> post-autoload-dump: Illuminate\Foundation\ComposerScripts::postAutoloadDump
> post-autoload-dump: @php artisan package:discover
Executing command (CWD): '/usr/bin/php7.3' -d allow_url_fopen='1' -d disable_functions='' -d memory_limit='-1' artisan package:discover
Discovered Package: aws/aws-sdk-php-laravel
Discovered Package: barryvdh/laravel-ide-helper
Discovered Package: fideloper/proxy
Discovered Package: laravel/tinker
Discovered Package: mpociot/laravel-apidoc-generator
Discovered Package: nesbot/carbon
Discovered Package: nunomaduro/larastan
Package manifest generated successfully.
ocramius/package-versions:  Generating version class...
ocramius/package-versions: ...done generating version class
> post-install-cmd: @php artisan clear-compiled
Executing command (CWD): '/usr/bin/php7.3' -d allow_url_fopen='1' -d disable_functions='' -d memory_limit='-1' artisan clear-compiled
Compiled services and packages files removed!
> post-install-cmd: @php artisan cache:clear
Executing command (CWD): '/usr/bin/php7.3' -d allow_url_fopen='1' -d disable_functions='' -d memory_limit='-1' artisan cache:clear
Failed to clear cache. Make sure you have the appropriate permissions.
> post-install-cmd: @php -r "if (!file_exists('.env')) copy('.env.example', '.env');"
Executing command (CWD): '/usr/bin/php7.3' -d allow_url_fopen='1' -d disable_functions='' -d memory_limit='-1' -r "if (!file_exists('.env')) copy('.env.example', '.env');"
root@DietPi3:/mnt/dietpi_userdata/koel#

@MichaIng
Copy link
Owner Author

MichaIng commented May 3, 2020

DietPi v6.29 has been released: #3502

Many thanks to all testers! ❤️

@Joulinar
Ah now I forgot about Koel. Works fine on x86_64, in ARMv8 container install does not work as at exactly the same step [2/4] Fetching packages... it hangs on "Your network connection seems to be not working, retrying..." or something like that. Must have something to do with that container network setup where the network adapters cannot be manipulated manually but the container simply accesses the one from host moreless directly, which enables internet access and even allows to access web applications of the "guest" directly on host IP...
However the error you reported really looks like a npm/node repo bug that should be resolved soon. Otherwise we need to fix or workaround with next release, as v6.29 was already much overdue with many important fixes inside already that cannot wait 😉.

@MichaIng MichaIng unpinned this issue May 3, 2020
@MichaIng MichaIng closed this as completed May 3, 2020
@ELDI-Steinar
Copy link

Did a update from 6.28.0 to 6.29.2 now on one of my RPi devices.
When i login my user (not root) there is a change in LAN IP and MOTD in the dietpi-banner:

/boot/dietpi/func/obtain_network_details: line 143: /run/dietpi/.network: Permission denied
─────────────────────────────────────────────────────
DietPi v6.29.2 : 09:33 - Mon 04/05/20
─────────────────────────────────────────────────────

  • Device model : RPi 3 Model B+ (armv7l)
  • CPU temp : 51'C : 123'F (Running warm, but safe)
  • LAN IP : Use dietpi-config to setup a connection (eth0)
    /boot/dietpi/func/dietpi-banner: line 222: /run/dietpi/.dietpi_motd: Permission denied
    ─────────────────────────────────────────────────────

If I login as root there is no problem.

@Joulinar
Copy link
Collaborator

Joulinar commented May 4, 2020

similar was reported already #3505

@saschadd
Copy link

saschadd commented May 4, 2020

Move root-filesystem possibly not working correctly

i updated to DietPi v6.29.2 this morning as it showed up when i connected via ssh.
After that i rebooted and everything was working as expected.
Then i decided to move the rootfs back to the usbstick because my harddrive went crazy on saturday as it was constantly working. I couldnt find the source as the raspi3b+ was not reacting to anything (not even on the attached keyboard or mouse, i could see on the attached monitor that there has been 70% cpu 1 hour before i noticed the constant working of the harddrive) so i had to switch it off and back on. After rebooting everything it worked like before.
Back to the moving...
I decided to move / back to the usb pen drive as it worked like a charm when moving to the harddrive. Unfortunately now my rootfs always gets mounted ro.
I cant seem to read the error messages on boot because they run to fast and found no way to stop them (one message has blue background and white text). The raspi boots to dietpi and ssh is working but nothing else.
In dmesg are no errors shown and at the moment i dont know what to do or what the problem is.

@Joulinar
Copy link
Collaborator

Joulinar commented May 4, 2020

Hi,

if your stick is mounted ro, it might contain some corruption on it. It could happen that devices mounted ro to avoid further data loss/corruption. As well you could have a look to /etc/fstab what mount options are set

@saschadd
Copy link

saschadd commented May 4, 2020

fstab has no options for the rootfs

# Please use "dietpi-drive_manager" to setup mounts
#----------------------------------------------------------------
# NETWORK
#----------------------------------------------------------------


#----------------------------------------------------------------
# TMPFS
#----------------------------------------------------------------
tmpfs /tmp tmpfs size=342M,noatime,lazytime,nodev,nosuid,mode=1777
tmpfs /var/log tmpfs defaults,size=50m,noatime,nodev,nosuid,mode=1777 0 0

#----------------------------------------------------------------
# MISC: ecryptfs, vboxsf (VirtualBox shared folder), gluster, bind mounts
#----------------------------------------------------------------


#----------------------------------------------------------------
# SWAPFILE
#----------------------------------------------------------------


#----------------------------------------------------------------
# PHYSICAL DRIVES
#----------------------------------------------------------------
PARTUUID=cb7b86f7-01 /boot vfat noatime,lazytime,rw 0 2
#UUID=224fdfa9-23d0-4574-a20c-74284e61bada /mnt/224fdfa9-23d0-4574-a20c-74284e61bada ext4 noatime,lazytime,rw,nofail,noauto,x-systemd.automount

@Joulinar
Copy link
Collaborator

Joulinar commented May 4, 2020

can you run mount command and post the output pls

@saschadd
Copy link

saschadd commented May 4, 2020

sure
note: at the moment i switched root=PARTUUID= in /boot/cmdline.txt to the usb harddrive to test if the harddrive would boot correctly. The rootfs on the pendrive would be /dev/sda2 with UUID cb7b86f7-02 where /dev/sda1 is /boot with UUID cb7b86f7-01

/dev/sdb1 on / type ext4 (ro,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=345708k,nr_inodes=86427,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=38,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
configfs on /sys/kernel/config type configfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime,lazytime,size=350208k)
tmpfs on /var/log type tmpfs (rw,nosuid,nodev,noatime,size=51200k)
/dev/sda1 on /boot type vfat (rw,noatime,lazytime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=70060k,mode=700)
/dev/sda2 on /boot/tempmnt/root type ext4 (rw,relatime)

@Joulinar
Copy link
Collaborator

Joulinar commented May 4, 2020

your rootFS is located on /dev/sdb1 and it's mounted ro

/dev/sdb1 on / type ext4 (ro,relatime)

@saschadd
Copy link

saschadd commented May 4, 2020

thats correct, /dev/sdb1 is the rootfs on the usb harddrive /dev/sdb

as this might lead knowhere at the moment, is there a way to
a) stop or pause the bootup to have a chance to read the messages or
b) send the output at bootup to a logfile for viewing later or
c) a way to restore my rootfs or at least most of the settings from the backup made while doing the update (i cant find it anywhere : ( )

@MichaIng
Copy link
Owner Author

MichaIng commented May 4, 2020

@saschadd
After bootup, you can run journalctl to check kernel and systemd logs. But actually, since /etc/fstab simply does not contain the rootfs entry, it is expected that it is only mounted ro by cmdline.txt entry.

Can you please run dietpi-drive_manager. It should ask you to remount rootfs writable. Accept that and check if /dev/sdb1 is then correctly shown in the list to be mounted on /. Exit and check that the fstab entry has created as well.

Then retry to transfer RootFS to the pendrive. When it seems finished, it prints:

RootFS transfer has successfully completed.

A reboot is required, please press <return> to reboot now.

Please do not yet hit return, but open a second SSH session and check /etc/fstab if the new rootfs entry has been created as expected.
The following code line should replace the existing rootfs entry with the new one: https://github.com/MichaIng/DietPi/blob/master/dietpi/dietpi-drive_manager#L720

@saschadd
Copy link

saschadd commented May 4, 2020

Thanks to all replies and ideas on the issue but i think i can confirm that this is NOT an issue of dietpi.
I already took the short way and installed dietpi again from scratch to the pendrive and it works fine.
As soon as i attach the harddrive the reboot is hanging. So the external harddrive seems to have a problem. Unfortunately this crashes my idea of using an external usb disk with its own power supply. Is there a known issue with external hardrives with own power supply or do they have to be newer ones. The reason why i am asking is that the harddrive i used is maybe 10 years old but not often used since then so i decided to put it to good use as a data drive on the raspi. It is a Verbatim 1TB drive so not a maybe complicated NoName-Drive.
Anyway, the issue is solved and is not a problem of dietpi.

@Joulinar
Copy link
Collaborator

Joulinar commented May 4, 2020

well we have quite a larger number of users who use eternal HDD or SSD. Normally it's working fine, specially with external power supply. Usually issues happen if you did not use a power supply. Maybe the HDD has some defect? Probably you can run a consistency check

sudo apt-get install badblocks
sudo badblocks /dev/sdX

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Beta 🧪 Issues specific to the Beta branch testing Information ℹ️
Projects
None yet
Development

No branches or pull requests

6 participants