Quirky Werewolf 64-bit 7.4 released

[Ted Dog]

Having issues with text and icons not being visible until passed over with mouse with dialog based interfaces, like connection wizard and whatever that was at the very beginning of first boot.

[Jerror]

Very excited to give this a go! I hope I'll find time this weekend. Otherwise I'll just have to accept that I will miss out on the bugs
Are there any changes (eg., to devx library versions) which might upset my Quirky7.2 .pets? I've built some finicky packages which I need for work.

[James C]

http://distrowatch.com/

[BarryK]

You had me worried there for a second!

I did nor really go through the scripts but 1.7GB space required (pic) made me think otherwise.

That figure of 1.7GB is an estimate of the maximum that Quirky is likely to need.
This is derived from about 1.7*2 = 3.4GB being the amount that can be stored in RAM, and the save-file compressing that.

That is, your system will have about 3.4GB space in the zram, in which to download files, install packages, caches, etc.
-- but you would need to mouse-over the memory icon in the tray to see the exact amount available.

[BarryK]

Hello @BarryK.

@Mavrothal shows the screen for an initial save-session. I have read both of your descriptions of the process, but, this implementation screen in a little misleading and I ask clarification on the process.

Step1
Here we identify which of any partitions seen by the system we want the file to be saved and further what folder name on the partition is the session file to be saved in
Question
Can the folder name be a path OR does the boot process only search root level for the folder vs looking for it path to find the session file?

Step2
Here, this step begins by asserting that a REMASTER is required.
Question
Is this to be done before we initially use this SAVE desktop icon? Or is this announcing that the process to be performed is going to place a new system master on the media in one of the PC's magazine?

The understanding appears that we are to rewrite the CD/DVD media as well as write a file for system boot on the permanent media (HDD/USB). Is that correct?

Is this correct, too?
Is your save-process structure for Live use as follows?

• The initial (pristine) DVD is to remain without change, because it is general for most PCs to boot from. Thus, this remains constant.
• While the save-session file is specific and unique to one's booted PC; and applies to only this PC. Thus, this is variable by individual PC where its saved

Thanks in advance for any clarification on Live use

Step 1,
the example folder name could be left as-is. It could have a path, but I haven't put in code to create a path if it doesn't exist.
That is something that I could clarify.

Step 2
I think that it is unambiguous.

[BarryK]

Had a better look at the "boot from CD save to partition/folder" process.
The space requirement mentioned above is a leftover from full installs and thankfully does not block the process.
However, both q.sfs and s.sfs are saved, which does not make sense if you are going to be booting from the CD that has the q.sfs. You just want to save the s.sfs file I would think.

Regarding kernel command arguments, it would appear that they require a /BOOT_SPECS file at the root of the boot device and there is no obvious way to provide the BOOT_DEV, BOOT_FS and BOOT_FOLDER parameters from the command line other than just type them and this is not working as they are ignored.
It would also appear that you can not have the initrd.q and s.sfs in different devices, at least when running from the original CD.

...Or maybe some better instruction are needed.

You haven't looked at the 'init' script.

If the q.sfs is saved alongside s.sfs, it is removed from the CD.

The install instructions are unambiguous, as per the snapshot you posted above.
The CD has to get remastered as part of the process.

[gcmartin]

OK, I see your process a little more clearly.

The save process REQUIRES that the CD is burned, initially, such that it is NOT closed. This must be done so that it can be reburned for a save session. Thus it MUST be a RW disc and NOT an +R/-R. Your process will rewrite the CD/DVD disc and also write a session file to local disk; namely HDD/USB/etc.

Therefore, the 2 items are a marriage required for Live CD/DVD use with save sessions.

This also means that if I want to use Live on another PC, it is best to create its own, separate Live disc media for boot and save-session use.

Is that correct?

[mavrothal]

You haven't looked at the 'init' script.

If the q.sfs is saved alongside s.sfs, it is removed from the CD.

The install instructions are unambiguous, as per the snapshot you posted above.
The CD has to get remastered as part of the process.

Maybe so but before I look again please let us know
a) if it is possible to boot from the original CD (_not_ a remaster) and have a save folder with _only_ the s.sfs on a partition? EDIT: It would appear "no"
b) if the above _is_ possible what the boot line arguments would be to use the said save folder (provided there is no /BOOT_SPECS file)? EDIT: Is possible. See below.
Thx

Latter OK

Code: Select all

quirky boot_specs=sda1:ext4:werewolf64-7.3

(or what ever partition:filesystem:folder is) works.
Kind like fatdog.

