Brand new to everything! Need help with modifying an industrial machine to use new video card.

Thanks for that info. So it appears there is no appearance of the bootloader in the form of a menu on screen for a time before the booting of the linux kernel, so we don't at this point know what the bootloader is. There's a chance it is grub which has been configured to hide itself before the linux kernel boots. There are other bootloaders it could be, syslinux or LILO, and this software may be boutique and not really amenable to much alteration or configuration. I know of such software, having written some.

If by chance the bootloader was grub, if one could get a grub menu on screen for a time, it's relatively easy to remove the matrox kernel parameters from there.

jacmeenon wrote in post #13:
Okay, I've written SystemRescue to a bootable USB drive. After forcing the computer to be able to boot from USB, I can get into the system rescue menu... going forward. Any help here would be awesome as this is all english to me but looks like greek.

The rescue disk should reveal info that will be useful one way or the other.

This is what I would do ... boot up the rescue disk. Select the default it suggests to boot and boot it. It should then bring you to a root prompt with a #. If you run the following commands and provide the output here, that output will likely suggest how to proceed:
lsblk -f

lspci

lspci -nnkd ::300
If you can put the output of these commands here inside code tags, we can see the output exactly as it has been extracted by the commands. Note: lspci, NOT lscpi.
 
Last edited:


Never heard of a machine that runs the instant the power supply is switched on. Not what I would term a 'normal' computer, certainly.

So; this sounds like it's been set-up to auto-run, and, moreover, to auto-hide everything as it does so. Apparently, the PSU has been wired direct to the mobo, instead of via a user-controlled on/off switch as normal. Which makes it almost impossible to "interfere" with; in other words, it's been set-up to be "tamper-proof"......so that even a complete dunce could run it. No 'tech' knowledge required..!

Does this have a standard mini-ITX motherboard, or this is a custom, embedded solution? I'm guessing the former, or else you wouldn't be talking about a separate, discrete GPU.

Whoever installed this, seems they didn't give much thought to any poor techs that came along behind them in later years when things started wearing-out and needed replacing/fixing. Probably seemed like a good idea at the time, but.....well; 'nuff said.

I think you're looking at an uphill struggle here, unless whoever installed everything left any 'notes' behind, tucked away in a file cabinet somewhere?


Mike.
facepalm-small.gif
 
Last edited:
I'm away from the machine at the moment, and will try when I regain entry, however I believe I tried "lspci -nnkd ::300" and reported back intel graphics drivers. Whatever it said, I remember it making me think that it was just reporting back the "new" environment that the Rescue Disk was loading, if that makes any sense. But, Like I said, I will try again and report back what it prints out. Thank you all.
 
I'm away from the machine at the moment, and will try when I regain entry, however I believe I tried "lspci -nnkd ::300" and reported back intel graphics drivers. Whatever it said, I remember it making me think that it was just reporting back the "new" environment that the Rescue Disk was loading, if that makes any sense. But, Like I said, I will try again and report back what it prints out. Thank you all.
That's good info ... the rescue disk however, would be reporting in this case on the hardware and software on the machine, not any "environment" of itself. Best to have the full output of the command which will include the driver info.
 
Last edited:
Thanks for that info. It helps. It shows there is a kernel driver for the intel graphics card, so the computer should be able to boot from it without the matrox video card, so long as the machine doesn't load the matrox drivers.

The lsblk output in this case has not shown the size stats of the partitions so it's hard to guess which is the root partition. However, I suspect that the two ext2 partitions are root and boot partitions. Normally a modern lsblk utility shows the space available in the partition and the percentage of it that is being used, for example:
Code:
[flip@flop ~]$ lsblk -f
NAME   FSTYPE FSVER LABEL UUID                    FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                         
├─sda1 vfat   FAT32       D7B1-9618                191.1M     3% /boot/efi
├─sda2 ext4   1.0         9a02dae6-eb81-4209-af70   35.9G    22% /
├─sda3 swap   1           201fc67c-6b76-4023-9191                [SWAP]
└─sda4 ext4   1.0         67a70060-3e2c-484d-b8d5  775.3G     5% /home
sr0
Your output may mean that your machine is running a stripped down set of utilities.

