OS2 World Community Forum

WebSite Information => Article Discussions => Topic started by: Martin Iturbide on December 06, 2015, 06:14:53 am

Title: [Arca Noae] Checked your disk lately?
Post by: Martin Iturbide on December 06, 2015, 06:14:53 am
Reference: [Arca Noae] Checked your disk lately? (http://www.os2world.com/index.php?option=com_content&view=article&id=21175:arca-noae-checked-your-disk-lately&catid=79:general&Itemid=518)

It is a great milestone for DFSee to support GPT, but I'm still thinking how useful will be that for OS2-eCS-BlueLion installation.

I'm guessing that it should be useful for someone to boot from USB/CD and with DFSee try to repartition and already partitioned HDD (by Windows or Linux) and resize partition to fit OS2-eCS-BlueLion. (and of course use all the great features of DFSee on a GPT drive) But once you boot the Installer will it recognize the installation partition on GPT or after installing the OS, will it boot?

I was told that what we are missing is to create some GPT driver like a FLT (Filter Device Driver). Will a  GPT.FLT driver will work without having UEFI support?

Quote
We at Arca Noae would like to thank ...., and OS/2 VOICE for its ongoing community support.

I really do not know the formal relationship between Arca Noae and OS2VOICE, I'm getting jealous about it  :P

I personally want to thank Steve Wendt from OS/2 Warp New and Rumors (http://os2news.warpstock.org/), the people from Italy behind eCSoft/2 (http://www.ecsoft2.org/) and the people that uploads their software to hobbes and netlabs for their great "ongoing community support", and super special thanks to the developers that shares their software and don't hide their source code to the public.

Regards
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Michaelhz on December 06, 2015, 01:11:37 pm
I personally want to thank Steve Wendt from OS/2 Warp New and Rumors (http://os2news.warpstock.org/), the people from Italy behind eCSoft/2 (http://www.ecsoft2.org/) and the people that uploads their software to hobbes and netlabs for their great "ongoing community support", and super special thanks to the developers that shares their software and don't hide their source code to the public.
Fully agree on this statement. I really get concerned about ArcaNoae's new attitude. Instead of working on their own roadmap (https://www.arcanoae.com/roadmap/), they announce a new version OS/2. My drivers and software package license expires soon, nearly nothing from roadmap was realized (except of pre-beta network drivers).
Important software repositories went away from netlabs (like USB-drivers, we no have two different repos, AHCI and ACPI). So if ArcaNoae suddenly decides to drop any OS/2 Activity, we have nothing in our hands.
This reminds me very much of Mensys, many announcements, no substantial progress, no transparency.
Bitwise is doing a much better job here, you can follow each development step easily (see Mozilla @github or vbox @ netlabs).
I really doubt if I still want to continue to invest money in the products of ArcaNoae.

Michael


Title: Re: [Arca Noae] Checked your disk lately?
Post by: Greggory Shaw on December 06, 2015, 05:29:34 pm
...
I really doubt if I still want to continue to invest money in the products of ArcaNoae.

Michael

How about you actually let them have a chance first of all - and a deal with Big Blue is no small deal.

And you're right they're about the last devoplers, so again how about a little support first.

Greggory
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Pete on December 06, 2015, 05:44:44 pm
Hi All

Unlike Michael I am reasonably happy with my recent Arca Noae subscription - at the moment.

I have downloaded and installed updates to ACPI, AHCI, Multimac, USB, Uniaud and JFS from the driver pack and am happy with most of these updates.

However, I have bumped into a couple of JFS problems that have made me revert to an earlier JFS release.

The Problems

1] The JFS /AUTOCHECK:+* switch is no longer honoured. This means that it is impossible to *force* chkdsk on drives that are Dirty but marked as Clean. This had been reported by someone else and the result is *unsatisfactory* with the bug marked as Resolved:-

Resolution:  won't fix
Comment:  Regardless of whether you consider it a defect fix, an enhancement, or just a change in operation, this is how it works now.

I have opened a new bug about this problem and hope that Arca Noae rethink and resolve this problem. It is silly to need to boot from another device, ie CD/DVD, in order to chkdsk a Dirty but marked Clean drive.


2] Since installing this JFS release  my system often "loses" a drive volume at boot. I have JFS formatted volumes G: through L: with H: and L: being bootable. About 1 in 3 boots I notice that G: is not mentioned at all during the JFS chkdsk display.
Once booted I can get G: to display in the Drives folder by running LVM and then exiting using Save and Exit - with no changes made and - Voila! drive G: appears in the Drives folder.

This is clearly undesirable behaviour by the JFS driver and needs fixing.

How do I know this is related to JFS 1.09.06?

Simple: It does not happen with any earlier release of JFS.


I have reverted to the jfs installed by eCS2.2beta2 - JFS 1.09.05 - and suggest that anyone else having any form of hard drive problems with JFS 1.09.06 - whether local or usb attached - reverts to any earlier build to see if the problem(s) go away.


Plugging DFSee as a disk fixer when you are supplying what in my view is a dodgy filesystem driver is a bit rich   ;-)

Depending on how Arca Noae resolve these problems will affect whether I stay happy with Arca Noae.

Regards