Bit later It would appear that the q.sfs _must_ be copied to hard disk too. Although the save dialog provides the option not to copy it to the HD, this results in a kernel panic on next boot with the above arguments.
This is because the init defaults in loading q.sfs from $QPATH if QPATH exits.
Maybe split QPATH to QPATH and SPATH to allow loading from different devices/partitions.

[linuxcbon]

Quirky Werewolf 64-bit 7.3

- transmission bittorent client has too many dependencies and not needed ? There is already pctorrent (small gui for ctorrent).
- xemeraldia has too many dependencies.
- why are perl and python not in devx ?
- why is there /usr/local/install_quirky/ when there is a standalone version ?
- there are duplicate folders :
/usr/local/lib/X11/pixmaps/ and /usr/share/pixmaps/
/usr/local/lib/X11/themes/ and /usr/share/themes/
solution : maybe merge them and create symlinks

This quirky is quite nice at the moment, except for seamonkey crashes.
T2 seems dead, so maybe this way is better. Anyway T2 has too many bugs and work to put into.

cheers

[BarryK]

Step1
Here we identify which of any partitions seen by the system we want the file to be saved and further what folder name on the partition is the session file to be saved in
Question
Can the folder name be a path OR does the boot process only search root level for the folder vs looking for it path to find the session file?

I have added a help button alongside the folder entry box.

Yes, the folder has to be at top-level in the partition, unless a path is specified. For example "quirky/werewolf-7.3"

[BarryK]

OK, I see your process a little more clearly.

The save process REQUIRES that the CD is burned, initially, such that it is NOT closed. This must be done so that it can be reburned for a save session. Thus it MUST be a RW disc and NOT an +R/-R. Your process will rewrite the CD/DVD disc and also write a session file to local disk; namely HDD/USB/etc.

Therefore, the 2 items are a marriage required for Live CD/DVD use with save sessions.

This also means that if I want to use Live on another PC, it is best to create its own, separate Live disc media for boot and save-session use.

Is that correct?

No, that is not correct.

Look at the snapshot posted by mavrothal.

If you choose to save the session to hard drive, a once-only remaster of the CD is required. Look at the snapshot, it unambiguously states "once only", and "please insert a blank CD or DVD".
So you do not use a -RW, you burn a new CD, with the save-file location hard coded into it.

It was a design decision I made for the original CD not to probe the hard drive.
Of course, I could go the Puppy-route and put some drive-probing into it -- which I might do if it turns out that nobody likes this idea of having to burn another CD.

So, yes, the second CD is hard coded for a specific partition, filesystem and folder (with optional path), so won't work on another PC unless you set it up with that same partition/filesystem/folder.

[BarryK]

You haven't looked at the 'init' script.

If the q.sfs is saved alongside s.sfs, it is removed from the CD.

The install instructions are unambiguous, as per the snapshot you posted above.
The CD has to get remastered as part of the process.

Maybe so but before I look again please let us know
a) if it is possible to boot from the original CD (_not_ a remaster) and have a save folder with _only_ the s.sfs on a partition? EDIT: It would appear "no"
b) if the above _is_ possible what the boot line arguments would be to use the said save folder (provided there is no /BOOT_SPECS file)? EDIT: Is possible. See below.
Thx

Latter OK

Code: Select all

quirky boot_specs=sda1:ext4:werewolf64-7.3

(or what ever partition:filesystem:folder is) works.
Kind like fatdog.

Bit later It would appear that the q.sfs _must_ be copied to hard disk too. Although the save dialog provides the option not to copy it to the HD, this results in a kernel panic on next boot with the above arguments.
This is because the init defaults in loading q.sfs from $QPATH if QPATH exits.
Maybe split QPATH to QPATH and SPATH to allow loading from different devices/partitions.

Yes, you are right!

Booting the live-CD, then saving a session, which requires burning another CD, might seem a hassle, but apart from hard-coding the save-file location, it does one more thing, move the q.sfs out of the CD to the hard drive.

Frugal install does the same thing.

This results in very fast booting, as q.sfs was previously inside the initrd so had to get loaded at bootup.

Note, the reason I put q.sfs inside the initrd was to avoid any drive probing at bootup. This makes the init script very "situation agnostic", for net boots or whatever.

[BarryK]

- why are perl and python not in devx ?
- why is there /usr/local/install_quirky/ when there is a standalone version ?

This quirky is quite nice at the moment, except for seamonkey crashes.

There is only perl_tiny, the full perl is in the devx. I want to keep perl_tiny for now.

Yes, sometime ago I decided to put python into the main f.s.
I need to rethink this, should probably put it out to the devx.

/usr/local/install_quirky has /usr/sbin/installquirky, which runs it.

The standalone version is an alternative, that can be created to use anywhere, in another distro.

Running in Quirky, the standalone version is not needed, it is builtin, in the menu.

[BarryK]