The next step I would take is to find that root partition, (and the boot partition if it is separate), mount them, change some configurations to delete the matrox kernel parameters, and try and get the machine to boot with the intel on board video. If one can get to that point, one is in a better position to install another video card.

I'm going to describe a laborious means of mounting rather than a more efficient one because I think you'll be able to follow this more easily.

So, I would mount the partitions one a time to see what they contain. The process is to mount the first partition on the mount point /mnt (which should exist in a linux filesystem), then navigate to the mount point, and run ls to list the files that are there. (Note the that the partition names in the lsblk output are named with their full device name for mounting i.e. sda1 is /dev/sda1 etc.):
Code:
mount /dev/sda1 /mnt
cd /mnt
ls
To unmount the partition, relocate root user to its home with the cd command taking root out of the mounted partition, and then run the umount command:
Code:
cd
umount /mnt

Similar commands can be made to mount the other partitions by changing the partition name to the one you want to mount. To look into each partition, each one has to be mounted, have its files listed in this case, and then unmounted before repeating the process for the next.

If you mount each one, and list the files, then one will be in a better position to proceed and try to make some changes.

If there is trouble mounting the reiser partitions, then the mount command could be altered to use this one:
Code:
mount -t reiser /dev/sda3 /mnt
The unmounting command is the same as above, and the mount point /mnt is the same.

I'll leave it there until we get the info if we can. If there's an issue, come back, describe it and we can try and deal with it.

Edit: you could try running lsblk without any options ... that may show the size of the partitions.
 
Last edited:
Thanks for working through those commands. Most useful. Looks like there's a lot of control commands for the process of your "semi-automated industry machine" on the second partition. The boot partition is /dev/sda1, and that's the one from which we need info. Normally the boot partition holds the config file to control the booting, so if you could mount the boot partition again, and run a command to dive deeper into it and see everything that there this time.

Code:
mount /dev/sda1 /mnt
cd /mnt
ls -alR boot

It might be a few screenfuls of text. Then you can unmount it as before. I know this is a bit time-consuming and laborious, but for someone new to linux, I'm trying to make it as easy as possible.
 
Thanks for that info. The file that one can work on to change the kernel parameters is menu.lst.

The task as I see it is to modify this file to try and achieve a few things: boot without the matrox drivers being loaded, and boot so that a grub menu becomes visible at boot time.

If one can make the grub menu visible at boot time, on every boot, then it becomes much easier or even just possible to stop the boot, make modifications to try, and then continue the boot. As the machine is at the moment, as I understand it, it just boots without menu straight into the system.

Next thing is to get to the menu.lst file, open it with a text editor and see what we need to change. The text editor likely on the system is vi, or hopefully, vim, and it can be tricky. First, it's best to make a back up of the original file so the system can be reverted to original if all else fails:

The following commands should mount the partition, change directory to the boot directory, run ls to see the files in the directory, see the grub directory, change directory to the grub directory, run ls to see what files are there and ascertain that the file menu.lst is there. Then make a copy of the original file with a suffix to identify it as the original file.
Then print the contents of the file on screen, and bring that back here so we can see exactly what we can change:
Code:
mount /dev/sda1 /mnt
cd /mnt
cd boot
ls
cd grub
ls
cat menu.lst > menu.lst.ORIG
cat menu.lst

Things I expect are open to change:
If it has the config "hiddenmenu", it can be stopped from hiding the menu.
If there's a "timeout" config, it can be configured to hold the menu on screen for a specified time, e.g. 30 seconds.
Alter the kernel parameters.

It's as well to remind you to have a look at the BIOS and see if there is an option in there to select an installed video card or the onboard one. If there is, then one has more control over this venture. If not, we are relying on some automatic software which may or may not be perfectly functional.
 
