Quirky SlaQ 8.1.6 x86_64 released

[belham2]

@belham2

Have you ever zeroed a 32 GB or larger flash drive? Believe me this takes a while. If you find that acceptable, what about my 128 GB drive?

Yes, and Yes, and even larger.......it's what beer and a night's sleep are for

[prehistoric]

@belham2

Have you ever zeroed a 32 GB or larger flash drive? Believe me this takes a while. If you find that acceptable, what about my 128 GB drive?

Yes, and Yes, and even larger.......it's what beer and a night's sleep are for

You do realize that the vast majority of people will not accept this don't you? If this is required I'm afraid puppy will become even more a minority choice than it is now. Unnecessary writes also shorten the useful life of a drive.

What's more, I don't think this is necessary. Fix the GPT and expand the filesystem, and none of the previous use will matter.

Also, if you are trying to eliminate the possibility that earlier data can be recovered from the drive it is not adequate. I've had friends who have had flash memory used in industrial applications who found companies who specialize in recovering data from such media after they have been overwritten. Also happened with a photographer I know. He carries insurance against losing data on flash drives that pays for recovery.

Added: Here is one example of a recovery service. Before you tell me this does not apply, I think you need to find out how flash drives work. Writing over data does not do what it does on magnetic disks.

So, what do you think you are actually accomplishing with this proposed procedure?

[linuxcbon]

It is flatout crazy that anyone who does a compressed image install using the dd command does not first do a complete dd wipe of that install device, whether they had GPT-related partitions previousy or not.

No. No. No. The problem is NOT what was on the disk before.
The problem is sfdisk not calculating "empty space" correctly.
You should never need to "dd dev zero", except to erase the whole disk and it takes many many many minutes. That's never needed for installing iso to the disk.

[belham2]

@belham2

Have you ever zeroed a 32 GB or larger flash drive? Believe me this takes a while. If you find that acceptable, what about my 128 GB drive?

Yes, and Yes, and even larger.......it's what beer and a night's sleep are for

You do realize that the vast majority of people will not accept this don't you? If this is required I'm afraid puppy will become even more a minority choice than it is now. Unnecessary writes also shorten the useful life of a drive.

What's more, I don't think this is necessary. Fix the GPT and expand the filesystem, and none of the previous use will matter.

Also, if you are trying to eliminate the possibility that earlier data can be recovered from the drive it is not adequate. I've had friends who have had flash memory used in industrial applications who found companies who specialize in recovering data from such media after they have been overwritten. Also happened with a photographer I know. He carries insurance against losing data on flash drives that pays for recovery.

So, what do you think you are actually accomplishing with this proposed procedure?

Listen, Prehistoric, Let's stop here. I am sorry I brought it up, and in fact, it was intended as an option for Barry, but of course others..well.... . Also, I try to stay reserved on the internet, but I work in the data security industry, 3+ decades now...we are NOT talking here about "securely" erasing drives and data on them. Don't mix and mash the discussion , trying to pull an apples to oranges comparison. I am not even sure if you know you are doing it. One thing I've learned over the decades of working securing databases & securing networks, is people, sometimes myself included, have trouble staying on point with "what" is being discussed and/or sorted out. Data recovery? Versus removing sectors on device sufficiently for home installs so partitioning schemes don't conflict? Two entirely diff subjects. Our objective with dd (for Barry's install's sakes) is not to securely, in totality, to wipe every bit off a drive. Also, we are NOT talking about attracting users to puppy or not, so please stop. Without Barry and the other creators, you and I and everyone else do not have anything to fuss over, period. I am not creating pups and their varities. Are you? Stop the childish insinuations. You, me and all the regulars here want the same thing; what is best for puppy. In essence, don't stand out in the sun and make the profound statement that it is warm out.

