Strange problem booting an old Dell laptop running Linux

[edy]

I have an old Dell laptop on which I installed Ubuntu. The battery is basically dead so we have it plugged in all the time otherwise it won't boot, like a desktop. When we don't need to use it, we close the lid and it goes to sleep. When we open the lid it wakes back up, no problem, works a charm.

Now the WEIRD STUFF happens when the machine gets unplugged by accident, and we have to reboot it. If I try to simply plug it back in and turn it on, it seems to get past the BIOS and then gets to a point where the boot freezes and I see strange bunch of lines and noise on the screen (I will post a photo when I get back home). The pattern is usually the same every time, it is repeatable.

Now here's the rub... If I press F2 on boot and get into the BIOS settings and do absolutely NOTHING but just choose the option to exit (no changes at all), it will proceed to boot normally. I will try to repeat this and make a video and post it.

I discovered this accidentally as I didn't know why this was happening. So I went into the BIOS a few times thinking something was up with the settings (since laptop dead I though maybe CMOS battery was also dead). But the computer retains the settings... clock, all the BIOS configuration is retained. So it can't be that.

It is as if something happens when I enter the BIOS menus that fixes the issue, that doesn't normally happen on a regular boot. I'm not even sure if this has anything to do with the OS and it happen with other distros or even Windows. I will also check if it happens if I do a proper shutdown versus and accidental unplug. Odd? Once I post the video maybe it will make more sense.

[Jeroen3]

Try to replace the bios backup battery anyway.

[edy]

Ok I have done some more testing... rebooting, shut down fully and then restarting, unplugging, etc. Turns out it is not me going into the BIOS that is "fixing" anything, I ended up having the problem even doing that. I just didn't notice because it seemed to work. But what is happening is this:

1. Computer unplugged or shut down or restarted normally
2. Gets past BIOS screen, hard drive spins a while but no GRUB menu and then screen fills with garbage (see attached photos - not always the same pattern)
3. I then hold down power button (or unplug/replug) until it reboots
4. Second time around GRUB menu appears and then it does a "recovering journal" and "clean" stuff
5. Boots successfully

If I now reboot the machine or unplug any which way, it will go through the exact same cycle AGAIN... requiring 2 boots to get up and running again. The first boot will always end up with no GRUB menu and garbage on screen. The forced restart will then show the GRUB menu and proceed to boot normally and end up doing the "recovering journal" / "clean" message which seems to indicate Ubuntu was loading the first time and froze.

I mistakenly thought it was me fixing it by going into the BIOS after the first unsuccessful boot that somehow fixed it and allowed it to boot the second time... but it had nothing to do with me. It will boot the second time even if I am not involved. This is consistent as I've now tested it numerous times. Always takes 2 to boot. 

It's almost like something is happening in boot cycle one that doesn't let it boot but allows it to boot on cycle two, but once it successfully boots it reverts to a state that will not allow it to boot again (until it goes through the failed first boot cycle). 

I'm not too worried but out of curiosity it would be nice to understand what is happening. Probably an Ubuntu thing. Perhaps there is a boot log which may point to the failure. Some driver detect for video going funny and Ubuntu resetting it back to a more default generic, but then once it boots successfully it tries to revert back to the faulty driver automatically once it is up and running some process? I don't know, just guessing here. Very flip-floppy behavior. 

They should call it Two-buntu!!!!   

[mfro]

Try to replace the bios backup battery anyway.

Would second that.

Also I would strongly assume that your problem hasn't anything to do with neither Linux nor Grub as it appears to happen long before the machine even smells it might have to boot one of them

[edy]

Try to replace the bios backup battery anyway.

Would second that.

Also I would strongly assume that your problem hasn't anything to do with neither Linux nor Grub as it appears to happen long before the machine even smells it might have to boot one of them

I'm not sure about that, because it goes past Dell's logo in both instances and hangs up *AFTER* the hard drive is spinning and seemingly doing something (by Ubuntu) for maybe 20 seconds. Then it freezes and shows something that looks like those photos I showed in my previous post. Then if I reset it again it will do again normal Dell logo and then display GRUB usually within 5 seconds and proceed to boot normally. It always fails on the "ODD" boot and works on the "EVEN" boot.

