Inconsistent boot behavior from Vanilla Dpup 10.0 in Toshiba Satellite P200

[redquine]

I've been using Vanilla Dpup 10.0.x-xwayland since its release, It still works perfectly once it boots up, but the boot screen has recently started hanging on 'Waiting for modules to complete loading...' This doesn't always happen and when it does, it sometimes continues after a few minutes - but sometimes not, and I have to Ctrl+Alt+Del to reboot it. When I do that, it zips through the boot process as normal. I've occasionally had to power down manually as it doesn't reboot either.

I can't see any differences in the error logs between successful and unsuccessful boots, apart from the process being cut short by my response. I was therefore wondering if my old Toshiba Satellite P200 is struggling with the latest kernels. (That doesn't explain why the fault is intermittent, but I thought it might be worth investigating.)

I can't see any older kernels on GitHub (unless I'm overlooking a link somewhere) so I was wondering if they were still available anywhere. I'm not sure exactly when the issue started so might have to try a few different ones.

Alternatively, is there anything else you can suggest please? Happy to provide any further details you might require.

[Flash]

If you're comfortable with taking the laptop apart, I'd say remove everything you can, especially the RAM, blow the dust out and put it back together. Just removing and replacing the RAM might do the trick.

[dimkr]

Does the regular X.Org flavor work? Consider the Xwayland flavor to be some tech preview, not something that's guaranteed to be as stable and reliable as the regular one.

Regarding kernel updates - 10.0.x sticks with 6.1.x and only gets bug fixes and security updates. Breakage is very unlikely, maybe your download was corrupt.

[bigpup]

To check for a real boot issue.

You need to be booting from a complete power off to power on condition.

Just doing a reboot is not making sure that the RAM is completely clean and empty.

Standard is one minute no power, to make sure everything in RAM is completely gone.

Because a reboot does not remove power from the computer, but only makes it go into a bios boot process.

The RAM does not loose power and could still have some leftover stuff in it.
It should be stuff that is no longer being used for anything, but it still could corrupt what will be entered into RAM, as the computer reboots.
It is a matter of it could, not that it will always affect anything.

Now, if you are getting boot issues, from a completely powered off/on computer, boot process.
Something is not correct and needs to be looked into fixing or finding out why, on this computer, it is doing this.

[wiak]

The RAM does not loose power and could still have some leftover stuff in it.
It should be stuff that is no longer being used for anything, but it still could corrupt what will be entered into RAM, as the computer reboots.

I don't think so... On reboot any areas of RAM needing re-initialised are re-initialised. It is irrelevant what remains in other areas of RAM that aren't allocated. Makes no difference what bit patterns they contained prior to re-initialising happening. If you have an example proving otherwise, a link to some respectable technical article maybe that confirms all of that in actual evidenced tests, I'd love to hear it. Otherwise above sounds like black magic or old wives tale that has nothing actually to do with anything. Sorry, but I think it is best not to give advice that is not evidence-based, even if it is entertaining to read.

[dimkr]

Memory is cleared before use, yes. I wonder if OP has replaced the kernel, because more frequently than not issues like this happen when people replace the kernel with something more recent and less stable than the longterm kernel used by Debian, sometimes patched with aufs (which causes lockups from time to time) or misconfigured.

[bigpup]

The RAM does not loose power and could still have some leftover stuff in it.
It should be stuff that is no longer being used for anything, but it still could corrupt what will be entered into RAM, as the computer reboots.

I don't think so... On reboot any areas of RAM needing re-initialised are re-initialised. It is irrelevant what remains in other areas of RAM that aren't allocated. Makes no difference what bit patterns they contained prior to re-initialising happening. If you have an example proving otherwise, a link to some respectable technical article maybe that confirms all of that in actual evidenced tests, I'd love to hear it. Otherwise above sounds like black magic or old wives tale that has nothing actually to do with anything. Sorry, but I think it is best not to give advice that is not evidence-based, even if it is entertaining to read.

first you assume everything is always going to work 100% correctly.

I know from personal use of computers, building computers, and fixing computers, that what I have told you is something that can and does work.

If you do not want to follow my advice, then do not.

The computer I am using right now, has been fixed for strange boot problems, by doing exactly what I stated.

I was doing multiple installs of different Puppy Linux versions and updating the boot loader.
Just doing reboot from different ones trying them out. (never completely powering off the computer)
At one point after several reboots, got a strange not booting correctly issue.
Did a complete power off shutdown.
Waited one minute no power.
Powered on computer and got to the boot loader menu.
Selected the menu entry I was trying to boot before.
It booted with no issue.

I just fixed a phone that a simple reboot did not work. (they are basically a computer)
Shut it down restart did not work.
Removed the battery for one minute.
Reconnected the battery.
Did a normal startup.
It is now working like normal.

[redquine]

Thanks for all your helpful replies - and thanks to whoever changed the title of this thread; that's a lot clearer.

If you're comfortable with taking the laptop apart, I'd say remove everything you can, especially the RAM, blow the dust out and put it back together. Just removing and replacing the RAM might do the trick.

@Flash, good idea! It'll take more time than I have available today but I'll give it a go over the weekend.

Does the regular X.Org flavor work? Consider the Xwayland flavor to be some tech preview, not something that's guaranteed to be as stable and reliable as the regular one.

@dimkr, thanks for clarifying that. I've used the X.Org version on other laptops but tried Xwayland first on this one; since it worked OK, I stuck with it (in¢luding the kernel provided).