Enjoy the rest of your Sunday, prehistoric, and I do mean this sincerely. I hope you get your problems sorted out with Quirky....on every one & way (frugal + full) I've installed now, and it just hit 5 different (AMD+Intel, all diff storage mftrs) machines today. Plus a friend yesterday during the US football playoffs did his laptop, full install, with Quirkyslaq. A success. These installs are on two USBs, two HDs, and two SD cards, I guess it must be that we are only lucky that we do/did the things we did with dd commands before we installed and didn't run into the problems you and others did. [Edited: plz excuse the constant spelling/grammar errors...argh!)

[belham2]

It is flatout crazy that anyone who does a compressed image install using the dd command does not first do a complete dd wipe of that install device, whether they had GPT-related partitions previousy or not.

No. No. No. The problem is NOT what was on the disk before.
The problem is sfdisk not calculating "empty space" correctly.
You should never need to "dd dev zero", except to erase the whole disk and it takes many many many minutes. That's never needed for installing iso to the disk.

linuxcbon,

Did I ever tell you the story of GPT Ghosting?? Me no like

[linuxcbon]

linuxcbon,
Did I ever tell you the story of GPT Ghosting?? Me no like

Hi belham,
sounds complicated...let's try not to complicate things and to find the bugs in puppy.
Cheers

[belham2]

linuxcbon,
Did I ever tell you the story of GPT Ghosting?? Me no like

Hi belham,
sounds complicated...let's try not to complicate things and to find the bugs in puppy.
Cheers

Agreed!

Hey, you think Barry might ever give your request consideration? I posted a few times about it, even stuck my necks out with a separate thread, but I know he is probably near his wits end with everything going on right now. Still, a barebones quirky?? Ooooh lala....

[linuxcbon]

Agreed!

Hey, you think Barry might ever give your request consideration? I posted a few times about it, even stuck my necks out with a separate thread, but I know he is probably near his wits end with everything going on right now. Still, a barebones quirky?? Ooooh lala....

I am sure he will keep his promise but he said he's very busy and he needs to rest (he is not as "young" as us)... So let's not pressure him too much. He needs to stay fit (like we do).

[prehistoric]

@belham2

Have you ever zeroed a 32 GB or larger flash drive? Believe me this takes a while. If you find that acceptable, what about my 128 GB drive?

Yes, and Yes, and even larger.......it's what beer and a night's sleep are for

All joking aside, I repeat, what do you think this waste of time will accomplish?

Added: the talk about saving BarryK effort apparently missed my proposed workaround. If you reuse a flash drive, check it with Gparted, and if there is a report of a corrupted GPT, let Gparted correct this.

I'm waiting to hear that someone reusing a drive has tried this. It should not require a command that runs overnight.

Added later: I've given up waiting. I used the problem drive I created and the version of Gparted in SlaQ 8.1.6, (booted off a DVD. You don't want to run Gparted on your boot drive,) to fix the GPT and resize the partition. That drive now boots without problems, and shows 28 GB available to SlaQ. Unless I hear otherwise, I will declare that the workaround works, provided you use an up-to-date Gparted.

I'll leave the command-line magic to others. All that is necessary at this time is to add some words to the instructions.

[Sage]

up-to-date Gparted

I dispute that, vide supra. Old ones still best!

[BarryK]

@barry

Thanks and kudos for Slaq. This might actually trigger my final move to x64.
Besides the already reported "filesystem growing issue" that is the major issue I have with it...
Now to go after chromium and netflix! Anyone has the latest slack based pets for the latest chromium?

Thanks,
gcav


PS: Why drop F2FS? I did notice a slow-down at boot-time, compared to April 7.2.1 on T2.

f2fs, yes... unfortunately, the latest version requires selinux to be installed.
Also, it still doesn't have filesystem resizing.

Also, I read somewhere that the advantages of f2fs are minimal with flash sticks, as they have some write-leveling built into the hardware.

Also, ext4 has features that support some write-leveling.

So, it would seem that ext4-without-journal is now a reasonable choice.

Another thing, I have read that lifetimes of flash technology are improving, making limiing writes to the drive less of an issue.

So, I have dropped f2fs.
Regarding boot speed, I can't remember noticing a slowdown with SlaQ. But, running the latest Quirky Xerus 8.1.6 on my baby laptop, Asus E200HA, I noticed that it seems to boot very fast -- just a subjective observation.