If the BIOS battery was bad, it wouldn't even retain settings at all, and it would never boot normally. This system always flip-flops between alternating BAD boot, then immediate next boot works. Then reboot is BAD, then boot again it works. Alternating indefinitely. Somehow if Ubuntu boots normally it messes itself up for the next boot, but something must happen in the BAD boot to fix itself so a subsequent boot works again normally.

By the way I'm trying "journalctl -b" and different logs "journalctl --list-boots" to show different logs (e.g. "journalctl -b-1", "journalctl -b-2", etc..) and I can't seem to track anything in there that would help. Strange behaviour, just thought someone may recognize this... we almost never reboot the machine anyways, just close the lid to put it into sleep, then wake it up... usually no problems. Only time we face this problem is if someone accidentally trips the cord or unplugs the wrong one (which is rare), then we have to go through this 2-cycle process to get it to boot. Annoying but not the end of the world, just a quirk.

[eugenenine]

I remember some molder dell laptops if the cmos settings were lost they would take longer to boot as they would auto detect the drives.  most have a multibay where you can add an additional drive in place of a battery so when it doesn't have the prior config stored it does a slow boot and attempts to check for the internal drive then any drives in the bays and that takes a long time.  after that first boot it does a fast boot by using the previously stored config.

[Ampera]

Let's eliminate some possibilities here.