I know from personal use of computers, building computers, and fixing computers, that what I have told you is something that can and does work.

@bigpup, I've fixed a few issues on various devices that way, but I don't believe this one's related to rebooting. I only ever do that if I've already had a problem, and rebooting usually fixes it. I normally cold-boot once a day and follow the standard shutdown process. It's completely powered off till the following day; the laptop battery's completely dead so once I've unplugged it from the mains, that's it.

Edit: I've just switched to vanilladpup-10.0.57 (X.Org) and all's well so far. Also, the issue doesn't seem to be related to my save folder as it happens when I boot RAM-only as well, but I've created a new one just in case. I'll let you know if I run into problems again.

[wiak]

I still feel it would be interesting to have some repeatable examples of cases where shutdown prior to reboot fixed a problem whereas straight reboot did not. Would be useful to identify why? Certainly there are many who have stories where they think that was the reasons seen happening to them, but why in terms of technical boot process?

Shutdown might itself physically clear bits in RAM (I don't know). Since power still applied, reboot might not, but the boot process should re-initialise according to design. If it doesn't it seems to me that something remains wrong so SOLVED in such thread maybe a bad idea. Could be the likes of dust affecting RAM addressing, or actually faulty areas of RAM (that would cause other issues). Depending on timing/race situationd, different RAM area could be allocated/initialised (who knows?...). One faulty bit in RAM might not cause any issue for 50% of the occasions storage is occurring to it (could coincidentally be a 1 or a 0 when save wants the same). But there are always underlying reasons for any fault condition including reboot not correctly re-initialising. Simply choosig shutdown as a discovered working mechanidm is just a workaround for unfound actual solution, so can be misleading overall.

There is always the 'hit it with a hammer trick' that some class of mechanics swear by.

Zen and the Art of Motorcycle Maintenance novel comes to mind.

[redquine]

I still feel it would be interesting to have some repeatable examples of cases where shutdown prior to reboot fixed a problem whereas straight reboot did not. Would be useful to identify why? Certainly there are many who have stories where they think that was the reasons seen happening to them, but why in terms of technical boot process?

I agree, it would! However, I'm unaware of anything I'm doing differently. As a creature of habit, I usually have the same applications running and close them all the same way before logging out. The error logs don't offer any clues either.

Next time I have a few minutes spare, I'll try going through the boot process very slowly and make notes as I go. There may be some subtle difference I haven't noticed as I'm usually on auto-pilot after a long day at work...!

[redquine]

At long last, I've been able to work out what makes the difference! I'm still not quite sure what's happening behind the scenes, but happy to mark this as resolved for now.

I don't have wifi at home. Instead, I tether my phone (Moto G5) via USB cable. On this model, I need to manually enable USB tethering after I've booted the laptop, so the phone can detect the USB connection.

If I connect the cable when I switch the laptop on, then enable USB tethering before the boot process begins, it's detected as a wired network connection and works fine.
If I don't connect the cable until after it's booted to the desktop, I can then connect it and enable USB tethering. This works fine too.
However: if I connect the cable at boot then fail to enable USB tethering in time: that's when the process hangs at 'Waiting for modules to complete loading...'

I'm guessing the phone is being detected as a USB device and that Vanilla Dpup is struggling to locate the right driver for it. (By the way, if I then disconnect the phone, the boot process continues to hang.) As to whether I can reboot or not: perhaps it depends on how long it's been searching for the right driver. I only have 3GB RAM, and boot with the "no-copy" tag, so it might fill up to the point where no further action is possible. Whereas if I manage to catch it quickly enough: USB tethering persists on reboot, which is why it is then detected correctly.

Hope all that makes sense, even if my guesses aren't 100% correct!

I've been able to replicate this a few times. It's not causing me any great difficulty at the moment, especially now I have a clearer idea as to why it's happening - just something for me to remain mindful about. But I thought I'd share what I've found out, in case it offers a clue to someone else with a similar problem.

[Doggy]

At long last, I've been able to work out what makes the difference! I'm still not quite sure what's happening behind the scenes, but happy to mark this as resolved for now.

I don't have wifi at home. Instead, I tether my phone (Moto G5) via USB cable. On this model, I need to manually enable USB tethering after I've booted the laptop, so the phone can detect the USB connection.

If I connect the cable when I switch the laptop on, then enable USB tethering before the boot process begins, it's detected as a wired network connection and works fine.
If I don't connect the cable until after it's booted to the desktop, I can then connect it and enable USB tethering. This works fine too.
However: if I connect the cable at boot then fail to enable USB tethering in time: that's when the process hangs at 'Waiting for modules to complete loading...'

I'm guessing the phone is being detected as a USB device and that Vanilla Dpup is struggling to locate the right driver for it. (By the way, if I then disconnect the phone, the boot process continues to hang.) As to whether I can reboot or not: perhaps it depends on how long it's been searching for the right driver. I only have 3GB RAM, and boot with the "no-copy" tag, so it might fill up to the point where no further action is possible. Whereas if I manage to catch it quickly enough: USB tethering persists on reboot, which is why it is then detected correctly.

Hope all that makes sense, even if my guesses aren't 100% correct!

I've been able to replicate this a few times. It's not causing me any great difficulty at the moment, especially now I have a clearer idea as to why it's happening - just something for me to remain mindful about. But I thought I'd share what I've found out, in case it offers a clue to someone else with a similar problem.

Nice detective work! Thanks for sharing your findings. It's helpful to know what's causing the issue, and your explanation makes sense. Hopefully, this will help someone else who runs into the same problem.