Pete
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Andreas Schnellbacher on December 06, 2015, 06:09:25 pm
1] The JFS /AUTOCHECK:+* switch is no longer honoured. This means that it is impossible to *force* chkdsk on drives that are Dirty but marked as Clean.
My technical opinion: Note that with '+*' you can't force anymore any clean-marked volume being checked at all, regardless if it's dirty or not.

When a dirty boot volume is marked clean, it's time to boot from another volume and perform the chkdsk from there. If that would happen for other volumes, you have now also to boot to another volume for that. Is that really that important? How many times happened that for you?

2] Since installing this JFS release  my system often "loses" a drive volume at boot. I have JFS formatted volumes G: through L: with H: and L: being bootable. About 1 in 3 boots I notice that G: is not mentioned at all during the JFS chkdsk display.
Once booted I can get G: to display in the Drives folder by running LVM and then exiting using Save and Exit - with no changes made and - Voila! drive G: appears in the Drives folder.
I would give David at least a few weeks time to investigate this and to react to your recently posted bug.

I agree with you that this needs fixing and if it's somehow reproducible, chances are not bad to fix it.
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Lewis Rosenthal on December 06, 2015, 07:24:56 pm
How do things get so taken out of context?

Let me see if I may set the record straight on a number of issues:

It is a great milestone for DFSee to support GPT, but I'm still thinking how useful will be that for OS2-eCS-BlueLion installation.

Well, we are planning GPT support in Blue Lion, and are working on that very issue right now.


I'm guessing that it should be useful for someone to boot from USB/CD and with DFSee try to repartition and already partitioned HDD (by Windows or Linux) and resize partition to fit OS2-eCS-BlueLion. (and of course use all the great features of DFSee on a GPT drive) But once you boot the Installer will it recognize the installation partition on GPT or after installing the OS, will it boot?

That's the plan. It's a tall order, and requires a number of things to be updated, but we are working on it (really).

I was told that what we are missing is to create some GPT driver like a FLT (Filter Device Driver). Will a  GPT.FLT driver will work without having UEFI support?

I don't know who told you that.

Quote
We at Arca Noae would like to thank ...., and OS/2 VOICE for its ongoing community support.

I really do not know the formal relationship between Arca Noae and OS2VOICE, I'm getting jealous about it  :P

Martin, you know the relationship which Arca Noae has with OS/2 VOICE. Let me run it down once again:


...super special thanks to the developers that shares their software and don't hide their source code to the public.

Is this meant as some sort of a dig at those of us who are bound by copyright and existing license not to release everything as open source?

I really get concerned about ArcaNoae's new attitude. Instead of working on their own roadmap (https://www.arcanoae.com/roadmap/), they announce a new version OS/2.

I'm sorry that our "new attitude" concerns you, Michael. Our overall roadmap does need some updating (admittedly, we spend more time developing than updating the roadmap, and often progress isn't reflected there in as timely a fashion as we'd like). However, work on Blue Lion complements our overall goal of bringing new drivers and support for current hardware to the platform; these two concepts are not at all at odds with one another.

My drivers and software package license expires soon, nearly nothing from roadmap was realized (except of pre-beta network drivers).

Do you somehow feel like you have not received a good value for your investment? Updates to ACPI, Multimac, and USB have not been useful to you? A roadmap is just that: a plan. It's not a promise. We have made progress toward many of the goals we set before us, though not all have been realized.

If you don't feel that you have received a good value for your investment, then you should feel free not to renew your subscription. Subscriptions were never intended as "support" contributions to further our own goals, but rather reasonable fees set for the products released. We have issued several updates to various components of the subscription during the year. If you have not benefited from them, then perhaps you shouldn't renew your subscription.

Important software repositories went away from netlabs (like USB-drivers, we no have two different repos, AHCI and ACPI).

Really? How about:

http://trac.netlabs.org/acpi
http://trac.netlabs.org/ahci
http://trac.netlabs.org/usb

Lars posts his USB builds to that Netlabs project as well as to Hobbes. It has been the case for some time that we have had two different branches of the USB dev tree. The only difference now is that they are maintained in two different places.

There is nobody stopping anyone from contributing to the AHCI and ACPI projects at Netlabs. Those projects are not going away. It's just so happens that the sole maintainer of them happens to be a principal in Arca Noae, so development has moved "in-house."

So if ArcaNoae suddenly decides to drop any OS/2 Activity, we have nothing in our hands.

Hmmm... An OS/2-only company dropping OS/2 activity. That doesn't sound very realistic, now does it? Again, the maintainer of these driver projects is a human, and if you look closely at the license strings contained in your drivers, you will see that David claims copyright and Arca Noae simply licenses his work. If Arca Noae were to close up shop tomorrow (which is not very likely, especially considering the considerable sum of money we recently paid to IBM), in all likelihood, David would still continue to maintain those drivers; they're not going away.

This reminds me very much of Mensys, many announcements, no substantial progress, no transparency.

Excuse me?

We are a privately-owned company. We are not required to be transparent. That said, do you not read our blog posts? Did you not see the several Warpstock and Warpstock Europe presentations which we have given? David has often shared his progress on driver development. Steven Levine has discussed at length our plans for SNAP and the immense hurdle he has before him getting the code checked into the repository (code for which Arca Noae paid a tidy sum to license). I have discussed the Package Manager (due for release this month, free for everyone to use) and Blue Lion (which, BTW, now has a bootable image in alpha stage, with functional networking to provide across-the-LAN or across-the-WAN installation).