This quirky is quite nice at the moment, except for seamonkey crashes.

I am running SM 2.39 now, so far so good!

[DanielSong39]

Can this version of Quirky Werewolf run 32-bit applications?

If so - time to give it a spin.

[BarryK]

Can this version of Quirky Werewolf run 32-bit applications?

If so - time to give it a spin.

Not Out Of The Box.

You would have to use the Package Manager to install the Ubuntu 32-bit libs.

I haven't tried it, I don't know which packages are required.

[Rodney Byne]

Well done Barry.
For me QW-7.3 on USB made from DVD is a nice stable release
and for what it's worth SM 2.38 is rock solid so far.

Only two questions, will 7.3.1 be available via the
Version Upgrade Manager and will all my SM 2.38
bookmarks & settings be transferred across to SM 2.39,
as would happen in Firefox?

Thanks, best regards.

[partsman]

Very nice Barry !

I did a full install to an 8gig flash drive
A couple of things:

1. cpu freq. scaling from the menu doesn't work

2. When installing from ppm when there are a lot of depends. the window is to large and can't click on the radio buttons !

I didn't get a lot of time with it yet but I did notice those 2 things !
Other than that I did install supertuxkart from ppm ! All good !
Looking nice ! Thanks !

More Later !

[gcmartin]

Thanks @BarryK. Your post here, emphasizes exactly what I shared in how the process works, physically.

And, in the subsequent post, I see why you are making a new CD to match the changes that are being made locally on local, albeit faster, peripheral. As such it could allow a faster boot as the boot system data is coming from 2 buffers directions.

I took a look at the size of the 2 boot system needs and dont see a major change in actual data size, per se.

I have one simple idea: I say :"simple" as it comes from me.
Why not pre-plan the boot manager with a save session concept where the original CD is packaged with its pre-planned design and has a boot option to use that pre-designed layout.

This would meet both your objective and minimize the complexity that currently exist while potentially cutting down on DVD disc media needs.

Here's why. @Stemsee, early on this year, showed the community how to have a boot manager that gives users the option of what they want to boot. In his design, he allows the user to select "boot this version" or "boot that version". In his case, he allows the user to select to boot the 64bit version or the 32bit version. In concept, this exactly matches what you intend: Just here, its boot Pristine or boot using the pre-designed save session.

If you are willing to consider his design, this could easily match your objective where the user selects to boots pristine OR the user boots with a pre-designed save-session where the local media probe occurs by the boot manager. The save-session name, then, is static in the pre-design.

Thus, take away the folder name selection altogether and only allow user to select the partition placement.

Complexity is reduced and only one DVD which remains matching local save needs via boot option 2 and portable (pristine) needs via boot option 1.

Of course, your present save app doesn't change much by merely removing the option from the screen as the work in done at the time of boot by user selection.

Further, the user, by this boot option has a way to get back into his system, pristine, should he need/choose.

It again, is a "simple" idea for consideration as you ponder how best to meet the objective you intend for your users to understand in use.

I see one flaw in my "simple" view where the probing for the folder would eat time, especially if it was the very last partition that exist in the local storage system. (I have seen some users, like me, sometimes on PCs that have many many partitions, across differing drives/devices. But everyone is not like me and this might be perfect for their needs.). This, of course, is a problem today's distro with boot probing for a save-session. for example, on some of my occasions I have told GRUB4DOS to "find" a root partition based upon some folder name.

Boot time Probing via a Boot Manager for a folder on storage, in my view, is not bad, but may not match with the views of others. Some may feel that looking for something specific, as the boot manager does, somehow violates them.

[don570]

I hope the new kernel will solve my problems with i915 driver.
Here is summary of changes....

According to the diff from Linux kernel 4.2.5, the new maintenance release is here to add various improvements to the ARM, ARM64, PowerPC (PPC), and x86 hardware architectures. Moreover, it fixes several issues in the Btrfs and OverlayFS filesystems, repairs a couple of networking problems, mostly related to mac80211 and Netfilter, as well as to adds a few mm and sound enhancements.

"I'm announcing the release of the 4.2.6 kernel. All users of the 4.2 kernel series must upgrade," says Greg Kroah-Hartman. "The updated 4.2.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.2.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/g ... ;a=summary.
Drivers, lots of updated drivers

Besides the changes mentioned above, Linux kernel 4.2.6 updates numerous drivers, especially for things like GPU (AMD, Intel i915, Nouveau, Radeon, and vmwgfx), BUS, CLK, CPUFreq, EDAC, I2C, iiO, InfiniBand, IOMMU, IRQ chip, MD-RAID, DVB, MMC, networking (mostly Wireless), PCI, PINCTRL, SCSI, thermal, TTY, USB, and video.