Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Andi B.

Pages: [1] 2 3 ... 46
Completely agree with you Lars ;-)

One note I want to add here - since a while I always check my config.sys (diff) after some installer wanted to change it. There are so many installers which changes libpath and/or path. At least since all these ported software luckily we have, it's a big problem when some installers put something in front of the %unixroot% entries.

(latest ArcaOS release + all modules at latest level)
New clean ArcaOS installation? Then it's best to open a ticket at AN.

I ask this cause I think you're the one with the DVD/JFS/UNICODE ticket we discussed the last days and in this ticket it turned out that you didn't test on a fresh ArcaOS installation but installed these faulty cputemp package which in turn leads to your trap you reported there. That said I fear no one here can guess what your page fault (000E) really triggered. Your memory settings or?

Hardware / Re: panorama not remembering monotor resolution
« on: Today at 12:21:38 pm »
Sorry, I fail to see just how the monitor can communicate with the computer when it is disconnected before and during boot.  Just how does the monitor send EDID when, to all intents it is disconnected which is what I am talking about?

There are no problems if the monitor is powered on when the computer boots.  It is when it is powered off that the problem occurs.
As Doug says it depends on different things. EDID can be read even when a monitor is switched off. It does not matter if stdby or really off (power switch or putting out the power cord completely). For DVI and HDMI it's mandatory that the source (the computer) delivers power to the destination (monitor) which is exactly used for this situation. Reading EDID even when a monitor is switched off. Of course this can't work if the monitor is disconnected (DVI or HDMI cable unplugged).

Unfortunately this situation changed with the invention of Display Port. Beside being a big fan of DP in general, reading EDID now is more problematic. Although there is also specified a power output on all DP connectors it is not intended for reading EDID. These 3.3V (instead the 5V) are also NOT connected on cables conforming DP (VESA) standard. So I see now way how fully switched off monitors connected via DP are able to put back EDID information to the computer. In this case usually the BIOS falls back to 'save' values and may report only low resolutions.

Of course situation is even more complicated when you put some other stuff (KVM, adapters to different interfaces) between computer and monitor. Then it depends on that stuff to report something useful.

Other OSes which have dedicated video drivers do not suffer so much from all these problems as they can read EDID during operation and react appropriately. But we (Panorama) rely on what the BIOS finds at boot up.

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 03, 2022, 05:09:59 pm »
Sorry to hear that. This ticket was from 2017 and dealt with the very same problem. But there it leads to a trap when reading DVDs. It's closed since a long time. I commented there back then. Maybe that's the reason why I see it. I don't want to copy text from there but the bottom line is - it would be good if the original CPUTEMP warpin package would have been tested better. But people make mistakes. The problems with this package are 1) it deletes UNICODE.SYS and 2) it puts rdmsr.sys at the top of config.sys. It should be better places after the IFS lines.

Unfortunately wic -t does not test such failures in a package. But a modified CPUTEMP package should be available from here - Mind I didn't test this. Use it on your own risk! Or search for the latest AND remember to check what an installer does with your config.sys.

By the way - this is a very good example that's not always a good idea to save old versions of packages/drivers...

I think it's not a big problem to copy this one sentence from the ticket - 'The only way for traps to never happen is for humans to never make

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 03, 2022, 11:30:12 am »
I repeat: this is an absolute NOGO for a commercial operating system.
Do you wanna send this complain to IBM or ArcaNoae? :-)

Lars, I absolutely understand your frustration. Really.

But IBM will never change this I fear. I also fear AN will not change the basics of any file system. Moreover I fear they have a lot of stuff to do with higher priorities. But we will see how they respond to the ticket.

For all with access to the ticket system - I think it's worth to read Stevens conclusion on this problem. The ticket should be linked now. Thanks Dave.

