new install

[jamesc2151]

Couple of issues but have a feeling they all come from PINN install..... loaded up running current ditro 64 bit on PI3b from pin all updates and wizards where an unexpected and nice touch but here's where the trouble begins..

Loaded webmin, phpmyadmin, Ampache, MariaDB MPD and Apache..
1) No site config sent to apache to load... fixed with webmin after I found where you hide the pubic dir created new port.

2) No site config sent to apache to load--fixed with webmin after I found where you hide the pubic dir created new port. Found DB for ampache out of date .. Ampache would not web update.. Used CLI and DB crashed..

3) removed MariaDB but wouldn't uninstall with Bad main DB as wizard kept trying to start service.. Did Override and only executed systemctl part of command as systemctl restart MariaDB would not run. Wizard finished. ok

4) decided to test if it was some sorta package deal... Removed the rest of the packages ok..

5) Loaded Ampache only.... it loaded MariaDB PHP7 and ampache..... NO WEB SERVER...??????

6) unloaded all again.. Tried this time to load Nginx then Ampache... No LINK to Sites.. Normally run Apache..

7) Like the distro and wizards and the fact that it's bloat free... But still needs a lot of connections to properly connect everything together. This is not a Bug report just my findings with your distro.. Going back to STD Raspberry OS for now. let me know if you need anymore details and if you would like me to try it again.. MY pi's are my toys and I reconfigure them all the time..

OH this is also a booted SSD Hardirve running pinn so if that's what's killing it I understand as it creates a middle layer partition that's know to blow up but other images are loading fine for now.. Did note a few times on reboot you distro lost network connection ability but switch out to another image and back corrected it.. GOOD JOB GUYS..

I'm not complaining just reporting to help out. Hoping to Migrate all this to my P4 but it's working fine and the 3 raspberry p3' i have are to find software to migrate to it. Not impress with Raspberry bookwork or prior release they killed my SPI TFT ability for Frame buffering.

[MichaIng]

1. Yes that is intended. For web applications which use their own web server, available via dietpi-software, no proxy is setup OOTB. You can install and use webmin hence without Apache and access it at port 10000. Compare with our docs: https://dietpi.com/docs/software/system_stats/#webmin
2. Indeed, something we need to address. First reported here: https://dietpi.com/forum/t/bypassing-ampache-update-page/17367 The database crash/corruption is however unexpected. Whatever the Ampache CLI does, it should not destroy the database or even its own table, of course. Makes sense to check the actual error logs, probably it was even an I/O error caused by the kernel/low voltage or any such, not directly related to Ampache.
3. Right, it tries to do a backup. Honestly, I think that is not even a bad thing, as it generally makes sense to investigate database or in case filesystem corruption, to know where it was coming from. But we should probably add an option to skip the backup (and hence the database service start).
4. Also uninstall the related software title via dietpi-software, to have it removed cleanly. If the MariaDB packages were manually removed, then the backup (> service start which failed previously) will be skipped.
5. Ampache does pull a webserver as strict dependency. Are you sure Apache is not installed anymore? Ah, or did you manually purge it via apt instead of via dietpi-software?
6. Not sure if I understand. What do you mean with "no link to sites"? And is Apache still installed or not? Or course you can only run a single webserver, as another one cannot bind to the same network port, hence fails to start.

With PINN you mean this? https://github.com/procount/pinn As long as it does flash the final OS image without manipulation to a different drive, that should be fine. If it does anything different than the result if you just flash our image directly, then it is definitely worth to try it without PINN and see whether it makes a difference. Not sure what you mean with "middle layer partition". If it is some kind of multi-boot system, i.e. ships boot config and kernel and loads only the userland of the installed OS (basically like BerryBoot), then this is not gonna work: DietPi relies on kernel, bootloader and boot configs being available to it on the FAT partition we ship with our images. If this is not the case, several config and install options won't work, as the intended boot config/overlay changes cannot be applied, and also kernel image may not match kernel modules, and much more. That would be certainly a reason for various bugs, not necessarily, but possibly including drive related ones, I/O errors etc.

