forum.pistar.uk

Can the 4.3 version be burned to a USB drive and then used as a boot drive on a pi?

PA5WIL wrote: ↑Fri Feb 09, 2024 12:23 pm wifi configuration is not working

Probably better now, I just worked up a fix for the crda data.

K4CQO wrote: ↑Fri Feb 09, 2024 8:46 pm Can the 4.3 version be burned to a USB drive and then used as a boot drive on a pi?

Not sure, never been interested in doing so.

raspberry pi Zero W rev 1.1, fw v1.6.1, dashboard 40206

4.3.0, booting image, it seems like it is hung after first reboot. I waited almost 5 minutes. it was acting like it was hung.
So I clicked dashboard and it went to dashboard with the warning message about modem selection needs to be update.
I then clicked on configuration again and the configuration blocks opened up. After that any time I did "apply changes"
to any section it would reboot and show me the main configuration again.

This problem happened on two different pi Zero W rev 1.1, fw v1.6.1, dashboard 40206.

Make that three pi zero w r 1.1

Pressing apply in the config page always has just applied the changes and re-loaded the config page - not sure I follow this one.

MW0MWZ wrote: ↑Fri Feb 09, 2024 10:49 pm

K4CQO wrote: ↑Fri Feb 09, 2024 8:46 pm Can the 4.3 version be burned to a USB drive and then used as a boot drive on a pi?

Not sure, never been interested in doing so.

SD cards are become harder to come by, especially in small sizes: a 32gb USB drive can be had for the same price as an 8gb SD card, for instance. USB's are faster, way faster than SD cards, longer lasting, and considerably more rugged, incorruptible. And given that more and more folks are moving beyond these two devices to SSD's (hard drives, M2 memories, etc), it would seem to make sense to consider updating to the standard boot mechanism now in use by all the Pi Foundation opsys offerings.

Only three changes are required to support a more generalized boot specs using the PARTUUID parameter rathar than a specific device name: the cmdline.txt file, the file sytem table (FSTAB) and the bash.bashrc file, all one line changes. The changes are backward compatible (they work for Jessie, Buster, Bullseye as well as Bookworm) and can be "slipped streamed" onto working systems via some strategically placed edits in the pistar-update and pistar-upgrade scripts (for older, existing versions) as well as being embedded in the current downloadable images.

Dare I say? These changes will still work on SD cards! But with this change, one can burn to a USB or SSD or M2 memory directly be up and running same as before.

KN2TOD wrote: ↑Sat Feb 10, 2024 12:39 am Only three changes are required to support a more generalized boot specs using the PARTUUID parameter rathar than a specific device name: the cmdline.txt file, the file sytem table (FSTAB) and the bash.bashrc file, all one line changes. The changes are backward compatible (they work for Jessie, Buster, Bullseye as well as Bookworm) and can be "slipped streamed" onto working systems via some strategically placed edits in the pistar-update and pistar-upgrade scripts (for older, existing versions) as well as being embedded in the current downloadable images.

Dare I say? These changes will still work on SD cards! But with this change, one can burn to a USB or SSD or M2 memory directly be up and running same as before.

Those are not compatible with my current build process tho, but coming in PS5 the build process is very different, and DOES work that way - but hell that's been in the works forever, don't hold your breath, I know I got a lot done lately, but still a ways to go yet.

I've tested 4.3.0 Beta on my generic (Chinese) Pi Zero W-based simplex hotspot using two different SD cards and two different downloads of the image, one from just a few minutes ago.. It always hangs at the "Stopping services and applying your configuration changes..." screen whenever I click an Apply button after making any configuration changes. The last few lines of /var/log/pi-star/MMDVM-2024-02-08.log are:

M: 2024-02-08 19:11:54.065 Mode set to Idle
I: 2024-02-08 19:11:54.065 Closing network connections
M: 2024-02-08 19:11:54.065 Closing YSF network connection
M: 2024-02-08 19:11:54.065 Closing POCSAG network connection
I: 2024-02-08 19:11:54.065 Stopping protocol handlers
I: 2024-02-08 19:11:54.065 MMDVMHost-20240126_PS4 has stopped
M: 2024-02-08 19:11:54.065 Closing the MMDVM
I: 2024-02-08 19:11:54.189 MMDVMHost-20240126_PS4 exited on receipt of SIGTERM

The OLED display shows OFFLINE . This sounds like almost the same issue that KA1PIT is having only his hotspot reboots while mine seems to shut down when we apply our configuration changes. BTW Pi-Star 4.20 works fine on this hotspot.

Platform: Raspberry Pi Zero W Rev 1.1
Modem: STM32-DVM / MMDVM_HS - Raspberry Pi Hat (GPIO)
Firmware: HS_Hat v1.6.1

Let me know if there's any more information you need.

Edit: to clarify, the OS is still running as is the Pi-Star web interface, it's just all of the Pi-Star services (YSF, DNR, etc.) that are shut down and never restart. Also, when this happens I lose the selected Radio/Modem type and am unable to reselect it because I can never apply my change.

Backup is not a zip file. All the file are in a map. I make a zip file from that map, but restore is gives failure,

PA5WIL wrote: ↑Sat Feb 10, 2024 11:18 am Backup is not a zip file. All the file are in a map. I make a zip file from that map, but restore is gives failure,

Backup file is a map? Just exported the config from a 4.3.0 build and I get the expected Zip file output.