Edit - this ticket I meant. Scroll down to the end.

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 02, 2022, 04:00:54 pm »
Waiting for a keypress was a suggestion. You could also do a simple delay of say 30 seconds or so (that would also be possible).
That would be a very good work around. (Solution would be putting back unicode.sys into config.sys when it's not before jfs.ifs). Such 30s delay would be also very useful for ACPI or USB test versions when they outdate. A problem testers are bitten every now and then. F.i. even Keith at his presentation in Colonge...

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 02, 2022, 12:59:15 pm »
There are device drivers that do not continue silently in case of error (I think MAC drivers often expect user confirmation to continue). So this is a general shortcoming and can hit you on all sorts of other occasions.
Yes it is a problem with other drivers too. That's why I'm think about. Specifically with ethernet drivers I often observed this when f.i. they do not find the correct chip. But other drivers too. I think PAUSEONERROR (or similar) can prevent stop the boot process. But using this is no good solution too because you probably wouldn't recognize the error message then as it flies away much to fast on current (< 10 years :-) ) hardware.

Does your system no longer have "legacy USB" support ? I can use the USB keyboard before OS/2 takes over the USB host
controllers ...
It does as long as something (ACPI, USB, ...?) very early in the boot process takes over control until the time when all the USB stuff, including usbhid is initialized (very late). In any case there is a big window during boot where USB keyboards do not work. From all what I understand and all the discussions about that (testers list, AN tickets) this window (non working usb keyboard) can not be eliminated. I never figured out how to sort config.sys to make this window as small a possible. But I got the impression it's impossible to cover all these places where device drivers may fire up this "hit return" message. We have to life with this when we want (or have) to use USB keyboards instead PS/2.

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 02, 2022, 10:23:21 am »
I wouldn't call it ridiculous. I would say this is another shortcoming/bug/problem/nuisance of one part/program of our platform. Of course it may be easy to improve this situation with Lars proposed changes. No clue if David will implement it when Lars creates a ticket.

It's good that Lars shares his experience here to tell others about some problems and how to circumvent it. That's what a forum is good for.

But I also see a lot of other shortcomings. And when I were in the position to give priorities, this one would have a low priority. We only can wait and see what David says about this. Or is there any chance to get access to the latest JFS sources?

display a warning message and even force the user to hit Return to continue boot process
I fear this can be a problem with USB keyboards. The systems I have do not serve USB keyboards (with OS/2) until the end of the boot process. Every such "hit return to continue" condition while booting (while loading all the drivers from config.sys) needs the old PS/2 keyboard which luckily is also attached to step over. Here there is no chance to respond to such messages with the USB keyboard.

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 01, 2022, 05:16:10 pm »
If you fear that something changes your and you overlook to check the changes before reboot you can also start a rexx script from your startup.cmd which parses your current Though I don't know how to find out which file is used by osinit.... But maybe simpler than changing jfs.ifs. Moreover chances are high that the output text from jfs.ifs while booting will be overlooked pretty easy. 

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: November 30, 2022, 03:25:18 pm »
These Umlaut problem hits us OS/2 users since the beginning. The root of the problem is IMO IBMs decision to translate important folders to something with special characters (Arbeitsoberfläche). A lot of us where bitten by this ages before JFS arrived when we simply played with codepage settings in config.sys or CHCP. It's the same with HPFS(386). When you change the codepage setting in config.sys, chances a good that on the next reboot you're Desktop is lost/destroyed. Only difference is - we learned not to do this. Never ever play with codepage setting (at least the first one). We also have to learn not the delete unicode.sys when using JFS. Maybe Martin can delete these package from hobbes. Or when it's really a warpin issue then I think it is solved in current releases. I remember reading about that problem (deleting unicode from config.sys) a while ago.

because I renamed a lot of the originally English named folders to common German names
I hope you don't make this problem worse and don't use umlauts. Even if the meaning of the translation sounds not as exact as it could be, it's far better to use another word and circumvent any special character in (system relevant) file/folder names.

Programming / Re: Building Qt5
« on: November 23, 2022, 08:03:49 am »
Dave, if I understand it correct, the problem is our gcc. So it would be necessary to fix gcc not Qt. What you propose is a work around for a bug in our gcc which only exposes on OS/4 kernel. Correct?

Programming / Re: UEFI and GPT not developed by ArcaNoae - by whom else?
« on: November 10, 2022, 02:50:23 pm »
Good sum up Sigurd. Only -
UEFI BIOS needs GPT HDD Layout (only Exception: The UEFI BIOS uses the CSM Mode if present!)
is wrong I think. I'm not really sure but I think UEFI can work with MBR disks without problems. Only Windoze does not support UEFI without booting from a GPT disk. But....

Programming / Re: UEFI and GPT not developed by ArcaNoae - by whom else?
« on: November 10, 2022, 10:26:55 am »
After seeing the presentation (parts of it) I'm confused too. One thing to remember is UEFI is different thing than GPT. Moreover Secure Boot seems to be another separate thing. Although these three things may come at once with a new Windoze notebook these are separated things.

Programming / Re: UEFI and GPT not developed by ArcaNoae - by whom else?
« on: November 08, 2022, 08:53:37 am »
To my understanding it is developed by (or to be more precise organized by, or developed under control of) ArcaNoae. As usual with a lot of parts in ArcaOS there are some ArcaNoae people involved but also some other developers/testers/translators/volunteers....

Both, UEFI and GPT, needs changes in different places of the OS. So different people work on different tasks. But as far as I can see (mind I don't speak for ArcaNoae) they are all organized by ArcaNoae. Some of them may be paid or not.

Applications / ssh - sshd
« on: October 30, 2022, 06:58:59 pm »
I want to set up a ssh server on my system. I've not much experience with SSH until now. I installed the openssh packages (yum install openssh-servers ..) but can't start the daemon.

I tried all combinations with or without path like p:\usr\sbin\sshd.exe or P:/usr/sbin/sshd.exe ... but I get always -
Code: [Select]
sshd re-exec requires execution with an absolute path

Anyone running successfully an ssh server on OS/2?

Pages: [1] 2 3 ... 46