[jamesc2151]

Yea PINN loaded it up for me same drive 2tbyte drive . When I say middle drive I meant PINN's loader (or Noobs) uses a partition it creates in the middle of your drive based on size not sure why perhaps other images need the bare root of the drive.. I noted this along time ago with NOObs when trying to clone a SD card over to a SSD drive... It would clone but never USB boot because the boot partition was a middle partition so some default boot stuff that I could never figure out wouldn't load.. When I get a chance I'll load you OS up on a standalone SD and see what it does .. But like the looks of your OS . It's just that i'm use to the old Raspberry file system and will have to figure out your file system that load stuff to the MNT folder and how you piecing the apps them around in the file system. But learning is fun.. I'm and old school SYSOP... and stubborn. Know what a sysop is ( Hint.. BBS systems before the internet.) no chaeting and google it.. We had to RTFM back then lol

[MichaIng]

Hmm, that is strange indeed. The RPi strictly requires its bootloader and boot config on the first partition, which must be formatted with FAT filesystem. The rootfs is hence always at least the 2nd partition. Is it possibly so that, with PINN, the first partition is still FAT and contains bootloader and boot config, but not the ones from the flashed image, instead the ones from PINN itself? I am honestly not sure how NOOBs worked, just remember that it was a GUI booted from the RPi itself to flash other distros from. But Raspberry Pi Ltd itself has abandoned NOOBs a while ago (in favour of rpi-imager), so there are no reference images to check. In any case, as long as the 1st partition of the final system drive is not the 1st partition form our image, this is not gonna work well.

It's just that i'm use to the old Raspberry file system and will have to figure out your file system that load stuff to the MNT folder and how you piecing the apps them around in the file system.

You mean our directory structure. But this has nothing to do with partitioning, filesystem NOOBs or any such, as this is all done withing the rootfs (unless you mount /mnt/dietpi_userdata from an external drive e.g. via dietpi-drive_manager). And it is only used for some software options in dietpi-software to store data and configs in a central place.

[MichaIng]

Ampache access issue will be fixed with: #6782

[jamesc2151]

Cool. But for me to migrate Ampache it's not going to be as simple as it once was by renaming it's directory in WWW and laying down a new nightly build of it in a fresh dir for testing.. It's going to take me a little bit as it looks like you put it's file systems files in WWW and well and /mnt/dietpi_userdata , I'll have to figure out what to move and what not to move.. but that's the fun of playing with PI's for me.. SYSOP System Operator of a BBS Bulletin Board system back in he days of modems.. Way before the internet.. Fido-net and Compu-serve and AOL

[MichaIng]

But for me to migrate Ampache it's not going to be as simple as it once was

I thought it is a fresh installation? However, not sure what you want to migrate, a reinstall will do everything for you, preserving config, data and database, but replacing all Ampache scripts. From Bullseye (Ampache v5) on, all files are located below /mnt/dietpi_userdata/ampache. /var/www/ampache is only a symlink to the /mnt/dietpi_userdata/ampache/public directory, which is the only one intended to be served by the webserver. This is a change introduced with Ampache v5, to enhance security, but having all config files, CLI scripts and internally loaded libraries and such outside of the webroot.

I'll have to figure out what to move and what not to move..

Move where with which intention? Generally, if you want to migrate stuff to a different system/hardware, copy the whole /mnt/dietpi_userdata over. Additionally, to be safe just in case, do a full database dump:

mysqldump -A > /mnt/dietpi_userdata/database_backup.sql

On "fresh" software installs on the new system, the content in /mnt/dietpi_userdata, which includes the database and Ampache configs, will be migrated. But in case of Webmin, data is stored elsewhere, /etc/webmin and /var/lib/webmin probably.

