MX-23 Raspberry Pi comes out of the garage

[Bouffski]

To be more concrete: mouse in USB2 port...

[Jerry3904]

Good. We only have one Pi 5, mine, so might PM you if we need corroboration on something.

BTW: what size memory do you have?

[Jerry3904]

Before I start stuffing my face this Thanksgiving, I want to lay out what I see as a TOP PRIORITY:

The most important item IMO to try to solve before going to Beta is the failure to reboot after the beginning boot sequence when info--of any kind in my testing, even just wireless data--has been entered into Imager's Advanced Options (name?) before flashing the OS to a SD. It is not only confusing to the user but seems so amateurish. I have some questions to try to get a handle on the actual question:

1. Is it just a Pi 5 problem? Has anyone confirmed it on a Pi 4 or 400?
2. I gather that the handoff (as I call it) comes when the initial system parameter set has been made using the first partition, and then the system turns to launching the OS using the second. Can we find the trigger for that reboot?
3. Is there a log for the early boot procedure?
4. Is there anything about MX in particular (the Live option, for instance) that might interfere with the boot partition's process?
5. Does MX get involved with the handoff in any way?

I find this very hard to understand since it does not happen with any other image I have tried.

[chrispop99]

Before I start stuffing my face this Thanksgiving, I want to lay out what I see as a TOP PRIORITY:

The most important item IMO to try to solve before going to Beta is the failure to reboot after the beginning boot sequence when info--of any kind in my testing, even just wireless data--has been entered into Imager's Advanced Options (name?) before flashing the OS to a SD. It is not only confusing to the user but seems so amateurish. I have some questions to try to get a handle on the actual question:

1. Is it just a Pi 5 problem? Has anyone confirmed it on a Pi 4 or 400?
2. I gather that the handoff (as I call it) comes when the initial system parameter set has been made using the first partition, and then the system turns to launching the OS using the second. Can we find the trigger for that reboot?
3. Is there a log for the early boot procedure?
4. Is there anything about MX in particular (the Live option, for instance) that might interfere with the boot partition's process?
5. Does MX get involved with the handoff in any way?

I find this very hard to understand since it does not happen with any other image I have tried.

I don't use Imager, so can't answer this straight away. I will try to do a test using Imager in the next couple of days.

Happy Thanksgiving - don't eat too much!

Chris

[dolphin_oracle]

Before I start stuffing my face this Thanksgiving, I want to lay out what I see as a TOP PRIORITY:

The most important item IMO to try to solve before going to Beta is the failure to reboot after the beginning boot sequence when info--of any kind in my testing, even just wireless data--has been entered into Imager's Advanced Options (name?) before flashing the OS to a SD. It is not only confusing to the user but seems so amateurish. I have some questions to try to get a handle on the actual question:

1. Is it just a Pi 5 problem? Has anyone confirmed it on a Pi 4 or 400?
2. I gather that the handoff (as I call it) comes when the initial system parameter set has been made using the first partition, and then the system turns to launching the OS using the second. Can we find the trigger for that reboot?
3. Is there a log for the early boot procedure?
4. Is there anything about MX in particular (the Live option, for instance) that might interfere with the boot partition's process?
5. Does MX get involved with the handoff in any way?

I find this very hard to understand since it does not happen with any other image I have tried.

its important to remember that the advanced features of pi-imager are designed to work with a shipping piOS. you also don't have to use pi-imager at all. I don't know about amateurish, what other system do you ever set up a user and wifi before you ever boot? except for the mx-tools, and the oobe setup, there isn't much different from the regular raspberrypi OS, other than the fact that the firstboot routines are already done.

one thing to eliminate: there are no live options on the pi image. the live system is in no way installed. what special first-launch stuff we do have happens after the user is logged in.

one thing to examine: the default user is different. piOS ships with raspberrypi as the default user. we use demo, which allows the oobe to work as intended. I've noticed that certain parts of the first boot routine fail if that user is not present. that could cause a hang and the system just sit there. part of the firstboot routines disables the firstboot routine, so a reboot might work there. I suspect that to be able to use the advanced setup in pi imager, we would need to abandon oobe and figure out how to reset piOS to its shipping condition. I don't know how difficult it would be to keep that default username, as piOS forces the user to change the default user name at first boot, so keeping the raspberrypi user name will be tricky at minimum. and that default user must be UID 1000, or other parts of the pi firstboot setup will fail, so just creating a second user as was done on an earlier img will not work either.

its sort of the same way that a personal snaphsot is different from shipping mx iso, but not really.

as far as I know there are no logs, but if they are anywhere they would be some where on the bootfs partition.

[Jerry3904]

Thanks for the detailed response. I'll try to see those logs, but not today.

[dolphin_oracle]

Thanks for the detailed response. I'll try to see those logs, but not today.

its super tricky, like complicated to be complicated. makes sense if you are setting up a headless device, like many pi kits do, as you would never need a physical screen. just boot and ssh in.

makes less sense on a desktop os.

turkey is in the bag and in the oven...thanksgiving comes to my house!

[dolphin_oracle]

it just dawned on me that most of the pi set up stuff happens with systemd services and/or some stuff in rc.local. there is a boot log generated in rootfs under /var/log/boot.log.

I didn't see any logs in bootfs.

[dolphin_oracle]

might be a /var/log/firstboot.log file as well, if customizations are attempted.

[Jerry3904]

Kitchen is humming here, too. Rachel is doing a "spatchcocked" turkey for the first time: all spayed out by the butcher, fast in the oven.