Last edited:
I was able to use vi to change the timeout to 9 seconds and then press ESC during a reboot and now see a menu where I can "enter the selected OS" or press e to edit the commands before booting.
 
Great to get so far. It doesn't seem like there's a GUI on the machine, rather it's running a framebuffer, which is what the matroxfb is providing.

You are now in a position to test different video options. I guess that the machine includes an intel framebuffer, called: intelfb since it's an intel graphics card onboard.

Here's some info on it: https://www.kernel.org/doc/Documentation/fb/intelfb.txt. You could for example, replace the matroxfb with the intelfb and see if it gets up.

I'm uncertain whether the intelfb can run the same vesa mode (of 0x1B8), from "video=matroxfb : vesa : 0x1B8", so it's experimental territory.

After having made a copy of the original menu.lst, as advised above, experimentation is possible which can always be reversed by renaming the backed-up file back to its original name.
 
Great. Does it matter where I change the "video=matrox..."?

I can change it in vi, or in the menu I am currently in, which I think is grub?
 
I changed the "video=matroxfb" to video=intelfb using vi and it still wont boot without the matrox called installed. It does boot with the Matrox card installed, leading me to believe that the framebuffer is not the issue.
 
jacmeenon wrote:
Does it matter where I change the "video=matrox..."?
You can change it in at least two ways. You can mount the filesystem through the rescue disk, or much easier is to halt the boot with grub and edit from there.

I changed the "video=matroxfb" to video=intelfb using vi and it still wont boot without the matrox called installed. It does boot with the Matrox card installed, leading me to believe that the framebuffer is not the issue.

What comes to mind is perhaps it's the particular matrox card that you have that is unsatisfactory, and if you could replace it with one known to be flawless, you could see if there's a difference.

I guess another step I would take is to inspect the modules that are in the filesystem to see what's there that can be loaded by the kernel without having to install anything else. The filesystem is very unusual from my experience so to install something else on it would need some careful work I think.
 
The above screen shot is what I get at the end of it trying to boot without the Matrox card installed, and booting into grub and then choosing the "linux" boot from the grub menu.
 
The DirectFB library needs to be accessed, and I can't say why it isn't. At the "home" of DirectFB at: https://github.com/deniskropp/DirectFB, this text appears:
To take full advantage of hardware acceleration, a Matrox G200/G400/G450/G550 graphics card is recommend for this version of DirectFB.
which sounds rather ominous for other video cards on your system. At a guess, the installation you have appears tightly tied together with the hardware.
 
@jacmeenon :-

Taking Osprey's observations on board, it appears that what you have there is a totally 'custom' build.....a machine commissioned by someone who had an extremely specific use-case in mind, along with some highly specific conditions for its operators.

It's entirely possible to 'strip-back' a Linux kernel at build/compile-time to such an extent that it will only successfully function with a very small subset of hardware combinations. This makes it smaller; it boots faster, and there's fewer attack vectors. I'm thinking there's a 'bare-bones' OS there; only what's needed to run the hardware and operate the custom GUI (hence the use of a framebuffer rather than the full "X" server). On top of all that, it's been 'locked-away' by the simple expedient of removing ALL the usual methods for accessing the OS. And it's been made as easy-to-use as possible by the operators; you hit the power button, it comes on almost immediately, and you start using it straight away.

When this was built, all those years ago, we hadn't yet reached the current manufacturer attitude.....which is "planned obsolescence". Things are now designed to only last so long, then no more; in other words, manufacturers generate future repeat business by deliberately building things to fail after x number of cycles.

I'm betting this device has probably outlasted expectations, and kept going for longer than anyone would have believed possible.....

One question. You've outlined for us how it starts. Out of curiosity, how does it shut down in normal use? Do you simply turn the power button to the 'Off' position?


Mike. :)
 
Last edited:

Members online


Latest posts

Top