[jamesc2151]

The Migration would be moving all my current Raspberry installed data over to dietpi.. thus needing to learn your file system layout. Like I stated before I like how light weight Dietpi is and is not locked to dedicated use like OSMC and the like.. Nor does it appear to be bloated with things I don't need but still have the ability to add them if I need to.....

Still paying and experimenting and enjoying it all Thanks for the info...

On Mon, Nov 27, 2023 at 1:41 PM MichaIng @.***> wrote:

But for me to migrate Ampache it's not going to be as simple as it once was

I thought it is a fresh installation? However, not sure what you want to migrate, a reinstall will do everything for you, preserving config, data and database, but replacing all Ampache scripts. From Bullseye (Ampache v5) on, all files are located below /mnt/dietpi_userdata/ampache. /var/www/ampache is only a symlink to the /mnt/dietpi_userdata/ampache/public directory, which is the only one intended to be served by the webserver. This is a change introduced with Ampache v5, to enhance security, but having all config files, CLI scripts and internally loaded libraries and such outside of the webroot.

I'll have to figure out what to move and what not to move..

Move where with which intention? Generally, if you want to migrate stuff to a different system/hardware, copy the whole /mnt/dietpi_userdata over. Additionally, to be safe just in case, do a full database dump:

mysqldump -A > /mnt/dietpi_userdata/database_backup.sql

On "fresh" software installs on the new system, the content in /mnt/dietpi_userdata, which includes the database and Ampache configs, will be migrated. But in case of Webmin, data is stored elsewhere, /etc/webmin and /var/lib/webmin probably.

— Reply to this email directly, view it on GitHub https://github.com/MichaIng/DietPi/issues/6781#issuecomment-1828412416, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGGJG4IL22YEEOQ2LYDDBYDYGTNHHAVCNFSM6AAAAAA72ZAXAOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRYGQYTENBRGY . You are receiving this because you authored the thread.Message ID: @.***>

[MichaIng]

Understood. If you are using Ampache v5 or v6 at those other systems, it should be possible to copy it to /mnt/dietpi_userdata/ampache on the DietPi system, before installing Ampache there.

For the database it would be:

1. Create a database dump on the origin system, like mysqldump ampache > ampache.sql
2. Install only MariaDB on the DietPi system, and import it there: mysql ampache < ampache.sql
3. Create the database user with name and password matching the ones in ampache.cfg.php, like:

   mysql -e "grant all privileges on \`ampache\`.* to 'ampache'@localhost identified by 'password';flush privileges"

   With database and username both being ampache and the password password.

Then install Ampache on DietPi, which will migrate/use the old configs and database. That should btw work already now, as the issue you faced was only due to the too old database template we used. If yours is newer, it should be upgraded successfully when accessing the web UI after the installation.

[jamesc2151]

1) Been using Webmin for a long time... use it for Apache2 and drive setups 2) I do believe you're right about the voltage issues noted a drop here recently with that adapter. It's only 6 yrs old or older :) 3) As for the database backup. I have a dedicated Raspberry doing all my database stuff. Those were just things I noted on my first use of dietpi. but since I store over 20000 songs in my database and ampache by default takes forever to make a catalog (of which I use their CLI to do) nomail users should get that option. 4) pretty sure I removed all of ampache, phpmyadmin and Apache2 via Dietpi-software on lst run as I left Apache2 and removed the sites only once and them loaded just ampache and discovered (5 below) which I created with webmin. (Also noted that your not using PHP8 yet ;??? ) 5) no links to site IE no sited default configs listed in etc/Apache2 for the sites created ....Ampache and phpmyadmin.

On Sun, Nov 26, 2023 at 8:59 AM MichaIng @.***> wrote:

