New initrd.gz for AntiX 15 b3-V LiveUSBs

BitJam · posted: 2015-06-18 06:02

Time is short. It would be great if Dolphin_Oracle, SamK, and skidoo would download
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://www.dropbox.com/sh/l9szqbe3cgab5xn/AACMcn-K6qLfNaHJXG27EFkha?dl=0"
linktext was:"this new initrd.gz"
====================================
, install it on an antiX-15-beta3 LiveUSB and see if it fixes the following problems:

Dolphin_Oracle: does it (still) use the correct xorg driver?
SamK: does X use the sisimedia driver without you needing to give any extra boot options?
skidoo: are you happy with no /live/aufs-ram/.wh..wh.plnk/ directory? You can use the"plink" cheat to return to the old behaviour.

You can install this on a LiveUSB by copying it to /live/boot-dev/antiX/initrd.gz. You might want to back up the original initrd.gz file. If the LiveUSB is plugged into another system then just copy it to the /antiX/ directory on the LiveUSB device. There should be an existing initrd.gz already there.

I suggest you delete any existing /live/boot-dev/antiX/state/ directory and all of its contents before using this new initrd.gz.

I don't know if an existing /live/aufs-ram/.wh..wh.plnk/ directory will get automatically deleted.

Here are the major changes:

Code: Select all

    Update video module detection add code for making sisimedia xorg.conf
    Disable default xorg.conf if we detect hardware for"any" video driver

    Restore state even if persistence is enabled
    Add persist-save.log and live-remaster.log to general-state-files
    Mount aufs with noplink mount option
    Add"plink","noplink" cheats.  Default is"noplink".

    Saving/restoring state
     o Change file lists
     o add comments to file lists
     o Save permissions on vfat liveUSBs
     o Improve mounting LiveUSB if"toram" was used
     o Make"savestate" and"nosavestate" sticky
     o Delete files in state dirs that no longer exist in FS
     o Change save state cheats to: nosavestate, savestate

If you don't want to download it from dropbox, I will be happy to email it to you. It's only 4 meg. Others are, of course, welcome to try it and give feedback. I'm particularly interested in the X driver that gets used. If your hardware supports a particular X driver (such as nouveau, intel, radeon, etc) and that driver is not being used by default, I'd like to know. If X doesn't start or if you end up with the fbdev driver at a resolution of 800x600, I'd like to know that too.

If we can verify that the three problems above are fixed, this will help us short-circuit the development cycle and help us get a really solid antiX-15 out the door before anticapitalista leaves for the summer.

I could also provide an xdelta-3 patch but I think it is much easier to just copy over the initrd.gz if you are already have a running antiX-15-beta3 LiveUSB. I have a bunch of other changes for live-remaster, save-persist and other things but they are not included in the initrd.gz.

We might end up doing several iterations but this is much faster than creating and downloading an entire iso file.

Thanks!

dolphin_oracle · posted: 2015-06-18 10:49

Time is short. It would be great if Dolphin_Oracle, SamK, and skidoo would download this new initrd.gz, install it on an antiX-15-beta3 LiveUSB and see if it fixes the following problems:

Dolphin_Oracle: does it (still) use the correct xorg driver?

yep.

BitJam · posted: 2015-06-18 11:45

dolphin_oracle wrote:yep.

Brilliant! Thank you!

SamK · posted: 2015-06-18 15:42

BitJam wrote:...does X use the sisimedia driver without you needing to give any extra boot options?

No it fails to produce a GUI desktop.

The boot begins normally. During the text phase, it reports

found sis kernel modules
found xorg driver
found video module(s) sis-agp
/etc/X11/xorg.conf file with sisimedia

The boot continues to the login stage, where it fails. The screen is totally blanked with an on-screen message Input Not Supported the system has to be rebooted at this point.

The problem is related to a missing subsection in xorg.conf

Code: Select all