No substantial progress?

We have full time developers working on code - RIGHT NOW.

Bitwise is doing a much better job here, you can follow each development step easily (see Mozilla @github or vbox @ netlabs).

Do you know who provides the bulk of the financial support for Bitwise's Firefox work? Arca Noae does. The difference is that Bitwise has a current focus on Firefox, which is fully open source, and we are working with much of IBM's code, which is not. Portions of the drivers we maintain are not open source. This isn't our fault; we're just playing within the rules set before us.

I really doubt if I still want to continue to invest money in the products of ArcaNoae.

Again, if you feel that you haven't received a good value for your investment, you shouldn't renew your subscription. It's not charity. We believe in a fair price for a reasonable service. If our service has somehow fallen short in your experience, then please accept my apologies on behalf of the entire Company, and feel free not to renew your subscription.

How about you actually let them have a chance first of all - and a deal with Big Blue is no small deal.

And you're right they're about the last devoplers, so again how about a little support first.

Thanks, Greggory, for recognizing what an herculean task this is.

Unlike Michael I am reasonably happy with my recent Arca Noae subscription - at the moment.

I have downloaded and installed updates to ACPI, AHCI, Multimac, USB, Uniaud and JFS from the driver pack and am happy with most of these updates.

Glad to hear that, Pete.

1] The JFS /AUTOCHECK:+* switch is no longer honoured. This means that it is impossible to *force* chkdsk on drives that are Dirty but marked as Clean. This had been reported by someone else and the result is *unsatisfactory* with the bug marked as Resolved:-

Resolution:  won't fix
Comment:  Regardless of whether you consider it a defect fix, an enhancement, or just a change in operation, this is how it works now.

I have opened a new bug about this problem and hope that Arca Noae rethink and resolve this problem. It is silly to need to boot from another device, ie CD/DVD, in order to chkdsk a Dirty but marked Clean drive.

David and I have differing views on this, but David is thoughtful and reasonable. It had not been his experience that forcing a check on an otherwise-clean-appearing volume has had any positive result. Several of us have made the case that our experience has been different.

I'm going to go out on a limb here. We have weekly staff meetings (except for this past week, due to my own inability to make the meeting). I will add this to our next meeting agenda, and we'll discuss it.

2] Since installing this JFS release  my system often "loses" a drive volume at boot. I have JFS formatted volumes G: through L: with H: and L: being bootable. About 1 in 3 boots I notice that G: is not mentioned at all during the JFS chkdsk display.
Once booted I can get G: to display in the Drives folder by running LVM and then exiting using Save and Exit - with no changes made and - Voila! drive G: appears in the Drives folder.

This sounds like there is some corruption possibly fixable with a full chkdsk run after boot or a forced chkdsk as described above. I'll have a look at the ticket for this one, and see if there's anything constructive which I might be able to add.

This is clearly undesirable behaviour by the JFS driver and needs fixing.

How do I know this is related to JFS 1.09.06?

Simple: It does not happen with any earlier release of JFS.


I have reverted to the jfs installed by eCS2.2beta2 - JFS 1.09.05 - and suggest that anyone else having any form of hard drive problems with JFS 1.09.06 - whether local or usb attached - reverts to any earlier build to see if the problem(s) go away.

JFS 1.09.05 (and prior) has/have a serious and known defect which can cause complete loss of a JFS volume. While it may address the issue you are seeing above, it's a poor long-term solution, IMO.

Plugging DFSee as a disk fixer when you are supplying what in my view is a dodgy filesystem driver is a bit rich   ;-)

Hmmm... Dodgy filesystem driver? That's a bit "rich," now isn't it? DFSee doesn't address the issues here, and DFSee is a third-party tool. It's not like we developed DFSee at the expense of "fixing" our own software. DFSee is a multi-purpose, multi-platform tool; the only relationship between the two is that DFSee recognizes and can address certain JFS issues.  ;)

Depending on how Arca Noae resolve these problems will affect whether I stay happy with Arca Noae.

Fair enough! Let me see what we can do.

My technical opinion: Note that with '+*' you can't force anymore any clean-marked volume being checked at all, regardless if it's dirty or not.

When a dirty boot volume is marked clean, it's time to boot from another volume and perform the chkdsk from there. If that would happen for other volumes, you have now also to boot to another volume for that. Is that really that important? How many times happened that for you?

This is an excellent point, worth making, Andreas; thanks for stating it so succinctly.

Forcing a check on a clean volume is really a shortcut to deal with the underlying problem. There is no substitute for a good maintenance partition or rescue system (we are planning a robust rescue & recovery environment for Blue Lion, BTW, with a reasonable set of tools, networking support, and the ability to really fix things on the live system, so that even if a serious problem makes it impossible to boot from a maintenance partition, the user has a decent chance of getting up and running again, just from a CD or USB boot).

2] Since installing this JFS release  my system often "loses" a drive volume at boot. I have JFS formatted volumes G: through L: with H: and L: being bootable. About 1 in 3 boots I notice that G: is not mentioned at all during the JFS chkdsk display.
Once booted I can get G: to display in the Drives folder by running LVM and then exiting using Save and Exit - with no changes made and - Voila! drive G: appears in the Drives folder.
I would give David at least a few weeks time to investigate this and to react to your recently posted bug.

