search

procount / pinn

An enhanced Operating System installer for the Raspberry Pi
1.15k stars 124 forks source link

[SOLVED] rebootp does not work within a pinn_init script when booting via USB #496

Closed jharris1993 closed 3 years ago

jharris1993 commented 3 years ago

Note: Tested using both 3.5.4 and 3.5.5

Issue: For whatever reason, a script that attempts to execute the "rebootp" (or rebootp xx to boot into a partition), is totally ineffective within the pinn_init script, however it works wonderfully within the rescue/command shell that runs after PINN has initialized.

It does not matter if it is back-ticked, given a full path, executed in a sub-process or sub-shell, it just does not work if executed prior to PINN.

procount commented 3 years ago

oh. That's a shame. I have no idea why not. In fact both pinn_init.sh and the rescueshell are both called from init BEFORE PINN is initialized. The only difference is pinn_init.sh is called by sh -c "/tmp/mnt/pinn_init.sh", whereas the rescueshell is just sh You'll have to go back to setting the "sticky-boot" setting instead then.

jharris1993 commented 3 years ago

Maybe I am using the wrong name?

What I am calling the “rescue shell” is the command-line interface entered when you hit either ALT-F2 or ALT-F3, AFTER PINN is fully alive.

There is apparently a different implementation, (or whatever) of a command shell that exists BEFORE PINN is fully alive that performs differently. Is it possible that the paths to various things are different during execution of the before-PINN shell?

PINN, during boot time, creates a diagnostic log. How do I create entries into that log? “loginfo ”? Is the /tmp directory writable by the shell during boot so that I can create my own log? Maybe I can try a “find” to see where the pre-boot shell thinks things are.

BTW, it appears that script errors in the pinn_init script do NOT get written to the diagnostic output file. With that said, where is the invocation of pinn_init kept? It would be great if I could modify the invocation of pinn_init to redirect output to stderr at invocation time (i.e. pinn_init.sh 2 > pinn_init.log)