cat / etc/X11/xorg.conf
#----------------------------------------------------------------------
# xorg.conf file
#
# Generated by make-xorg-conf sometime around Thu Mar 26 08:53:16 GMT 2015
#
# If you want to save customizations, delete the line above or this
# file will get automatically deleted on the next live boot.
#----------------------------------------------------------------------

Section"Monitor"
    Identifier"Monitor0"
    Option"DPMS""true"
EndSection

Section"Device"
    Identifier"Device0"
    Driver    "sisimedia"
EndSection

Section"Screen"
    Identifier"Screen0"
    Monitor"Monitor0"
    Device "Device0"
    SubSection"Display"   -----------------------------------------------> Manually added
        Modes "1280x1024""1333x768""1024x768""800x600"   ---> Manually added
    EndSubSection   ------------------------------------------------------> Manually added
EndSection

Ref my original report,
post40203.html#p40203
in it there are two xorg.conf files.

The first was automatically produced by a version of antiX that did not contain any SIS driver.
The second was produced automatically by antiX after I had compiled and added sisimedia
Note in both cases they contain the subsection missing in your latest initrd.gz.

After re-booting to console, once the subsection is added manually, then the startx command issued, X starts as expected and uses the sisimedia driver to produce a resolution 1280x1024@75.00hz

BitJam · posted: 2015-06-18 19:43

Thanks SamK!

I think I understand what happened. There were two changes. One change detected more video related hardware. This was the fix for D.O. The other changes detected hardware that uses the sisimedia xorg driver and if this happens, I set xorg=sisimedia internally. But I had forgotten that detecting your video hardware would disable a"default" parameter that normally gets added to the xorg= boot parameter when no video hardware is found. So now when I detect hardware for the sisimedia driver I set xorg=default,sismedia and this should fix your problem and get you to X at 1280x1024.

I renamed the previous initrd.gz to initrd-1.gz and I uploaded a new initrd.gz called initrd-2.gz to
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://www.dropbox.com/sh/l9szqbe3cgab5xn/AACMcn-K6qLfNaHJXG27EFkha?dl=0"
linktext was:"the same dropbox folder"
====================================
.

Could you please replace your initrd.gz with the initrd-2.gz that I just uploaded? It needs to end up being named"initrd.gz" in the antiX/ directory.

I'm sorry the previous version didn't work. I appreciate your detailed bug report which allowed me to track down the problem. Please let me know if this version boots to X for you. I'm glad we're doing field tests now instead of waiting for the next iso release. This is a big time saver overall.

Thank you all for you help.

skidoo · posted: 2015-06-18 20:22

are you happy with no /live/aufs-ram/.wh..wh.plnk/ directory? You can use the"plink" cheat to return to the old behaviour.