I agree with you that this needs fixing and if it's somehow reproducible, chances are not bad to fix it.

Indeed.
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Pete on December 06, 2015, 08:58:58 pm
Hi

@Andreas

I have had 2 instances of needing to boot from DVD to chkdsk "Dirty but marked Clean" volumes twice since installing JFS 1.09.06 on 15 November - Uninstall happened 2 December after the umpteenth "lost volume at boot" and I lost patience with this JFS package.

Booting from another device - experience says forget trying to boot from another volume on the hard drive - should not be necessary; previous versions of JFS honoured the /AUTOCHECK:+* switch and performed chkdsk against the drives regardless of whether they were marked dirty or not.

This version requires the user to waste time booting from CD/DVD - pointless trying to boot from a different "Dirty but marked Clean" volume on the system as the problem is identical - run chkdsk to correct problems, then reboot to the hard drive.

With a JFS package that honours the /AUTOCHECK:+* switch the chkdsk is performed during boot and the system then boots with Clean volumes. How long does this take? - a lot less than the time wasted if having to boot from eCS CD/DVD to pre-boot menu, select hardware/location, boot to the Maintenance Console, open a cmd window, perform chkdsk(s), exit cmd window and then reboot to hard drive.


I am sorry but this behaviour of JFS 1.09.06 is not acceptable; the /AUTOCHECK:+* switch should be honoured and full chkdsk performed.


With regard to the "lost at boot" volume I would normally be happy to test and provide results for David when he is ready.



@Lewis

The point Andreas made is that JFS 1.09.06 does not support the /AUTOCHECK:+ switch but he does not state why, just his preference for booting from a different drive if that happens to his system.


It has been my experience, and I would expect others to agree, that forcing a full chkdsk on a volume which is Dirty but marked Clean has very Positive results: A Clean volume that can be used immediately; after chkdsk the system boots and everything works fine - I will add "usually" here as there are bound to be the odd exceptions in a group of users over a period of time.

I believe that was the original intention of the /AUTOCHECK:+ switch - up and running without fannying around with external media eg floppies, CD, DVD - and it has always worked fine for me.

If there is a/are any  good reason(s) why this behaviour has suddenly become undesirable I am interested in hearing/reading it/them.

Another thought: How many modern OS's have to be booted from CD/DVD/USB/Whatever/Floppy(?) in order to run a chkdsk? Sounds a bit 1980s to me... especially as OS/2 systems seem to have had this capability a long time.


Could the "lost volume" be a result of this chkdsk failure? Possibly...

I tend to suspect the possibility that JFS 1.09.06 does not get shutdown properly sometimes during system shutdown or reboot although all seems to work properly. I base this idea on the recurring "lost volume" plus the fact that when I have needed to perform chkdsk at boot the system had been shutdown successfully on both occasions. Worth noting is that all volumes, G: through to L: inclusive were "Dirty marked Clean" on both occasions.  Maybe this is the "underlying problem"...

This renders the idea of booting from a "Maintenance" volume or another system volume un-workable as all volumes have the same problem.


My " dodgy filesystem driver" comment was an attempt at mild humour rather than a full scale "dig" at Arca Noae - Sorry if it was misunderstood; my following comment was genuine  :-)


Regards

Pete