1. Yes that is intended. For web applications which use their own web server, available via dietpi-software, no proxy is setup OOTB. You can install and use webmin hence without Apache and access it at port
2. Compare with our docs: https://dietpi.com/docs/software/system_stats/#webmin
3. Indeed, something we need to address. First reported here: https://dietpi.com/forum/t/bypassing-ampache-update-page/17367 The database crash/corruption is however unexpected. Whatever the Ampache CLI does, it should not destroy the database or even its own table, of course. Makes sense to check the actual error logs, probably it was even an I/O error caused by the kernel/low voltage or any such, not directly related to Ampache.
4. Right, it tries to do a backup. Honestly, I think that is not even a bad thing, as it generally makes sense to investigate database or in case filesystem corruption, to know where it was coming from. But we should probably add an option to skip the backup (and hence the database service start).
5. Ampache does pull a webserver as strict dependency. Are you sure Apache is not installed anymore? Ah, or did you manually purge it via apt instead of via dietpi-software?
6. Not sure if I understand. What do you mean with "no link to sites"? And is Apache still installed or not? Or course you can only run a single webserver, as another one cannot bind to the same network port, hence fails to start.

With PINN you mean this? https://github.com/procount/pinn As long as it does flash the final OS image without manipulation to a different drive, that should be fine. If it does anything different than the result if you just flash our image directly, then it is definitely worth to try it without PINN and see whether it makes a difference. Not sure what you mean with "middle layer partition". If it is some kind of multi-boot system, i.e. ships boot config and kernel and loads only the userland of the installed OS (basically like BerryBoot), then this is not gonna work: DietPi relies on kernel, bootlaoder and boot configs being available to it on the FAT partition we ship with our images. If this is not the case, several config and install options won't work, as the intended boot config/overlay changes cannot be applied, and also kernel image may not match kernel modules, and much more. That would be certainly a reason for various bugs, not necessarily, but possibly including drive related ones, I/O errors etc.

— Reply to this email directly, view it on GitHub https://github.com/MichaIng/DietPi/issues/6781#issuecomment-1826791873, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGGJG4J7FIL4BAPZKTOJH2LYGNDMNAVCNFSM6AAAAAA72ZAXAOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRWG44TCOBXGM . You are receiving this because you authored the thread.Message ID: @.***>

[Joulinar]

Also noted that your not using PHP8 yet ;???

PHP8 is used on Debian Bookworm systems by default. On Debian Bullseye, we use PHP7.4 as it's Debian default on this oldstable Debian version. We don't use a 3rd party PHP repository.

[jamesc2151]

Update,,,Did a fresh install after i found the Power supply issue.. 1) installed Ampache and sure enough it loaded up apache2 and Mariadb no problems.... 2) still had the database update issue so I thought humm they include the SQL file to import with each version . 3) loaded up PHPmy admin...and webmin.. No problems.. Had to create a remote login account as @.*** host doesn't login via web 4) ran SQL script via PHPmyadmin.. 5) no login account in DB for Ampache.. Hummm lets run ampache install.php and have it reload the DB and create the User account.. 6) no go ... No write permissions to write over config.. and no ampache.cfg.php.dist to copy defaults from.. NP got a copy.. 7) working now but still getting nagged about config file being out of date??? But it's working and Loading up my catalog now..Gona be awhile as I have over 2400 albums.. but will keep you updated. Hope all this helps you somehow.. JC

On Tue, Nov 28, 2023 at 1:43 PM Joulinar @.***> wrote:

Also noted that your not using PHP8 yet ;???

PHP8 is used on Debian Bookworm systems by default. On Debian Bullseye, we use PHP7.4 as it's Debian default on this oldstable Debian version. We don't use a 3rd party PHP repository.

— Reply to this email directly, view it on GitHub https://github.com/MichaIng/DietPi/issues/6781#issuecomment-1830470734, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGGJG4KDD6DPXOO66XHG3ETYGYWFPAVCNFSM6AAAAAA72ZAXAOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZQGQ3TANZTGQ . You are receiving this because you authored the thread.Message ID: @.***>