Hmmm, just noticed something else. I am running Xerus 8.1.6 on my laptop, have it installed on the internal hard drive. At last bootup, I turned off touchpad tap, but now it is back on -- will need to find out why Flsynclient settings are not persisting.

It does trigger my memory. There was a problem with Flsynclient not remembering settings, it was necessary to use an older version.
It did write the settings to a file, but was unable to read that next time.
There would be something about this on the forum somewhere.

[belham2]

Hmmmm.........

Barry, any chance you could either tell us (or me ) how to get the darn 'Q_ID" magic number for the Q-ID file so my frugal installs can see the savefiles I create on the first time booting up? I think the #s are some mix of the ISO's date and also 4 digits after, from what I can see of my other two Quirkys needed 'Q-ID' files required for frugal boot + savefile loading:

Werewolf-7.4.........Q_ID = 201512101229 (boots and loads .sfs great)

Quirky8.0..............Q_ID = 201604210401 (boots and loads .sfs great)

QuirkySlaq8.16.....Q_ID = ???????????????? (boots pristine all the time and cannot see/load the .sfs previously created)

QuirkyXenial8.1.6..Q_ID = ???????????????? (same as QuirkySlaq)


Gracias!! It's kind of rough flying 'frugal' installs w/o the ability of Quirky seeing (and loading) the s.sfs created




[UPDATE: Ok, discovered that the 'Q_ID' file is located in the initrd.q...stupid of me not to look there first Or, if you're currently inside a quirky-live frugal install, look in /initrd/q_rw/rw/boot/initrd-tree (and copy it over to your frugal folder):
Here they are for Quirkyslaq8.1.6 & QuirkyXenial8.1.6:

QuirkySlaq8.1.6 = 201701111649

QuirkyXenial8.1.6 = 201701140115

With these, you can go to town with using a frugal install with savefile (or not, your choice) done upon exit. Sweet!!

[belham2]

Whoa, hold the crackers: even with the Q_ID file properly placed, Quirky Slaq 8.1.6 cannot load a savefile (assuming you are frugally installed & created one) on subsequent boots after savefile's 1st creation.

Does this have something to do with the errors linuxcbon noted in Xenial? I am seeing the same errors during boot of both Xenial & Quirky , though they will boot up to the live-desktop every time, they're throwing errors I've never seen before in Quirky boots. For the savefile, during the loading and layering, there is no hope of that previously created savefile being seen. It is like it doesn't exist, almost what Flash is describing in the Xenial 8.1.6 thread after he did a remaster. Hmmmmm........

Barry, where can I dig at this to fix it?? In the initrd.q initrd-tree?? Is there a script error in the loading process during init?? Or is something not being transferred/passed correctly after the savefile is created curing the first initial run of a live-session? I'm stumped.

(by the way, this same problem is also appearing in Quirky Xenial 8.1.6; anyone else seeing this?

Also want to ask: why is there no YAD in these two Quirkys (Slaq and Xenial)? Had to drag over YADs from other Quirky installs, made/makes it a bit of a pain when installing something like urxvtset package from PPM if there's no YAD by default in the OS).

[FeodorF]

Quirky SlaQ 8.1.6 x86_64

- jwmrc not correct. That's why startup programs (network tray, retrovol) don't appear in tray.

Code: Select all

Generating /root/.icewm/menu...
mv: cannot move '/root/.icewm/menu' to a subdirectory of itself, '/root/.icewm/menu-previous'
Generating /root/.jwmrc...
mv: cannot move '/root/.jwmrc' to a subdirectory of itself, '/root/.jwmrc-previous'

Code: Select all

# jwm -p    
JWM: warning: /root/.jwmrc[423]: close tag "Program" does not match open tag "?xml" 

Solution to the problem:

edit /root/.jwmrc
delete all the lines starting from line number 414...
save it and restart the x server

[FeodorF]

Wrong! Deleted

[FeodorF]

Drive sr0 can not be mounted - but you can boot the live-CD.

CDs and DVDs are not detected by the system as mountable.

DVD drive works fine with Quirky Xerus 8.1.6 .

Used the SlaQ live-CD for testing.

[linuxcbon]

Quirky SlaQ 8.1.6 x86_64

Solution to the problem:

I know this already, but that's not a solution, it's a manual workaround. You need to find where the bug exactly comes from in the scripts and give a real solution.

- some useless folders :
/usr/bin/lib64/ -- empty
/usr/bin/svn-tools/ -- empty
/usr/etc/ -- empty
/usr/games/ -- empty
/usr/local/share/ -- empty
/usr/lib/modules/ -- empty

- /etc/profile too complex, what is only needed is export PATH= ...

- perl can be moved to devx or is it needed somewhere ?

[belham2]

Ok, this is to follow-up for those of you that want to 'frugal' install this latest Quirky-Slaq/Xenial and also have the ability to have a savefile recognized during boot. Currently, this latest edition (this goes for QuirkyXenial too) cannot see the savefile you created on the 1st frugal boot, and thus won't load it.

The problem is in the init script, which gets loaded from the initrd.q. This is how you solve it for now, until Barry can take a deeper look at why the latest changes in this 'init' script caused the problem:

1) It does not matter if you are booting into Slaq/Xenial for the 1st time, or if you've already created a savefile and are stumped why it isn't loading on subsequent boots.

2) go into your /mnt (or your desktop shortcut, if it exists) and get to where the vmlinuz and initrd.q are located (they should be un-mounted)