Title: Re: [Arca Noae] Checked your disk lately?
Post by: Sigurd Fastenrath on December 06, 2015, 09:47:54 pm
Reference: [Arca Noae] Checked your disk lately? (http://www.os2world.com/index.php?option=com_content&view=article&id=21175:arca-noae-checked-your-disk-lately&catid=79:general&Itemid=518)

It is a great milestone for DFSee to support GPT, but I'm still thinking how useful will be that for OS2-eCS-BlueLion installation.

I'm guessing that it should be useful for someone to boot from USB/CD and with DFSee try to repartition and already partitioned HDD (by Windows or Linux) and resize partition to fit OS2-eCS-BlueLion. (and of course use all the great features of DFSee on a GPT drive) But once you boot the Installer will it recognize the installation partition on GPT or after installing the OS, will it boot?


One of my plans with my "own OS/2 distribution" was to include DFSEE and QSINIT in the boot process.

QSINIT has some kind of "EFI" support included, if that could be activated with OS/2 one would need a disk partitioning tool in the next stage of the OS/2 installation process. For this DFSEE is (and was allways) for me the one and only choice - if DFSEE is able to handle GPT now - that's the best news to have in case one would like follow this road.

As I succeded with QSINIT (integrating it in the boot process of the DVD, NOT EFI!!!) I failed with adding DFSEE to the boot image.

Some time another plan came to my mind:

The best (and easiest, fastest and so on) way to install was

- NOT with Floppy Disk
- NOT from CD
- NOT from DVD

-> it was and is copying an image that has been cloned before with DFSEE on the HDD

So, If I would have a chance (and time and resources...) to produce a new OS/2 distribution I would:

- create an USB Stick that boots with QSINIT
- that includes DFSEE that is integrated in the QSINIT Menue
- that includes an "Universal OS/2 clone" (I do have one for me, that has been cloned with DFSEE, and uses QSINIT as Bootsystem/Loader)
- that can be restored then on the HDD of the PC

I tried something similar with a Linux System on USB Stick, but using DFSEE with it was really hard (for me).

Anyway, I am really looking forward to see what Arca Noae will present us during the next year, and If I can be of any help I would appreciate to do so. I am happy that there are people moving on and pushing things forward - and do have a plan. And this is exactly the other way round compared to what Mensys did during the last 5 years.

When it comes to JFS I would like to add: I am working with HPFS386 as the file system of the Boot partition (the clone) for years now.

When it comes to OS/2 Voice I would like to add that I (even if this is the largest OS/2 User group in the world) have no other point of contact than knowing that this organisation organizes Warpstock Europe (as Roderick Klein do now at OS/2 Voice what he has done before at Mensys) and that they sponsor some things. When it comes to "daily business" I personally do benefit much more from the person Martin mentioned, in addition to himself and those running the german os2.de forum. Loosing the forums here at OS2world or OS2.de or the "OS/2 Warp News and rumours" of Steve Wendt or hobbes (and all the other OS/2 Sites around) would hit me really.




Title: Re: [Arca Noae] Checked your disk lately?
Post by: Lewis Rosenthal on December 06, 2015, 10:53:43 pm
Another thought: How many modern OS's have to be booted from CD/DVD/USB/Whatever/Floppy(?) in order to run a chkdsk? Sounds a bit 1980s to me... especially as OS/2 systems seem to have had this capability a long time.

When there is a serious error, many OSes need to be booted from alternative media, actually. The fact that the OSes generally do not state the requirement doesn't mean that they should not be handled in this fashion. I've dealt with more than my share of broken Windows systems where NTFS needed to be checked from something other than the boot partition because, well, they wouldn't boot. I've also had *nix systems (running JFS, Reiser, XFS, and EXT4, though not BTRFS - yet) need to get up and running fully and then have to go back and run a manual check against the disk. The difference is that *nix systems don't normally put so much data on the boot partition and what is there doesn't change as often as on other systems.

I tend to suspect the possibility that JFS 1.09.06 does not get shutdown properly sometimes during system shutdown or reboot although all seems to work properly. I base this idea on the recurring "lost volume" plus the fact that when I have needed to perform chkdsk at boot the system had been shutdown successfully on both occasions. Worth noting is that all volumes, G: through to L: inclusive were "Dirty marked Clean" on both occasions.  Maybe this is the "underlying problem"...

This is certainly possible, and if so, we'll want to get some low level data to see what's happening so we can do something about it (assuming it's not something specific to only one machine, of course; resources are spread thin as it is, so time tracking down elusive errors should be spent wisely).

This renders the idea of booting from a "Maintenance" volume or another system volume un-workable as all volumes have the same problem.

Understood.

I keep my maintenance partition running 16-bit HPFS just for that reason (it gives me something else which is JFS-aware but not JFS-dependent to use for recovery).

My " dodgy filesystem driver" comment was an attempt at mild humour rather than a full scale "dig" at Arca Noae - Sorry if it was misunderstood; my following comment was genuine  :-)

Apologies if I came on too strong with my reply, Pete; it was unintentional. I know you better than that, and the irony isn't lost on me, considering your lack of success with the updated JFS driver!

Let's see what we can do to address your issues. Forced chkdsk functionality aside, we certainly shouldn't be creating errors, and we want to make sure that's not the case.

Cheers
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Doug Bissett on December 07, 2015, 04:05:10 am
Quote
I tend to suspect the possibility that JFS 1.09.06 does not get shutdown properly sometimes during system shutdown or reboot although all seems to work properly.

This is probably the reason why there is a shutdown option to delay the actual power off. It has been in eCS for quite a while, I think it is really part of X(e)Workplace. Desktop properties-> X(e) Shutdown, near the bottom. It never hurts to use it, but it may hurt if you don't, when you need it (It is definitely a possibility). I am not sure why it is optional, it should always do the delay, to let the system finish what needs to be done before the power is cut.
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Martin Iturbide on December 07, 2015, 04:56:22 am
Hi Lewis

Thanks for the GPT feedback, those are very good news. Something that is very annoying today while installing eCS is the geometry limitations and now GPT lack of support, I really hoping that installing Blue Lion on a dual boot machine will be more easy.

I disagree about your opinion on OS2VOICE. OS2VOICE newsletter stopped being an interesting source of news for the community since some time ago. Today they just wait for the people to post the news instead of looking for them like they were doing on the past. I even got that complains from some people at Warpstock that they are not getting any OS/2 software news anymore because they rely heavily on OS2VOICE newsletter.

That is why I thank the real sites that looks for OS/2 software news like "OS/2 Warp New and Rumors" and "eCSoft/2".

I understand that you can not open source Arca's drivers based on the IBM DDK examples (license limitation). What you can do is give the driver source code that is based on IBM DDK examples to Netlabs and create an "close source" but collaborative driver development repository. So members of Netlabs can have access to that source code and the IBM DDK examples are only shared within that organization. Just like Lars is doing with his USB drivers. If you tell me that Arca's latest ACPI driver source code is already uploaded to the "close source" Netlabs repo, and Netlabs also have rights over it, I'm fine with it.

Multimac and AHCI are GNU GPL projects, any derivative project from it must be open source under the same license. I'm guessing that Netlabs SVNs source code are at the same level of the packages that Arca is distributing, right?

Another thing is that even on open source the author retains all the copyrights over his own works, but they give a distribution right under an specific license. If David gave Netlabs a distribution right on the close source repo that is fine with me. Also, David also needs to give distribution rights of his source code (changes to the IBM examples) to Arca, to reduce the risk in case something happens to him. (Personal opinion, maybe it is already on place)

It will be also interesting if Arca can try to break off from the JFS from IBM and try to improve the GNU GPL one to reduce the risk to depending on that source code.

I also want a long term strategy for the platform, not just drivers and new hardware support, that is only short term.  I don't want to see a Blue Lion just committed to protect the investment of OS/2 users (maybe that is good for the first release), but I want to see a "Blue Lion" committed to open source and the free (as in freedom) access to the platform for everyone. But I don't want to insist on this topic to you since I understand that right now Arca is doing the initial efforts are on the first release of Blue Lion. I insist to the rest of the community that we need to look under the hood and start messing with the OS/2 components that are working fine today (example (http://www.os2world.com/forum/index.php/topic,900.msg8569.html#msg8569)).

Quote
Do you know who provides the bulk of the financial support for Bitwise's Firefox work? Arca Noae does. The difference is that Bitwise has a current focus on Firefox, which is fully open source....
That is also good news, that needs also to be on your announcements to show that Arca Noae is committed to open source. Mensys also used to sponsor some bitwise development (according to rumors), but I don't know why Mensys didn't announce it, like there was some kind of shame to say that they support open source ( I never understood that).

Open source is not for me only a hippie fashion that comes and go to get free of charge software. I see open source as the tool to reduce risk to be left high and dry,  just like IBM and Mensys did with OS/2 and eComStation.

Quote
Is this meant as some sort of a dig at those of us who are bound by copyright and existing license not to release everything as open source?

No, like I told you, I already know the limitation of the IBM DDK. I was thanking the people that I consider that does "ongoing community support" and sometimes we forgot to thank. There are people out there that likes to publish his source code and share their knowledge with the rest... that is real "ongoing community support".

Regards
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Lars on December 07, 2015, 06:16:25 am
Interesting. I did not know that the USB repository is now split. I only know the one at Netlabs.

Lars
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Jochen Schäfer on December 07, 2015, 10:15:46 am
Another thought: How many modern OS's have to be booted from CD/DVD/USB/Whatever/Floppy(?) in order to run a chkdsk? Sounds a bit 1980s to me... especially as OS/2 systems seem to have had this capability a long time.
Actually, you always had to boot from some installation/rescue medium for OS X to fix filesystem problems on the boot volume. Since 2011, Apple automatically installs a recovery system alongside the main system to allow for faster boot into the installation/rescue system.
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Andi B. on December 07, 2015, 11:27:16 am
Quote
With a JFS package that honours the /AUTOCHECK:+* switch the chkdsk is performed during boot and the system then boots with Clean volumes. How long does this take?

Infinite. Or better said, it does not work some times. See other JFS tickets.

Another problem would arise if you have forgotten to detach any USB drive before booting. As you may know chkdsk on an 2TB external USB drive tooks ages to complete.

I understand your wish for /AUTOCHECK:+[BOOTDRIVE] work as you expect. But in contrary /AUTOCHECK:+* would be a really bad choice for people using more and bigger volumes when it would really do what you insist on. 

Of course you can complain that + should work as you expect (and work as it does with other file systems). But as you found out David has a different POV. We can complain about they way David communicated his POV but I'm pretty sure there are much more important stuff to do....

Maybe you would not be so upset if David had answered to the '+' ticket something like that - Sorry I've implemented + in JFS different cause we've observed some troubles with this or that and it seems a good choice to do it that way and I do not want to spent any time to work on this again as it it such a minor issue and only so little people will suffer from and most of them do not have a big problem to work around in these so very very rare cases.....

Hope this calms down these JFS threads a bit.
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Pete on December 08, 2015, 02:11:26 am
Hi

@Lewis

Having a HPFS based "rescue" volume would certainly get around jfs chkdsk problems... I've got some free space on a disk and will implement that.


@ Doug

I must admit to never having used the Delay option at all - never even looked at it until I had read your message. I will reinstall JFS 1.09.06 and check that Delay option to see if it helps.


@ Andi B.

I can only say that I have not had any problems with the /AUTOCHECK:+* switch but appreciate that different systems with different hardware and different size volumes may behave differently.

The largest USB drive I have is 1Tb and it can seem to take a long time to chkdsk during boot - had a system crash a few weeks ago with this drive attached - but the reality was that it took around 5 minutes with the 6 volumes on the internal drive, around 750Gb, taking a little less. The USB and internal drives are not very full though, with a bit over 60% capacity available on them.  No, I do not have a 2Tb drive to experiment with - I'm happy to believe you that it could take a lot longer than 2 * 1Tb chkdsks  :-)

Certainly a mention of this change in the readme with a brief reason for the change would have prevented me from discovering the change the hard way - when it did not work  :-)


I do not see the removal of this switch as a "deal breaker" - simply a bit of an inconvenience. However, the idea of a HPFS formatted "rescue" volume is probably the way forward as it seems that when I need a boot CD/DVD I always end up playing a game called "now where did I put that?"  :-)


Regards

Pete


Title: Re: [Arca Noae] Checked your disk lately?
Post by: Andi B. on December 08, 2015, 11:54:50 am
I can't remember when I used xwp shutdown delay the last time. There should be no additional delay necessary with current xwp and current ACPI. See what David says about ACPI shutdown. https://www.arcanoae.com/wiki/acpi/requirements/

If shutdown does not work reliable for you then I would suggest to open a ticket for ACPI. Of course only if it reproduceable with  "acpistat poweroff" as stated in the wiki. If shutdown work with this but does not work with latest xwp beta then I would be interesting too. 

I use xwp settings 'ACPI shutdown' and 'xwp new ini file routines'.
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Doug Bissett on December 08, 2015, 06:15:37 pm
Quote
There should be no additional delay necessary with current xwp and current ACPI.

Some years ago now, I did have a problem with a new machine, where it was getting the power turned off before the disk finished writing something. I didn't see any reason not to use the delay (obviously it was implemented for some reason), so I just started using it always. I still don't see any reason not to use the delay, it is definitely safer than not using it. Note that turning off the power, before the disk has finished writing, is not the same as not being able to load the power off module because the file system had been shut down. It sounds like Peter's problem is that the power is going off before the disk is finished, so the delay may be necessary (worth trying anyway).

I will note, that not all machines use ACPI. My ancient ThinkPad A22e doesn't use it, and it looks like it might need the delay (but I haven't tried without it, for a long time). I will also note, that that machine does suspend/resume, with no problem, and has done so since Intel fixed their network driver, oh so many years ago. I have yet to get a modern machine to do that.