[MichaIng]

DietPi v8.25 (released yesterday night) resolved the Ampache config file issue. The ampache.cfg.php.dist is now left in place as well. The www-data user has write access to the two config files ampache.cfg.php.dist and ampache.cfg.php, so re-running install.php should work, but is not required anymore.

[jamesc2151]

Cool beans But I've got it running great now and is my main living room OS. Loaded up the latest eversion of Raspberry 64 bit and not at all happy with it they have systemically removed some of the old legacy I2C functions and GPIO controls I use for OLED and SPI TFT displays and having to reconfigure them. Not to mention they have gotten rid of system log and crammed it all into the journal log so I have to scan for errors in a new format now... Thinking seriously of going back to a 32 bit release of your Build prior to buster as my Main Raspberry OS... Any thoughts.....

[MichaIng]

Logs in journal make it actually much easier, e.g. to check for webserver logs:

journalctl -u apache2

The practical benefit is that the output of the binary is there as well as the output of the wrapping service unit. With plain text file log, you always needed to check both to get the full picture, since an issue could have prevented Apache from even getting into a stage where it is able to log anything. The journal/system additionally catches signals and exit codes, and of course contains any possible error with the systemd unit itself or related settings. However, of course it means to change automatisms.

Using ancient/unsupported distro versions is not only a security issue, but also means that you cannot use the software you want to use: E.g. Ampache v6 requires PHP 8.x, which is only provided by Debian Bookworm and above.

So I can only recommend to adapt to the changes modern distros, software and hardware interfaces bring. Change is natural, regardless whether we like it or not 😉.

[jamesc2151]

Ture that Change is change and at 59 I've seen more than my share LOL .. My problem tho is I have I2C device that the bus is reporting an error on which is not actually and error and I could pipe it to a null log and not worry it now it's giving me an error I'm not able to fix trying to write the bus info.. So they must have change something else too.. But again.. I'm liven and learning and moving on..

Thanks for the info.. Have you tried to put a TFT spi device and your 64 bit build .... ??

James

[MichaIng]

I do not own LCD/SPI/DSI displays to test with, and have limited experience about setting them up. If there is an overlay shipped with the kernel as listed in /boot/overlays/ and /boot/overlays/README, then I'd expect it to work.

Generally, with older setup scripts or guides shipped by LCD vendors, they might expect the legacy GPU stack to work, i.e. no KMS but the framebuffer driver. So check whether there is a dtoverlay=vc4-* line in /boot/config.txt, and in case try to remove/comment it (and reboot), to see whether this changes things.

And there is at least one overlay (Allo Boss2) which broke with Linux 6.1 and is not maintained by its vendor company, since they seem to have shut down. In this particular case it seems to have been fixed with recent kernel releases. But RPi changed the packaging and boot mount structure, which we just started to test support for: https://github.com/MichaIng/DietPi/issues/6676 So you could test migrating to the new kernel packages using this script, and see whether this makes a difference.

[jamesc2151]

yea I use the mini Oleds on I2c buss to show Stats and one to watch MPD while it's streaming. The 3.5 SPI was a pain and they are dropping support or Frame buffer to the Wayland support and I get it but I finally got a compatible overlay to work after I compiled it on the system to run in place of the HDMI outputs. I know I'm side tracking you in your current objectives so if you need to close this as totally unrelated now I understand ... But thanks for all the info some of it has helped and I hope visa versa. but if you want to play with TTF on day let me know.. I'm about ready now to migrate all my learning over to your OS and see how everything gets along on the GPIO controls and frame buffering.. will let you know..

OHH yea While getting this all to work I've noted Raspberry is moving some of their video overrides (legacy stuff like frames)0 to be made in the cmdline.txt file

JC

[MichaIng]

Okay, I'm closing this issue. Feel free to open a new issue regarding the SPI/LCD topic.