[Solved] Why can't my computer's boot menu see a bootable LiveUSB?

[Neil Edmond]

So.... did the SolydX updates mess with the system in some way which still allow it, and Mint, to work, but prevent MX16 and the Live media from connecting or driving the display graphics properly?

While you cannot take my thoughts as the final work on the subject, I have to answer no to the question. As far as my mind can grasp, SolydX updates can only affect SolydX, not any other installed OS, and certainly not the BIOS.

I guess it is possible that old system board components further decayed during the time it was sitting un-used. I have had stuff like that happen before...

[br1anstorm]

..... As far as my mind can grasp, SolydX updates can only affect SolydX, not any other installed OS, and certainly not the BIOS. ......

My mind works on similar lines. I too cannot see how updates to SolydX would affect anything other than SolydX. The only "grey area" is whether an update to SolydX's Grub (which is the "lead" Grub for booting into any of the three OSs on the system) would affect its ability to work effectively with those other OSs. I already know that it can still boot Mint up. But it can't boot MX16 now.

I guess it is possible that old system board components further decayed during the time it was sitting un-used. I have had stuff like that happen before...

I don't think that's a plausible explanation, for a couple of reasons. First, the system hasn't exactly been "un-used". I fired it up about once a month anyway, usually just to run updates, but occasionally to do some specific piece of work. So the components did get some exercise! Secondly, if indeed any component had "decayed", it would surely affect each and all of the OSs installed on the system. In my case, SolydX and Mint continue to function perfectly, which surely rules out a hardware failure?

[Neil Edmond]

Agreed. I had overlooked the fact that you have a working system or two installed, and just one of them is giving you problems. So probably not hardware failure.
One the other point...a while back, when I was running 3 or 4 distributions on the same hard drive (most if not all based on Debian Sid), the one most recently updated would take over the top spot on the GRUB menu, but that was all. The others would still boot just fine, just not without my intervention.

[br1anstorm]

It is hard to grasp why a system that worked in the past doesn't work now. I'm fairly sure MX offers a safe graphics mode of some sort in the boot menu of the live system. Have you tried choosing that? Maybe even try the xforcevesa boot option and see if that makes any difference.

Well I'll be d....d! I looked back through this thread and re-read this post, and thought - well, I haven't yet tried that! So I dug out my LiveCD of MX16.1 and sure enough, there is an option to set a "safe video" mode.

I have just booted up a Live session of that MX16.1 from the CD in 'safe video' mode. Glory be, it boots successfully, and displays the normal screen at regular quality, colour and definitions, with all the usual menu options. I can connect to the internet and choose any of the normal menu options.

So what on earth does that tell us? A LiveCD won't properly boot into Live Session when started normally; but it will boot up fully when in 'safe video' mode. I'd assume that it points clearly to some problem with the graphics/video drivers. But not being an expert in the design of MX16, I don't know what the 'safe video' mode uses that is different from the 'normal' mode. It suggests that the problem lies in whatever graphics/video software is bypassed in the 'safe video' mode.

Any thoughts would be welcome. I might also seek some more advice in the MX16.1 forum now that we seem to have narrowed down the focus to the likely culprit!

[br1anstorm]

Well, another twist in the tale.

I seem to be replying to, or adding to, my own posts as the story evolves.

Picking up on earlier suggestions, I tried editing the entry for MX16 in the grub menu to include nomodeset and then xforcevesa. Neither had any effect. I was still getting a black screen at the end of the MX16 boot process.

But the issue was clearly something to do with driving the video screen/monitor. So I had a rather lateral thought.

I have just changed monitors and plugged in a different (but equally ancient!) monitor display screen....

Yay!!! Not only do SolydX and Mint boot up perfectly - but MX16.1 boots up too, and I have the normal screen display in front of me. No more black screens.

So what does this demonstrate? I'm still trying to figure it out. It seems to point to a problem or hardware fault in the actual monitor I was using.

That does not explain why the monitor I was using performed perfectly well with SolydX and Mint, but gave a black screen for MX16 and for any LiveCD or USB. Is it because different monitors require different drivers, and the one which SolydX and Mint uses is different from the one MX16 (and Live CDs) use? I can't quite figure that out....

So in a curious way the problem is solved (simply by using a different monitor screen), even though the actual cause of the problem remains - at least to me - a bit of a mystery. If anyone cares to offer thoughts, in the light of all this evidence, on exactly what the fault was or is, feel free to comment. Meanwhile, thanks to Neil Edmond - and others - for joining in the detective work. Maybe the only outcome of this will be to consign the monitor which I had been using to the scrapyard.....

[jglen490]

I suppose that, technically speaking, there are three elements that have to interact to produce some picture on a monitor. The three parts are the motherboard, the video circuit, and the actual display device. There should also be two more pieces that contribute to success: the software driver and the connecting cable. And there are one or more standards applicable to each part.

The monitor has to understand the signal it is receiving, through the cable, via the video circuit as interpreted by the driver, as it was first passed from the motherboard. Plenty of room for random mismatching, especially if one or more components are much older or much newer that other parts. Maybe you saw that when you changed your monitor. Not every old piece is supported forever, and really new parts may not have been a consideration when software and firmware were written. You'd think that cables of a certain type would be standard forever, but loose connections or damage can really change what you can see, or hear.

[br1anstorm]

The final instalment - I think - in this saga.

jglen490 is right. To get a proper display on screen, all the separate elements have to work together. For some reason, on my multiboot system, this stopped happening. Two of the three distros (Mint and SolydX) were able to drive the monitor display. But neither MX16, nor any of several LiveCDs/USBs, could do so.

Having followed several fruitless trails, it turned out that the problem - whatever it was, and we still don't know exactly - was with the display monitor. A different monitor worked perfectly with all the distros and the Live sessions.

A final postscript. I connected the "faulty" monitor to another desktop which still has Windows XP on it. Initially it would not work: it displayed a "Signal Over Range" message on a black screen. Some googling revealed that this was - yes - because the video driver wasn't communicating correctly with the display. The solution was to boot Windows into Safe Mode, and adjust or re-set the display settings. I did that, and rebooted. Guess what: the monitor screen works perfectly again.

Technology works in mysterious ways. But at least I can now mark this thread 'Solved'.