While I am at it, I have one old machine that will not power off using ACPI, or APM. It goes through the routine, and something clicks when it should go off, but it just does a power on again. Of course windows will power it off, and even using DEL when Air Boot opens, will power it off. The delay makes no difference. I will note, that windows XP refuses to use ACPI, but eCS uses it with no problems, other than it won't complete a power off. Very strange...
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Pete on December 08, 2015, 06:28:55 pm
Hi Andi B.

Well, ACPI seems to work fine here - although I have just discovered the /VW switch is required in order for the Marvell 88SE9172 eSATA controller to be available to the system.

The mainboard uses the AMD 990FX / SB950 chipsets which, i seem to recall being told by Lewis in an email, are "untested but expected to work" with current ACPI.

At the moment a shutdown problem is the suspect so although I have never needed tthe XWP Shutdown Delay option before I will give it a try in order to try and establish whether the problem is caused during shutdown.


Regards

Pete
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Lars on December 08, 2015, 11:29:37 pm
Just a guess: there is always the chance that shutdown will be prevented by USB host Controllers that are still active and therefore accessing memory. The fact that some HW device is still reading from / writing to memory (USB host Controllers are busmaster capable) is enough to make shutdown fail. This is true in general for any other busmaster capable device (in short: a busmaster capable NIC still being active might exhibit the same problem).
It's always worth a try an specify /FS on every USB host Controller Driver line in config.sys. This switch will halt the host Controller and therefore will prevent it from touching memory.