short answer: Yep, HAPPY. Dynamic root persistence seems to be working fine without plink.
...and, FWIW, I never understood why plink was enabled (nor why the aufs author's help page at sourceforge discourages omitting plink 'feature').
==============

Under the new initrd.gz, across 8+ test runs so far, the only scenario in which"non ideal" persist-related behavior occurs is this:
boot init 3, manually run persist-save... immediately followed by shutdown (er, 'halt').
The quirk is this: during shutdown, persist-autosave still prompts Y/N to perform a (redundant) persist-save.
Not reporting this as a"bug" though, because I'm _NOT_ sure I've retrieved from github the latest copies of all scripts + excludes files.

The excludes files are currently replicated across (er, redundantly contained within) two antix *.debs
Difficult to track/maintain and, even at this moment (i just checked) these are not"in sync" (see: live-remaster-exclude.list)
so... during build, whichever package is installed later/last"wins". Later, the most-recently-upgraded package"wins".

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/antiX-Linux/antix-libs/tree/master/excludes"
linktext was:"https://github.com/antiX-Linux/antix-li ... r/excludes"
====================================

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/antiX-Linux/Persist-Scripts/tree/master/excludes"
linktext was:"https://github.com/antiX-Linux/Persist- ... r/excludes"
====================================

antix-common.sh (sourced by persist-save.sh) is similarly replicated (but, AFAICT, the copies are currently"in sync"):

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/antiX-Linux/antix-libs/tree/master/lib/antiX"
linktext was:"https://github.com/antiX-Linux/antix-li ... /lib/antiX"
====================================

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/antiX-Linux/Persist-Scripts/tree/master/lib"
linktext was:"https://github.com/antiX-Linux/Persist- ... master/lib"
====================================

Anyhow, I'm just pointing this out to explain why I didn't post back to the thread where you invited"can grab the latest from github to test".

a question, for future reference:
Last night when I retrieved zipfile from github
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/antiX-Linux/Live-initrd-1"
linktext was:"https://github.com/antiX-Linux/Live-initrd-1"
====================================

and tried using /usr/local/bin/ps_initrd.sh ...I came up short. The resulting initrd.gz was only 1.7Mb instead of the expected 3Mb+ size.
Deja vu ~~ but I coundn't recall which"piece" is missed. As I type this, I'm guessing"vmlinuz".
Instead of deleting the content of initrdgz-image directory, then copying zipfile content into that path, then closing...
...I should have just tried overwriting the existing content with the zipfile content?

anticapitalista · posted: 2015-06-18 20:49

skidoo - I'll upload all the new debs to the repo once we are pretty sure it doesn't break anything.
Should be within 24 hours, probably much sooner.

BitJam · posted: 2015-06-18 22:40

skidoo wrote:short answer: Yep, HAPPY. Dynamic root persistence seems to be working fine without plink.

Great! Thanks for testing.

...and, FWIW, I never understood why plink was enabled (nor why the aufs author's help page at sourceforge discourages omitting plink 'feature').

I'm in the same boat as you. Although it seems that using plink and the auplink tool ends up with some minor space savings compared to noplink. We tired using the auplink tool but despite the current documentation saying it could be"run at any time", it can make the root file system inaccessible for a few seconds (depending on how much work it has to do) which is VERY BAD(TM).

Under the new initrd.gz, across 8+ test runs so far, the only scenario in which"non ideal" persist-related behavior occurs is this:
boot init 3, manually run persist-save... immediately followed by shutdown (er, 'halt').

Thanks!

I wasn't sure what this policy should be. Currently the lockout timeout is only triggered by automatically run persist-saves. This seemed to be a more conservative approach: if someone wanted to do a manual persist-save right before shutting down then maybe they had a good reason and they still want the automatic persist-save to run. Do you think I should assume that I know better than the user and have manually run persist-saves also lockout automatic persist-saves for 15 seconds? These kinds of policy choices are often obvious to people who are using the software but much less obvious to me when I'm writing it.

The excludes files are currently replicated across (er, redundantly contained within) two antix *.debs
Difficult to track/maintain and, even at this moment (i just checked) these are not"in sync" (see: live-remaster-exclude.list)
so... during build, whichever package is installed later/last"wins". Later, the most-recently-upgraded package"wins" [...]

This is not my area of expertise although I wouldn't be surprised if I have added to the confusion. I imagine the solution will involve package dependencies.

Thanks for you feedback skidoo! It's been very helpful. So was the feedback from D.O. and SamK. Thank you all!

skidoo · posted: 2015-06-19 00:09

have manually run persist-saves also lockout automatic persist-saves for 15 seconds?

Fine as-is, really ~~ amounts to"erring on the safe side".

BitJam · posted: 2015-06-19 01:52

skidoo wrote:
have manually run persist-saves also lockout automatic persist-saves for 15 seconds?
Fine as-is, really ~~ amounts to"erring on the safe side".

skidoo, I trust your perspective on this and want to try it your way.

The existing rule is that if an auto-save has been started but either aborted by the user or failed for some reason we still start the 15 seconds lockout countdown. Otherwise if you have selected semi-automatic and you said"no" the first time, you will still be asked again a few seconds later. Likewise if the if the save failed for some reason the first time, it is likely to fail again for the same reason.

But dealing with previous manual saves has to be different. For these, ISTM the save has to complete successfully in order to start the lockout countdown. It had seemed to me that doing a manual save less that 15 seconds before shutting down would be uncommon but we might as well deal with it correctly. This rule may not be perfect but I think it is simple and easy and may be close enough.

SamK · posted: 2015-06-19 14:03

Re: sisimedia driver

initrd-2.gz produced the expected GUI desktop.

Code: Select all

cat /proc/cmdline
vga=788 lang=en_GB quiet splash=off disable_srv=LX

inxi -c 0 -G
Graphics:  Card: Silicon Integrated Systems [SiS] 65x/M650/740 PCI/AGP VGA Display Adapter
           Display Server: X.Org 1.16.4 driver: N/A Resolution: 1280x1024@75.00hz
           GLX Renderer: Gallium 0.4 on llvmpipe (LLVM 3.5, 128 bits) GLX Version: 3.0 Mesa 10.3.2

Re: antiX release

BitJam wrote: Time is short.
[...]
...this will help us short-circuit the development cycle...
[...]
This is a big time saver overall.

These are quite odd remarks, particularly in view of the quiet patience the community has demonstrated since the last antiX release on 05 November 2013. It is curious that speed of community response is now introduced as a relevant factor.

BitJam wrote:...help us get a really solid antiX-15 out the door before anticapitalista leaves for the summer.

Of course I don't decide when antiX has reached a sufficiently high quality threshold to trigger the release of another official version. What will happen if the trigger date is missed? The release will be delayed by a few weeks. This is likely to be a much shorter time period than it will take to repair any reputational damage caused by the release of an unfinished and insufficently polished final version, in an attempt to meet a spurious deadline. antiX has more to lose by attempting a premature release than it has to gain.

In view of the state of beta-3, it will be beneficial to produce a minimum of one further ISO, (potentially followed by others) to enable testing, checking and verification of the work done since its release. Additionally, there might be new matters uncovered. In short, the beta-3 ISO was the last the community has seen. Because it was such a long way from being finished a further beta seems both an obvious and needed next step.

In my opinion, antiX should be released only if and when the quality threshold has been reached. In other words it should be released when it is ready, not simply to meet an abitrary and artificial deadline.

anticapitalista · posted: 2015-06-19 15:08

If antiX is not released before I go to the UK at the beginning of July, it will not get released until the end of September (at the earliest) when I return. That isn't a few weeks, but 3 months (minimum).

A new iso is to be uploaded later this evening.

fatmac · posted: 2015-06-19 16:05

In my opinion, antiX should be released only if and when the quality threshold has been reached. In other words it should be released when it is ready, not simply to meet an abitrary and artificial deadline.

I agree whole heartedly, a few more weeks/months don't matter, it is more important to have a stable polished distro.

anticapitalista · posted: 2015-06-19 17:05

I disagree that a few months won't matter, It will.
Also, I'm convinced that for well over 95% of antiX users, it is already stable and polished enough. (and that is down to the feedback from all testers, so thanks to you all).

SamK · posted: 2015-06-20 06:48

fatmac wrote:
In my opinion, antiX should be released only if and when the quality threshold has been reached. In other words it should be released when it is ready, not simply to meet an abitrary and artificial deadline.
I agree whole heartedly, a few more weeks/months don't matter, it is more important to have a stable polished distro.

anticapitalista wrote:I disagree that a few months won't matter, It will.

Expressing differing opinions in a respectful, courteous, and considerate way is a hallmark of an empathetic community.

@anticapitalista As always, you are rightly the ultimate judge of antiX matters. Assuming it doesn't impinge on personal concerns, will you give some insight into why"it will" matter if the release is delayed?