3) Left-click on the initrd.q (it has the black& white puppyface)

4) Up will pop a yellow dialog box. It says:

initrd.q: expand?
Do you want to open up initrd.q, and optionally edit it?

(click yes here)

5) Then a mint green dialog box pops-up. It tells you it opened/epxpanded the initrd.q to: /root/initrd-expanded

Also, it is helpful if you leave open the file manager above that still shows the black&white initrd.q file. We're going to need it in a minute.

(click 'ok' in this mint green dialog box)

6) up pops Rox with the expanded initrd.q. Right-click on the "init" file, and choose "open-as-text"

(we are going to edit this file)

7) once it is open in Geany, scrolldown just barely, near the top, and you will see the following lines (without the # comment outs):


hwclock --hctosys --localtime #160427 from util-linux. assuming hw clock set to local

if grep -qw aufs /proc/filesystems; then
LAYERFS='aufs'
RO='=ro'
else
LAYERFS='overlay'
RO=''
fi

(put a "#" in front of each and every one of these lines, so the init script will ignore them).

Now, go back to that Rox open window (we left it open) I mentioned to keep open above.

9) Left-click on the black&white puppy 'initrd.q' file

10) it will ask you if you want to save your edits to the initrd.q file:

initrd.q: update?
A CPIO-archive........./initrd.q?

(Click "Yes")

11) up will pop another mint-green dialog box saying:

initrd.q: success
File.........initrd-expanded.

(Click "Ok")

12) up pops a yellow dialog box:

initrd.q: finished
Do you want to delete /root/initrd.q-expanded? If in doubt, please choose Yes

(Defintely choose 'Yes' here)

13) That's it!! Close out any remaining Rox windows open, and either go about setting up your Quirky and the 'savefile', or just reboot (assuming you already have a 'savefile') and you will find that upon booting up, Quirky now sees your previously created 'savefile'.


***Please note: this exact same procedure will/should work in QuirkyXenial, as the inits are the same****



P.S. Barry, I just played it safe and had them comment out both the "hwclock" change you made, and also the offending "layer/aufs" section, which seems by itself to be the problem causing both QuirkyXenial and QuirkySlaq to not see any savefile created after first boot. I tested, and once this stuff is commented out, my savefile files (on a frugal install) are now being seen at boot and loading up perfectly.

[Billtoo]

@belham2

I sent you a pm regarding redshift.

[belham2]

@belham2

I sent you a pm regarding redshift.

Thanks Bill!