In a perfect world, all OS/2 drivers serving busmaster capable devices should disable busmaster capability on shutdown. But not every driver does so ...

Lars
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Andi B. on December 09, 2015, 09:58:01 am
Quote
Some years ago now, I did have a problem with a new machine, where it was getting the power turned off before the disk finished writing something. I didn't see any reason not to use the delay (obviously it was implemented for some reason)...
Honestly I do not know how long the xwp delay will be when the button is checked. Is it configurable?

Anyway I vaguely remember a discussion for giving flash based storage devices enough time to write there cache to the flash cells. Since a long time there is a delay in xpw shutdown for this marked with [SHL]. I think I set his value in my last beta builds from 200ms to 500ms for safety reason. Older source code has bigger values there but sometime SHL decided 200ms is enough. I guess for good reasons ;) This was at the time as the ACPI memory swap out problem was started to be solved.

From Lars post I now think my occasional shutdown problems does have not have anything to do with the delay but with USB. I supposed it before as it seems they only show up when I use my external USB drives. So for my next xwp build I reduce the delay in xwp to the value Steven has found to be enough.

Bottom line - delays and values seemed to be discussed and changed for more than 5 years now. If there is a delay needed more than the 200ms then this should be hardcoded in xwp. A few hundred ms are hardly noticed by the user anyway. If there is no reason other than a workaround for other drivers fault, then this has to be discussed and solved in that driver.
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Doug Bissett on December 09, 2015, 06:45:56 pm
Quote
Honestly I do not know how long the xwp delay will be when the button is checked. Is it configurable?

It is 4 seconds, and produces 4 beeps when it happens.

Quote
If there is no reason other than a workaround for other drivers fault, then this has to be discussed and solved in that driver.

I don't think it is the driver that was causing the problem that I had, a few years ago (and I suspect that this might be Pete's problem). It seemed that the driver thought all disk activity was done, but the drive still had some stuff in it's internal cache when the machine finished processing the shutdown, and cut the power. The delay fixed that problem, and 4 seconds at shutdown is hardly noticeable. It probably doesn't need to be more than 1 second, but machines are getting faster, and disk caches are getting bigger, so some delay is probably a good thing. Why not use more time than anybody might think is necessary. 200 ms might be enough, most of the time, but so is 1000 ms. 199 ms may not be enough. Who really cares how long it takes to shut down a machine, as long as it gets done right. This is not a race. Well, I suppose it is a race between getting all of the data written, and pulling the plug. Getting all of the data written is much more important than pulling the plug.