What I'd do first is generate a fresh grub config. I'm wondering if this isn't a GRUB driver problem (GRUB is not Linux, it's a self-contained environment right up until it loads Linux, so it has its own driver modules). The instructions to do this can be found on the Arch Linux wiki's GRUB page. If you're comfortable, it's not a bad idea (though not needed) to use a live environment with the tools loaded, or with an internet connection so you can download them. Arch keeps everything fairly close to upstream so this wouldn't be a bad distro to use (again, if you're comfortable).

Go into the grub config (ususally /boot/grub/grub.conf) and get rid of any module that gets loaded that looks like it might be related to VESA or special graphics modes. Make sure to only comment the (I think it's includes in GRUB, but I forget)
statements out, as this might take a few tries. The idea is you want GRUB to only load using VGA drivers and nothing else. Try to see if this improves things.

If you're running X and it decides to break at this point, ensure your graphics drivers are up to date. If you're using Intel graphics I suggest xf86-video-intel as it tends to fix some issues and have more options than the default KMS driver (if you don't have it already).

If nothing here works, you can try installing DOS. Try to see if you can even reliably boot into a text mode environment, and then try something like Windows 95, which without custom drivers only supports VGA video. If it always does this and nothing else works, I'd say you have a hardware issue, and that if replacing whatever CMOS battery and clearing BIOS NVRAM does nothing, then it's likely something that would take more time to fix than that laptop is worth.

[magic]

Incredibly bizarre. What if you break the cycle by power cycling on Dell logo or GRUB menu?

If you have access to those logs, any indication that Linux actually attempted to boot when the machine hung?

[Jeroen3]

Try and see if you can get the glitch when you boot without hard disk.

[Psi]

My money is on a hardware fault that is slowly starting to manifest.
I suspect the changes in heat inside some component is causing this change in behavior until it warms up a little again.
Could be bad/dry electrolytic capacitors making it harder for the switchmode controller to produce stable DC under the rapid load current fluctuations at boot time.

Sadly I also suspect that the problem is going to get worse and take more tries to get it to boot in the future.

If it was me i would disassemble and check/replace the caps on the internal DCDC psu board.

[Jeroen3]

Does this look familiar?
I just installed lubuntu-18.04-alternate-i386 on this Vostro 1520 and look what it did.

So, it's software! Good thing to know. Probably some grub thing, are there alternative to grub?

It's the same pattern, so probably a pointer failed somewhere causing raw memory to be put on the screen.

Edit:
This is the supposed fix, will report in later.
https://askubuntu.com/questions/38780/how-do-i-set-nomodeset-after-ive-already-installed-ubuntu
... Yeah... This does fix the boot problem. But the video driver will be stuck in generic resolution, which is tiny.

[rstofer]

In the old days, it was necessary to flush the disk buffers before shutting down.  'sync;sync;sync' followed by 'shutdown -h now'  No fewer than 3 sync's and no more...

"Old days" is defined as "up to and including tomorrow".  The Raspberry Pi doesn't like power drops.  This is such a problem that I added a UPS just to prevent it.

Try not just putting the system to sleep, shut it down completely.  I would expect current Linux 'shutdown' commands to sync the drive(s) (the old 'halt' command didn't) but maybe you can try it both ways; with the sync's before the shutdown and without.

You can force a 'fsck' at boot time, details on Google.  If you see a lot of errors, you can just about bet your abnormal shutdowns aren't helping.

[andersm]

Does the machine respond to pings? If it does, try switching to another virtual terminal with alt+Fkey. Having a running SSH server can be a godsend if you're dealing with graphics driver issues.

[edy]

Does this look familiar?
I just installed lubuntu-18.04-alternate-i386 on this Vostro 1520 and look what it did.

So, it's software! Good thing to know. Probably some grub thing, are there alternative to grub?

It's the same pattern, so probably a pointer failed somewhere causing raw memory to be put on the screen.

Edit:
This is the supposed fix, will report in later.
https://askubuntu.com/questions/38780/how-do-i-set-nomodeset-after-ive-already-installed-ubuntu
... Yeah... This does fix the boot problem. But the video driver will be stuck in generic resolution, which is tiny.

Thanks for all the help and suggestions. I'm glad to see I'm not the only one this is happening to. I am going to assume it is the particular Linux install. I can try to just boot off USB keys (I have a few distros) and see it the same problem manifests. If I am booting successfully from every key I have, or the same key, continuously without any hangs then it must be the OS configuration on the machine. 

Like I said before, it corrects itself as soon as I reset the machine again. But then when I shutdown and restart it hangs again until I reboot it (2 boots each time to work). Even the GRUB menu doesn't display on the first faulty boot, but as soon as I reset it the GRUB menu shows. As long as GRUB menu shows I know it will proceed to boot normally... I've never had the GRUB menu show up and have it hang.

So whatever is happening may be pre-GRUB or related to graphics driver initialization prior to GRUB being displayed. As far as I can see the GRUB menu also displays is some different font so it is using graphics mode, it is not just a plain text screen. I don't know enough about how the pre-GRUB initialization works, but I can try that "nomodeset" suggested so that it will display using regular BIOS text screen and see if that fixes the issue.

As stated before, what fascinates me is the flip-flop behaviour. I understand if it just fails randomly but it is predictably predictable. One boot fails, second boot works, third boot fails, fourth boot works... etc. GRUB or Linux is doing something on the fail to allow the reset to work (it must be writing it to disk because the reboot wipes all memory), but then it subsequently changes the setting back after successfully booting, causing the 3rd boot to fail again, cycle repeats. Interestingly the GRUB still displays in graphics mode even when it fixes itself... it doesn't seem to be BIOS mode but then again maybe it is?

I will try the fix above and see what happens. Thanks again!

[Jeroen3]

I fixed it by installing the 64 bit kernel. And it’s post grub. The disk is being accessed a long time first. (Ssd)
Must be the graphics screwing things up.

[Ampera]

You can also set the initial kernel graphics mode by passing the vga= parameter on the kernel command line, using three digit codes as such: https://en.wikipedia.org/wiki/VESA_BIOS_Extensions

If it's a problem with X, you can also disable X (on systemd systems it's usually by disabling a login manager like lxdm, gdm, lighdm, sddm, etc) and then install the appropriate drivers for your system. If you have Intel graphics, there can be issues with the modesetting and xf86-video-intel drivers alike, so you can install or select on or the other in your xorg.conf (if you need to generate one do as su X -configure and then cp /root/xorg.conf.new /usr/share/X11/xorg.conf.d/xorg.conf).

If you're using nvidia drivers, you might be using nouveau, the open source nvidia driver implementation, that often has issues with hardware. In this case you can try using the proprietary nvidia drivers (on most distros called "nvidia") which tend to work better.