From: procount @.*** Sent: Saturday, March 20, 2021 2:47 AM To: procount/pinn Cc: Jim (JR); Author Subject: Re: [procount/pinn] rebootp does not work within a pinn_init script (#496)

oh. That's a shame. I have no idea why not. In fact both pinn_init.sh and the rescueshell are both called from init BEFORE PINN is initialized. The only difference is pinn_init.sh is called by sh -c "/tmp/mnt/pinn_init.sh", whereas the rescueshell is just sh You'll have to go back to setting the "sticky-boot" setting instead then.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/procount/pinn/issues/496#issuecomment-803194790 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AC36Q5DIVJKGH3IVDEJ423DTEPO7HANCNFSM4ZPU4GIA . https://github.com/notifications/beacon/AC36Q5ERPKI45GATTYZYVKDTEPO7HA5CNFSM4ZPU4GIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOF7P4PJQ.gif

jharris1993 commented 3 years ago

Is it possible, and if so, how do I create a log file from within pinn_init?

I am trying to create a log "pinn_init.log" and I am trying to redirect 2>&1

In my pinn.init.sh script I have placed three lines: echo "This is the beginning" 2>&1 /tmp/settings/pin_init.log find -iname rebootp 2>&1 /tmp/settings/pin_init.log echo "this is the end" /tmp/settings/pin_init.log

When I enter the "rescue shell" I then execute a "find -iname pinn_init* and it returns /mnt/pinn_init.sh /mnt/pinn_init_new.sh which I know exist

I have also tried redirecting to /tmp itself.

How do I create a log?

procount commented 3 years ago

PINN creates /tmp/debug when it starts then appends to it. So anything you write to it before PINN starts, e.g. in pinn_init.sh will probably be obliterated. Choose another file, such as /tmp/log. But remember the /tmp folder is in RAM and will be lost on a reboot. Choose /settings/log if you want it available after a reboot, but don't let it fill the /settings partition.

Your redirection syntax is not correct. 2&>1 will redirect the stderr to stdout, but it doesn't redirect it to the given file. For that you need to do something like:

echo "This is the beginning" >>/tmp/pin_init.log 2>&1

I think the order of redirection is also important. (This is from google, I've not tried it myself yet)

Your example tried to redirect to /tmp/settings/pinn.log, but this will only work if the /tmp/settings folder exists, so you would need to create it first with mkdir. I had suggested using /settings, but I'm not sure if this is mounted already in pinn_init.sh. You would probably have to mount /dev/mmcblk0p5 onto /settings first, and umount it after use. I think it is only mounted when PINN starts.

procount commented 3 years ago

I finally found some time, and a free PINN installation, to test this out a bit.

You must be doing something wrong because I just created a simple script as follows that worked perfectly:

pinn_init.sh:

#!/bin/sh
rebootp 6

When booted, the rainbow square came up, then pinn_init rebooted into the first OS without going through PINN. So the problem must be in your script.

jharris1993 commented 3 years ago

Please retry with that line commented out to make sure there’s no sticky-boot or something else set.

From: procount @.*** Sent: Saturday, March 20, 2021 10:05 PM To: procount/pinn Cc: Jim (JR); Author Subject: Re: [procount/pinn] rebootp does not work within a pinn_init script (#496)

I finally found some time, and a free PINN installation, to test this out a bit.

You must be doing something wrong because I just created a simple script as follows that worked perfectly:

pinn_init.sh:

!/bin/sh

rebootp 6

When booted, the rainbow square came up, then pinn_init rebooted into the first OS without going through PINN. So the problem must be in your script.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/procount/pinn/issues/496#issuecomment-803446595 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AC36Q5ALRLAUOKU6AOLXDJ3TETWWRANCNFSM4ZPU4GIA . https://github.com/notifications/beacon/AC36Q5CLW5RA7GEZPJTV3WTTETWWRA5CNFSM4ZPU4GIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOF7RZ6QY.gif

procount commented 3 years ago

There isn't, because I have forcetrigger set, so if PINN loads, it will go straight to the menu

jharris1993 commented 3 years ago

Are you doing this from an external USB device, or a SD card in the Pi's SD slot?

I just duplicated your script exactly, (except I used rebootp 10) and it failed to work.

I am going to try again with a test SD card.

procount commented 3 years ago

I did it in an SD card. And I just commented out the rebootp command and and PINN started as normal.

jharris1993 commented 3 years ago

I've been working with an external SSD drive on one of my Pi-4's USB2 ports.

Which Pi are you using?

I am going to make a totally new installation of PINN on a 32 gig SD card, install a couple of things to it, and try it there. It would be intensely interesting if it failed because it was an external device. . .

My device is shown within PINN as a "Raspberry Pi 4 Model B Rev 1.1 with 4GB ram

procount commented 3 years ago

I just tried a USB boot on a 3B+ and it didn't reboot. Hmmm. OK something I need to investigate. I don't know why a USB boot should be different

jharris1993 commented 3 years ago

Whew!

At least I'm not going outta my mind. . . .

. . . but, with an SD card, I'm having a heck of a time with PINN itself. I install 3.5.4 and then update to 3.5.5 and it still LOOKS like 3.5.4 without the skull. . . Never had that happen with the USB attached SSD.

I like the SSD because it's fast as a thief and has OODLES of room for my project development and testing.

BTW, this is a Seagate Expansion 500gb SSD. I also have a Seagate One-Touch SSD of the same size, (they're sister drives for marketing purposes, I suppose), and Seagate is No Slouch in the mass storage market. They both behave the same way too. Just like yours.

Glad you found it.

I wonder if redirecting to a file fails on a USB device too? It never worked for me.

procount commented 3 years ago

My first feeling is that this is a timing issue. USB devices take longer to boot because they take longer to be detected. I think the device is not available when pinn_init.sh is being detected, so the script is not even being executed. I suggest you test on SD cards whilst I try to sort out the issue on USB devices.

jharris1993 commented 3 years ago

. . . .but I get a rainbow. . .

You don't get a rainbow on a Pi4 until the firmware is loaded from /RECOVERY - ergo the device MUST be mounted and available since there is no SD card installed.

procount commented 3 years ago

No that's not how it works. The firmware runs on the VC core, loads the firmware into memory ready to boot linux. But linux on the ARM still has to detect the drives. Because the boot drive is on USB, I am not waiting long enough for the drive to be detected on Linux.

jharris1993 commented 3 years ago

The bottom line here appears that, (except for use as a boot manager), PINN isn't useful on USB based devices as boot-scripts don't work.

Testing on SD cards works fine. Unfortunately my big SSD on a USB port is still not working (as expected) and it's seriously bashing my development efforts as I want to use Visual Studio Code connected directly to the target device. Doing this with a SD card is abysmally slow.

Absent this capability, I need to develop on my laptop, migrate the files to the robot using FileZilla, and then run them there. This created tremendous opportunities for files to get out of sync and makes a balls-up of my development.

I had the bright idea of adding a timing loop while attempting to mount /dev/sda on /settings just to know when things were ready, but I forgot that the darn device isn't even live. . . Errr!

I'm going to put the whole thing away until a solution is found as there is nothing more I can do.

lurch commented 3 years ago

PINN isn't useful on USB based devices ...

That's a bit of a bold claim...

as boot-scripts don't work.

...given that 99% of people probably don't use boot-scripts? :confused:

Doing this with a SD card is abysmally slow.

Does "boot-partition on SD card, root-partition on SSD" not work? (I've not experimented with PINN, bit I think I remember that being a supported option)

This created tremendous opportunities for files to get out of sync

You could try running rsync over SSH, instead of manually copying files using FileZilla? Much more reliable :)

jharris1993 commented 3 years ago

Lurch,

I am really resisting the temptation to make a snarky reply. . . .  So, instead, I will just reply to your points.  

PINN isn't useful on USB based devices ...

That's a bit of a bold claim...

as boot-scripts don't work.

...given that 99% of people probably don't use boot-scripts? 😕

So what? It's a specified and supported feature.  USB is a specified and supported environment.  Q.E.D. It is supposed to work.

That's the equivalent of saying that if 99% of the people don't use hazard flashers or the parking brake on their car - that it doesn't matter if it works or not?  Tell that to the car owner the next time he's stuck in the middle of the freeway or he needs to park on a hill.

Maybe that only happens one percent of the time, but during that one percent, it darn-well better work!

I already specified, (perhaps on the sticky, not here), that the only workable use-case for PINN on a USB device, (at least until procount fixes this), is if you don't need anything customized and are using a plain-vanilla PINN install as a boot-manager.  

Doing this with a SD card is abysmally slow.

Does "boot-partition on SD card, root-partition on SSD" not work? (I've not experimented with PINN, bit I think I remember that being a supported option)

That's not the problem.  As procount noted above, what is happening is that after the initial boot of PINN's basic kernel via the GPU, it takes a non-trivial amount of time for the kernel to enumerate and mount the USB devices.  PINN's boot sequence passes control to the rest of the boot process BEFORE the USB devices are enumerated - as he mentioned in a posting above.

Apparently the kernel boots, attempts to run the script on /mnt, but since /mnt isn't on-line yet, it can't, so it fails and continues the PINN boot which has to wait for the USB device to be enumerated before completing the "initializing" step.

Additionally, I am not sure even how to make that work.  As far as I have seen working with PINN, the device PINN is initially installed on is the one that gets reformatted and used as the boot-and-root media for all installed operating systems.

Lets even assume that this is both possible and that the script would run if the recovery and settings partitions are on a SD card and everything else is on my SSD.  We would still have the problem of PINN's kernel booting faster than the USB device, which is the crux of the entire problem.  

This create[s] tremendous opportunities for files to get out of sync

You could try running rsync over SSH, instead of manually copying files using FileZilla? Much more reliable :)

Since my main development environment is Visual Studio Code running within Wiin-10, rsync is a more complex option.  Instead, I can install a small utility on the target device, (my robot), and have VSC connect directly to it and run code from the VSC console directly on the robot itself instead of having to jump back and forth all the time.  Since the entire code-base resides, (again), directly on the robot itself and not on my laptop, I don't have to sync anything as it's already there.

That's even more "reliable" than either rsync or FileZilla, and is what I want to do.  Running a VSC "server" instance on a SD card is like trying to run a marathon through Jello - ergo my desire to use a SSD as my primary device.

Additionally, since the software I am working on has to work on three different platforms, (Raspbian for Robots, DexterOS, and the new GoPiGo O/S), I need to have the three of them available and I need to be able to choose between them fluidly.

I have a dip-switch arrangement that, along with my script and my specially customized config.txt file, allows me to switch-select the O/S I want to use at the next reboot - without needing to have a monitor attached, monkey around with a remote connection, or anything else.  In order to do what I want, in a fluid, flexible, and rapid manner, I want to do this with a SSD as the boot media.

Rather than trying to second-guess all of this, let's just allow procount to do what he can do, OK?

lurch commented 3 years ago

I am really resisting the temptation to make a snarky reply

I'm sorry if I caused any offence. It's just that I know that @procount puts an awful lot of work into PINN, entirely for free as a hobby-project, so to see someone state "The bottom line here appears that ... PINN isn't useful on USB based devices" felt a bit jarring (especially as it's only because of particular corner-case combination of features that @procount hadn't happened to test together). Maybe I over-reacted. Hugs? :hugs:

That's the equivalent of saying that if 99% of the people don't use hazard flashers or the parking brake on their car - that it doesn't matter if it works or not? Tell that to the car owner the next time he's stuck in the middle of the freeway or he needs to park on a hill.

I'd argue that hazard-lights or a parking-brake on a car are slightly more essential than PINN's boot-scripts feature :wink:

Lets even assume that this is both possible and that the script would run if the recovery and settings partitions are on a SD card and everything else is on my SSD. We would still have the problem of PINN's kernel booting faster than the USB device, which is the crux of the entire problem.

As mentioned before I've not experimented with PINN much, and never even looked at this "boot script" feature, but my assumption would be that the "boot script" would be on the boot partition (on the SD card) and so wouldn't suffer from the delay in waiting for USB devices to enumerate? And of course if the boot-script did need to access files on the root partition on the USB SSD, the script itself could do the necessary delaying.

That's even more "reliable" than either rsync or FileZilla, and is what I want to do. Running a VSC "server" instance on a SD card is like trying to run a marathon through Jello - ergo my desire to use a SSD as my primary device.

Neat! That background-context was missing from earlier comments. Just out of curiosity, are you sure it's only running from an SD card that's slowing down the "VSC server"? Maybe it's also network bandwidth or something? Apart from the initial startup, I'm not sure how disk-IO-intensive I'd expect VSCode to be? :shrug:

I have a dip-switch arrangement that, along with my script and my specially customized config.txt file, allows me to switch-select the O/S I want to use at the next reboot - without needing to have a monitor attached, monkey around with a remote connection, or anything else. In order to do what I want, in a fluid, flexible, and rapid manner, I want to do this with a SSD as the boot media.

Very cool. :robot: Reminds me of this NOOBS request: https://github.com/raspberrypi/noobs/issues/366 (and see also #375 )

Rather than trying to second-guess all of this, let's just allow procount to do what he can do, OK?

Agreed :+1:

jharris1993 commented 3 years ago

. . . .but I get a rainbow. . .

You don't get a rainbow on a Pi4 until the firmware is loaded from /RECOVERY - ergo the device MUST be mounted and available since there is no SD card installed.

According to procount, the boot process is, (in PINN's case), a THREE step process:

  1. The boot-loader logic in the GPU, (which is the boot-time processor), mounts and boots the boot partition, loads the PINN kernel, and kicks it up the bum to get it going.
  2. The PINN kernel creates its virtual (squashfs) filesystem and starts the ball rolling.  At this point, PINN's kernel has to boot and enumerate the USB device as a Linux device, as opposed to a device loaded by the Raspberry Pi's equivalent of a "int-13" BIOS call - which are two totally different things.  Supposedly this takes a considerably longer time than enumerating the SD card does.  After all, the SD card is the "native" boot method - the USB method requires some hoop-jumping.
  3. Once the USB device is fully enumerated, drivers loaded, and it's bound-and-mounted - it's then available for PINN, (and associated scripts), to use.

However, (apparently up to this point, at least), procount has fallen for the (not so obvious) fallacy that SD card == USB device as far as everything else is concerned.  I can't fault him, I've made that mistake more times than I can count too.

I do not want to second-guess him, but he is currently entertaining the idea that the USB enumeration process is orders-of-magnitude longer than the SD enumeration process.

Your idea of using a SD card as the boot media, playing the script THERE, and spinning on something, (like mounting /dev/sda5 on /settings), that won't be true until the USB device is active and on-line is a good one.  I actually tried that myself, (within the context of the USB device), but the script never even gets run because the device doesn't exist yet.

I don't know if USB enumeration takes place before or after the pinn_init script runs, and I don't want to guess.

If I wasn't up to "me arse" in US taxes, I'd take a stab at it just for S's and Giggles.  

I'm sorry if I caused any offence. It's just that I know that @procount puts an awful lot of work into PINN, entirely for free as a hobby-project, so to see someone state "The bottom line here appears that ... PINN isn't useful on USB based devices" felt a bit jarring (especially as it's only because of particular corner-case combination of features that @procount hadn't happened to test together). Maybe I over-reacted. Hugs?

Fair.  I can totally agree and I tend to be a bit dispassionate when discussing bugs.  Props for watching his back.

Procount himself has stated that I have managed - within the context of one single project to hit just about every edge-case and corner condition both in the software and in the documentation. :wink:

I have also taken care to make sure that EVERYONE knows how indebted I am to procount for his help getting this thing working.  Recently I even quoted an Army action report from the Pacific during WWII:

The bald statement "The Navy assisted in the action" is a masterpiece of understatement. Without the Navy there would have been NO action. . .

and the same is true for procount and PINN.  

are you sure it's only running from an SD card that's slowing down the "VSC server"? Maybe it's also network bandwidth or something? Apart from the initial startup, I'm not sure how disk-IO-intensive I'd expect VSCode to be?

Honestly, I cannot speak to that.  What I do know is that if run from an SD card, even a hugely expensive 128g A2 rated card, VS-Code runs considerably more slowly than if run in the exact same way from an SSD.  And I know the configuration is exactly the same because I PINN backup-and-restore copied the system from the SD to the SSD.

Re: The dip-switch arrangement.

I am surprised that nothing like this has ever come up before.  Surely I'm not the only one who has a headless device that needs to multi-boot?

jharris1993 commented 3 years ago

I have a dip-switch arrangement that, along with my script and my specially customized config.txt file, allows me to switch-select the O/S I want to use at the next reboot - without needing to have a monitor attached, monkey around with a remote connection, or anything else. In order to do what I want, in a fluid, flexible, and rapid manner, I want to do this with a SSD as the boot media.

Very cool. 🤖 Reminds me of this NOOBS request: raspberrypi/noobs#366 (and see also #375 )

I have updated the threads with a link to my scripts on the PINN sticky located here: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574&p=1843314#p1843314

. . . . to help people who may land there via a search-engine find what might be helpful. Hopefully they can use it.

It's currently a one-of-five selection using a five-position dip-switch, with the first "on" switch found selecting the O/S. If all are "off" - nothing selected - it falls through to the normal PINN boot process.

Feel free to play with it yourself and let me know what you think and/or comments and suggestions, etc.

Do you think that something like this could find a home on PINN's GitHub?

lurch commented 3 years ago

According to procount, the boot process is...

I'm the person who wrote https://github.com/raspberrypi/noobs/wiki/NOOBS-partitioning-explained :wink: (although that was long before the Raspberry Pi supported booting directly from USB.)

If I wasn't up to "me arse" in US taxes

Good luck :crossed_fingers: I managed to get my UK taxes finished off mid-January.

Procount himself has stated that I have managed - within the context of one single project to hit just about every edge-case and corner condition both in the software and in the documentation. :wink:

Haha, that's often the case when you're trying something "out of the ordinary". It's a great way of uncovering corner-case bugs like this! :laughing:

even a hugely expensive 128g A2 rated card, VS-Code runs considerably more slowly than if run in the exact same way from an SSD.

Hmmm, fair enough. Good to know that you've actually got "concrete evidence" rather than just "guessing" as some people seem to do :+1:

Re: The dip-switch arrangement. I am surprised that nothing like this has ever come up before. Surely I'm not the only one who has a headless device that needs to multi-boot?

Dunno. I know that people with media-centres often want to boot multiple OSes, and @procount has done a lot of work helping people to get PINN working with CEC remote-controls and USB joysticks. But I guess for headless devices, the Raspberry Pi is so cheap that it's probably easier to just buy multiple Pis and dedicate each Pi to a single purpose, rather than try to multiboot them? :shrug:

Feel free to play with it yourself and let me know what you think and/or comments and suggestions, etc.

I don't have time to play with it, but I did leave a suggestion on one of the issues you replied to.

lurch commented 3 years ago

I would say that "99% of the time people won't need anything that generalized" - but we've already seen that "99%" go down the tubes already. . . :laughing:

Touche! :rofl:

jharris1993 commented 3 years ago

I don't have time to play with it, but I did leave a suggestion on one of the issues you replied to.

Who has time for any of this?

I saw your comment and - as always - your advice is always good.

In My Own Humble Opinion. . . .

Given my choice between "generalized" and "easy to read and maintain", I go for "easy" even if it isn't very elegant.

In the full-bore script that both procount and I are working on, he implements some sed and awk stuff that makes my head spin!  The two of you gotta have a bigger pair than I got if you can make heads or tails out of that gibberish. . .

jharris1993 commented 3 years ago

I'm the person who wrote https://github.com/raspberrypi/noobs/wiki/NOOBS-partitioning-explained 😉 (although that was long before the Raspberry Pi supported booting directly from USB.)

There it says:

Creates a new small (32MB) ext4-format partition /dev/mmcblk0p3 at the end of the card, and labels it as 'SETTINGS'.

This is no longer true - at least as far a GParted knows - as it shows that partition at the beginning of the extended partition, (at least within the context of PINN 3.5.4 etc.)

lurch commented 3 years ago

https://github.com/raspberrypi/noobs/wiki/NOOBS-partitioning-explained#update-for-noobs-v15-and-later :stuck_out_tongue_winking_eye:

jharris1993 commented 3 years ago

This then 'reboots' the firmware and loads start.elf from the specified partition (typically /dev/mmcblk0p5 if only one OS is installed)

But only if it's a pre-1.5 version. 1.5 and later would be /dev/mmcblk0p6, right?

jharris1993 commented 3 years ago

There really should be a way to take a lot of this interesting, (but not necessarily relevant), discussion off-line. Unfortunately, I don’t know how to PM anyone on this list.

lurch commented 3 years ago

IMHO this discussion is interesting enough to keep on public GitHub, rather than moving to private channels. (but of course it's up to @procount as this is his repo!)

jharris1993 commented 3 years ago

IMHO this discussion is interesting enough to keep on public GitHub, rather than moving to private channels. (but of course it's up to @procount as this is his repo!)

Agreed.

I haven't really had the chance to "sit and talk", (and get to know you better), and I am thankful for the opportunity. It's just that I was thinking that it's wandering away from the main topic of the thread.

jharris1993 commented 3 years ago

My first feeling is that this is a timing issue. USB devices take longer to boot because they take longer to be detected. I think the device is not available when pinn_init.sh is being detected, so the script is not even being executed. I suggest you test on SD cards whilst I try to sort out the issue on USB devices.

Any progress on this?

Is there anything you're still waiting for from me?

I'm almost finished with my taxes and I am looking forward to jumping right back into this!

procount commented 3 years ago

Still experimenting, when my real world job doesn't get in the way.

jharris1993 commented 3 years ago

Still experimenting, when my real world job doesn't get in the way.

(laughing!)

Ain't that the truth!

procount commented 3 years ago

https://sourceforge.net/projects/pinn/files/testing/pinn-356.zip/download

Hopefully pinn_init.sh will now run on a USB booted version of PINN. In case you need it, I pass the boot drive to pinn_init.sh as the 1st parameter, so $1 will be /dev/sda1 or /dev/mmcblk0p1 If you want to reference the settings partition, you can get it as follows:

#!/bin/sh

setting_dev=${1%?}5
mount /setting_dev /settings
....
# Do what you want
...
umount /settings
procount commented 3 years ago

I consider this fixed now, but reopen if there are still issues.

jharris1993 commented 3 years ago

Still testing.  Been away all day.

Apr 7, 2021 9:07:18 PM procount @.***>:

I consider this fixed now, but reopen if there are still issues.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub[https://github.com/procount/pinn/issues/496#issuecomment-815116513], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AC36Q5EQKOZQQ3IEH7JSQWDTHSNNLANCNFSM4ZPU4GIA]. [data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAABHNCSVQICAgIfAhkiAAAAB9JREFUaIHtwQEBAAAAgiD/r25IQAEAAAAAAAAAAC8GJDAAAY7rwGcAAAAASUVORK5CYII=###24x24:true###][Tracking image][https://github.com/notifications/beacon/AC36Q5HXY43R3UCY5P4SQCLTHSNNLA5CNFSM4ZPU4GIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGCK3BYI.gif]

jharris1993 commented 3 years ago

There are two issues with the test zip as issued.

1.  Dependency folders are not included. The test will not boot without them. 2.  In a test file scenerio, please don't include the init command on the recovery command line since (I am assuming) that you want a simple drop-in test.

There is still some boot flakiness that I am still researching. Please don't close/release until I finish testing.

Note that I am NOT testing using a SD card. I am using an external SSD via USB only.

Also note that it appears to boot to some extent, but there may still be issues.

Summary: We're making huge progress, but may not be out of the woods yet.

Will advise.

Thanks!

Apr 7, 2021 9:07:18 PM procount @.***>:

I consider this fixed now, but reopen if there are still issues.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub[https://github.com/procount/pinn/issues/496#issuecomment-815116513], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AC36Q5EQKOZQQ3IEH7JSQWDTHSNNLANCNFSM4ZPU4GIA]. [data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAABHNCSVQICAgIfAhkiAAAAB9JREFUaIHtwQEBAAAAgiD/r25IQAEAAAAAAAAAAC8GJDAAAY7rwGcAAAAASUVORK5CYII=###24x24:true###][Tracking image][https://github.com/notifications/beacon/AC36Q5HXY43R3UCY5P4SQCLTHSNNLA5CNFSM4ZPU4GIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGCK3BYI.gif]

procount commented 3 years ago
  1. Which dependency folders?
  2. Without the init command it won't boot. A drop-in test is surely just to add a pinn_init.sh script :confused:
lurch commented 3 years ago
  1. I suspect @jharris1993 might have been referring to the runinstaller option?
jharris1993 commented 3 years ago

All of them.

Look in the 3.5.5 zip and notice that there are several folders with stuff.

I believe the first command in the recovery command line file is something like runinit that forces a total nuke-and-rebuild.

Drop-in replacement = unpack the zip file into the RECOVERY directory replacing everything there, since I don't know what was specifically changed.

In my case, I totally cleared the directory and then put your files in place.  No boot.

Then I copied the folders back. No boot.

Then I erased everything and copied my zipped-up archive of the original directory contents back. It booted.

Then I copied your files overtop of mine and almost nuked my system back to the stone-age.  It boots

It boots but there may still be issues.

I need to research and discover if the issues are with your update or my script.

One thing I noticed when compared to a straight-up SSD boot without PINN - it takes an extremely long time to boot.

I think you set a hugely long timer that is guaranteed to be enough time.

Is it possible to periodically poll for completion instead of waiting something like 30 seconds or so?  Surely the SSD doesn't take that long to come on-line as it never takes that long in a non-pinn environment.

Apr 7, 2021 9:35:55 PM procount @.***>:

jharris1993 commented 3 years ago

Correct. My e-mail and my robot are on different systems with different monitors and when I switch between them I have to try and remember - which doesn't always work. 😉

Apr 7, 2021 9:51:20 PM Andrew Scheller @.***>:

procount commented 3 years ago

Ah sorry, although I put it in the testing folder, it's a complete pinn-lite.zip "install" file, not a drop-in replacement just for testing. I should have been more specific, but always good to check for the runinstaller option

By "folders of stuff" do you mean the raspberry Pi OS & LibreELEC installation files in /os? Those are not included in the lite version. Otherwise all the same files seem to be in 3.5.6 compared to 3.5.5.

The extremely long time to boot is a feature of the firmware and your SSD rather than anything in PINN. Try the same installation of PINN on an SD card to see the difference.

  1. USB devices seems to take longer to be detected.
  2. The PI firmware has more things to check before it finds your OS to boot (PINN). If you are booting off SSD all the time, try changing the boot order so that it looks at USB first before the SD card. It might not save too much time though.
  3. The only difference in 3.5.6 is now I wait until the USB/SSD device is available in an endless loop. There is no timeout, so as soon as it is found, the pinn_init.sh script is executed followed by PINN itself. This code to detect the boot drive is just moved from within PINN to the /init script, so it shouldn't really take that much longer to get to the menu than before. The speed of your SSD being detected is the limiting factor. The only thing I can think of is to perhaps put a small sleep in my loop to allow the system to spend more time looking for the drive. But USB booting has always been slower than SD card booting. A small price to pay for better subsequent performance. I only tested it with an SD card in a USB/SD card adaptor. From pressing ctrl-alt-del to affect a reboot within PINN on a PI400, it took 8 secs to get the rainbow screen and 18 secs before the cursor showed up in its little green square.
jharris1993 commented 3 years ago

It's getting really late here and I'm making stupid mistakes. Continued tomorrow when I'm more awake.

lurch commented 3 years ago

The only thing I can think of is to perhaps put a small sleep in my loop to allow the system to spend more time looking for the drive.

I guess in theory if your loop has no delays, it could be sucking up all the CPU performance, leaving no time "left over" for USB enumeration. But given that the Pi4 has a quad-core CPU, even the "greediest" code should only tie up one core, leaving Linux free to use the other 3 cores for other tasks? :man_shrugging:

and 18 secs before the cursor showed up in its little green square.

That's still much quicker than my Amiga 500+ used to take to load Workbench off a floppy disk :laughing:

procount commented 3 years ago

I put a sleep 1 statement in my loop and tried the same SD card in the SD card slot, and in a USB adaptor in the USB port. Both took about the same time as above.

I remember booting GEM off my twin floppy Amstrad PC1512. Now that took a while. Upgrading to a 20MB hard disk was a revelation.

jharris1993 commented 3 years ago

Testing on my 500 gb USB SSD drive:

Issue: Assume the user wants to specifically control the order of the O/S's, or wants to come back and install something later.

If I select one O/S to install, and several project spaces, once the first O/S installs and I hit "OK", it immediately boots into the first O/S without returning to PINN. Subsequent boots boot directly into the installed O/S without pausing for PINN to launch. The only way for me to return to PINN is to add "forcetrigger" to the command line, (I don't have access to the GPIO jumpers.)

Once a second O/S is installed, completion of the install process returns to PINN normally.

Previous versions allowed to install one O/S and several project spaces and when the O/S install was finished it would return to PINN.

Expected behavior is for the install O/S process to return to PINN when complete instead of booting directly into the installed O/S.

Suggested behavior: If PINN is installed with one O/S and at least one Project Space, it should still offer the option of booting to PINN.

Note that in my case this is especially important as it is necessary for me to absolutely control the order of the installation of the operating systems. The only way to control the installation order is to install them one-at-a-time, initially reserving enough project spaces for all the O/S's I want to install.

jharris1993 commented 3 years ago

Issue: PINN does not request WiFi credentials at first boot.

Previous versions of PINN have always insisted on setting up WiFi on first boot. The 3.5.6 version does not.

I am flagging this because it is an undocumented change in behavior, though IMHO I like it that way.

However, other users who depend entirely on downloaded O/S's may find this new behavior jarring and may wonder where the downloaded O/S's went.

procount commented 3 years ago

Expected behavior is for the install O/S process to return to PINN when complete instead of booting directly into the installed O/S.

PINN inherited this behaviour from NOOBS and AFAICR it has not changed. If you just installed 1 bootable OS, PINN will boot it immediately. More than 1 and it returns to PINN (presumably because you need to select which one to boot)

procount commented 3 years ago

PINN does not request WiFi credentials at first boot.

This behaviour has not changed. It depends on certain conditions, particularly whether it can get a list of OSes. I think you are only prompted if it can't get a list of installable OSes. If you have ethernet connected, or some OS install files on the SD card or on USB, then it probably won't ask and you have to do it manually (inherited behaviour from NOOBS)

jharris1993 commented 3 years ago

PINN inherited this behaviour from NOOBS and AFAICR it has not changed. If you just installed 1 bootable OS, PINN will boot it immediately. More than 1 and it returns to PINN (presumably because you need to select which one to boot)

"AFAICR" - at least when I was experimenting with 3.5.4, installing a single O/S and several placeholder partitions always returned.

I would beg to suggest that this is the desirable behavior, especially of placeholder partitions exist when doing the initial config.

PINN does not request WiFi credentials at first boot.

This behaviour has not changed. It depends on certain conditions, particularly whether it can get a list of OSes. I think you are only prompted if it can't get a list of installable OSes.

Again, within the scope of my memory with 3.5.4, I have had an SD/USB thumb-drive with installable OS's on it and in-place and not wanting to mess with the WiFi stuff - and the huge list of installable OS's on-line - I deliberately SKIPPED WiFi config.

I don't know and, no, I have not gone back and tried to reproduce this with an earlier version. Maybe I'm loosing my mind?

All I know is what I remember and I remember these behaviors being different.