I will note, that I have always had to use /FS on the USB drivers, in that same machine, or the BIOS, very often (3 out of 5), would hang on initializing the USB stuff on a warm boot. It is very rare to have any USB device attached at shutdown (except for the mouse, and the UPS). I never really saw any other problems with USB. BIOS still has a problem initializing the USB, but it is about 1 in 100 with /FS. I have used /FS on other machines, and it doesn't make any difference, so I would suggest that /FS should be the default (why not?).
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Andi B. on December 11, 2015, 09:52:31 am
Quote
It seemed that the driver thought all disk activity was done, but the drive still had some stuff in it's internal cache when the machine finished processing the shutdown, and cut the power. The delay fixed that problem
To my understanding that was the reason why SHL added the delay in xwp code. It's another story that this version of xwp source code never found the way to the public until I started uploading betas.

Quote
and 4 seconds at shutdown is hardly noticeable. It probably doesn't need to be more than 1 second, but machines are getting faster, and disk caches are getting bigger, so some delay is probably a good thing. Why not use more time than anybody might think is necessary. 200 ms might be enough, most of the time, but so is 1000 ms. 199 ms may not be enough. Who really cares how long it takes to shut down a machine, as long as it gets done right.
This all is a workaround for a problem either not understand or not solved in the right way. I consider workarounds only as second best choice. There must be a proper solution and I've no evidence that Steven ones is not the correct one. I'm happy if you can prove the opposite. But for this you have to -
- use the latest AN ACPI
- and the latest xwp beta
- and the 'apcitool shutdown' has to work reliable
- and xwp shutdown does not
- and xwp shutdown with delay does

If all these things are true then we should discuss the proper value of delay. Otherwise I would suggest Pete to look for a real fix for his problem.

I want to say that I do not post this to offend against someone but only cause I want to fix xwp if it has bugs and make it even more perfect.
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Doug Bissett on December 12, 2015, 01:33:16 am
Quote
To my understanding that was the reason why SHL added the delay in xwp code. It's another story that this version of xwp source code never found the way to the public until I started uploading betas.

It sad that there seems to be no mention of what was changed, or why. Actually, that isn't entirely true, there is a list of things that changed, but the average user (including me) has no idea what it is talking about. Whether 200 ms is enough delay remains to be seen. I am not willing to change my main system, yet, but I will change other, less critical, systems (including the one where I had the problem, but it has a different hard disk now), and see what happens.

In Pete's case, he has a problem that sounds like the one that I had, and adding the delay fixed mine, so he should try it. If it fixes it, and he meets the rest of your conditions, I would suggest a longer delay in XWP. He didn't mention which version of XWP, or eWP, he is using, so the delay may work. In any case, I would suggest that the delay be left in the code, for diagnostic reasons, but it could probably be less than 4 seconds.

Quote
This all is a workaround for a problem either not understand or not solved in the right way.

There are probably 100 (or more) of those in eCS. In a lot of cases, the work around is necessary because there is no way to fix the problems properly.  In other cases, nobody is interested in doing it. And in even more cases, those who might be able to fix them, insist that the problem doesn't exist. I suspect that most of the work arounds come from somebody who can sort it out, who fixed it because they had the problem. The rest of us are left hanging, and anything that somebody can figure out becomes the work around.

While I have your attention, why don't you turn off that annoying animation that is default on XWP shutdown? At least make it so that it is not the default.
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Andi B. on December 13, 2015, 01:49:35 pm
Quote
While I have your attention, why don't you turn off that annoying animation that is default on XWP shutdown? At least make it so that it is not the default.
Cause for me it is not so much annoying to spend any time on it :). Didn't find much in the doc so how can you disable it?
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Andreas Schnellbacher on December 13, 2015, 04:26:13 pm
Desktop -> Properties -> XShutdown -> Shutdown only
Animation  [ ] before shutdown  [ ] before reboot
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Andi B. on December 13, 2015, 07:52:04 pm
Thanks Andreas, I'm blind cause I've overlooked it 2 times I searched for it in that dialog :(.

Anyway, I don't think it would help very much if I change default setting. I'm pretty sure xwp will take over your old settings when you install a new version. As I've deactivated animation years ago I didn't get annoyed by it since a long time ;)

Dough, do this setting got reenabled for you when you install a new version? Then it's a bug of course. Or do you make new installations so often that this is a problem for you?
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Doug Bissett on December 14, 2015, 03:38:29 am
Quote
do this setting got reenabled for you when you install a new version? Then it's a bug of course. Or do you make new installations so often that this is a problem for you?

No, it doesn't change for an update to x(e)WP. I have been doing a lot of new VBox installs lately, while testing things. I usually don't think about it until I shut down, then, I forget again after I start up. It is not really a problem, but it is annoying until I make a specific boot, just to get it turned off. I realize that some new version of OS/2 will be required to get an updated XWP into it, but if it starts now, it will get there eventually.
Title: Re: [Arca Noae] Checked your disk lately?
Post by: Andreas Schnellbacher on December 15, 2015, 09:02:35 pm
I've overlooked it 2 times I searched for it in that dialog
I made the same experience a few years ago. That part of the notebook page seems to be too crowded.