Wary64, very small, for x86_64 CPUs

[BarryK]

To all. Be Aware! I have had a hiccup with system access my HDD with NTFS. This is a 2nd such occurance and this happened on a completely different 64bit PC (my personal one, this time). There is a potential problem with this distro as well with a system's HDD. This may cause loss of your data. With April64, I lost a partition using that system's tools.

Nothing has been added, as the running desktop is pristine, save for FirstRUN setup and Connect being run for LAN service.

Initially, clicking to open a 1TB partition on the system's HDD, WARY opened a folder for all partitions on the HDD. Closing the ROX window and clicking a 2nd partition onthe HDD, caused the icons for the drive to disappear from the desktop.

Request to development
Something is amiss.

• What is wanted to gather data for evaluation?
• Is there any explanation for what occurred?

I will let this system idle for only 12hours awaiting instructions before abandoning.

Further, this system has approx 4000 data, documents, and media files on the HDD. I have been using LH64 & FATDOG on this PC for several years with no hint of problems. Most recently I had FATHouse running. LH has the updatedb commands which makes file "locate" immediate. updatedb, locate, slocate is still missing as we move to 64bit PCs with massive HDDs.

Code: Select all

# fdisk -l

Disk /dev/sdb: 1.4 TiB, 1500301910016 bytes, 2930277168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x55e655e6

Disk /dev/sdc: 1.9 GiB, 2020904448 bytes, 3947079 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xd6ca7880

Device    Boot     Start       End  Blocks  Id System
/dev/sdc1 *         2048     34815   16384   6 FAT16
/dev/sdc2          49152   3817471 1884160  83 Linux

This is being posted from the Wary64 PC. Notice, below, that the HDD is missing, NOW, from the desktop.

So, it is /dev/sda that has disappeared?

Try this, running Wary64 with the missing drive icons:

# gdisk -l /dev/sda

Also, look in /dev (using ROX-Filer), are the sda* device nodes still there?

[BarryK]

I think that Ted Dog might be the guy to ask about this...

Do any of you guys have experience with "udf" mount of CDs?

I was wondering, if I mounted a CD with udf filesystem, then changed a file, would the change be recognised at bootup?

That is, would the PC only see the original file, not the changed one?

udf works be writing a complete new file to the CD, and the original is still there.

I have no experience with udf.

EDIT:
Oh, I did do something:
http://bkhome.org/blog2/?viewDetailed=00096

...I had forgotten about that. Anyway, I never did try udf writing to a CD then boot up to see if the changes are recognized.

[L18L]

Why I need such small size these days, I'm not so sure, but it is fun to do -- download is just 110.8MB, with a fully-featured distro, having "everything that you would want".

...everything that English speakers would want.
Small size is good to add something for the rest of the world.

Imagine you have a new phone or tablet or running android-x86 on your PC ...and it is not "all Greek" but all Chinese.

No
Android is clever enough to give you a choice of user's language from the start on.

And Quirky should also do so.

Here is my contribution:

A small wrapper named launch_app_in_another_LANGUAGE does what its name says.

No question (because language unknown)
Just answers (language in the language's language)

(No locale needs to be pre set....)

Use it in delayedrun to launch quicksetup in one of the available translations.

It could be improved if it would appear on a black screen.
EDIT
.. and include translations for welcome1stboot
.. and include translations for network-setup

.. or include all puppy specific translations (it is not that big)

EDIT
pet was downloaded 14 times
deleted
bug fixed pet, see:http://murga-linux.com/puppy/viewtopic. ... &start=104 please.

[gcmartin]

@BarryK asks for these results:

Code: Select all

# gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.10

Problem opening /dev/sda for reading! Error is 2.
The specified file does not exist!

Hello @LiBL, I like your picture called "QuickSetup". BarryK built "Quicksetup FirstRUN..." that is used thruout Puppyland, now. I feel that it would be great added feature for user selection on Barry's FirstRUN to also have a selection for language. Would certainly add to the user friendliness at systems starts empowering the user of all types.

I know this was discussed in the past, and wonder if, today with the advancements made, that would be a good approach?

Looking forward, everyone.

[L18L]

This bug spelling error - Mouse/keyboard Wizard is also here, of course.
Maybe it is time for a langpack_en


@gcmartin glad you like it.
But please do not confuse me using words like "pictoral"!
It is just a common snapshot.

[linuxcbon]

WARY64 6.98

- geany lacks icons for "save all" and "build"

- starting pmusic for first time from console makes it go bad :
# defaultaudioplayer
and the console displays many empty lines and has many zombie processes...it would be better not to have pmusic, pfind, pmirror,etc by default in puppy...

- seamonkey
ERROR: Caught a segmentation fault while loading plugin file:
/usr/lib64/gstreamer-1.0/libgstlibav.so
Please either:
- remove it and restart.
- run with --gst-disable-segtrap --gst-disable-registry-fork and debug.

# defaultchat
/usr/local/bin/defaultchat: line 2: exec: mozchat: not found

PPM buggy
start ppm : between "Package" and "Description", there is a border line. Try to resize that border by moving it...
--> result : ppm will ask you many times to install "gnome icon theme"

- xine takes like 50% of CPU for playing a simple mp4 video, cpu goes hot quickly...

[linuxcbon]

WARY64 6.98

- can someone compile chromium or dillo or midori ... for wary64 to test ? Firefox/seamonkey has become the worst bloatware.

[scsijon]

Do any of you guys have experience with "udf" mount of CDs?

I was wondering, if I mounted a CD with udf filesystem, then changed a file, would the change be recognised at bootup?

That is, would the PC only see the original file, not the changed one?

udf works be writing a complete new file to the CD, and the original is still there.

I have no experience with udf.

I did it once, to play with a cd-ram drive (latest thing back then) I was asked to evaluate.

You need both the drive to be cd-ram capable and a CD-RAM disc in it, not just a cdrom disc. It takes time though as ALL the memory has to be written out and the drive seems to run at a slow multiplier (x4,x16).

You also need to tell it to look for and load your update back in, I forget who helped me back then.

@linuxcbon - maybe it would be worth having a look at midori again, it's latest has got a good writeup in a couple of online mags lately. However you need to remember Seamonkey isn't a single use package, there is an awfull lot it can do for it's size.

[rufwoof]

A 32 bit "equavalent" will be nice. I have a 1.7GHz, 384Mb RAM machine and am running 412, 431 and Wary but hey we have to move with the times. Being able to do a frugal install like with the older puppies will round it off nicely.

Quirky doesn't do frugal installs.

You have to do a full install, to a drive (such as a Flash stick) or a HD partition.

EDIT:
Well, that is what I have been saying about Quirky, as there is no support for SFS files and the layered filesystem modes as per normal pups.

However, the way I am building the live-CD, could also be implemented as a frugal install on a HD. I never thought of that before, but the live-CD, as I am currently building it, is just a "humongous vmlinuz" with everything inside it, and everything runs in RAM. There is no reason why that vmlinuz can't be anywhere, for example on a HD.

It would be easy to save a session, by opening up the vmlinuz on the HD, save changes into it, rebuild the vmlinuz, replace original.
This could just be a "save" icon on the desktop, so you can choose whether to save session of not.

Thanks, you have got me thinking of new possibilities!

For reference, I downloaded quirky64, created a empty partition on my external USB HDD (sdc3) and ran the install quirky to partition script. Failed saying I needed to download the ...xz file and I had to remove a virtual-sort (or something like that) switch from the install script to get it to run and install to the partition OK.

Next I mounted the partition and created a init file in /mnt/sdc3 that contained just

#!/bin/bash
exec /sbin/init

and gave that init executable permissions

Then I copied the vmlinuz file out of the /boot directory to where I frugal boot to (cp /mnt/sdc3/boot/vmlinuz /mnt/sda3/quirky/vmlinuz) and created a initrd.gz by

cd /mnt/sdc3
find | cpio -o -H newc | gzip >/mnt/sda3/quirky/initrd.gz

Added a entry to grub4dos menu.lst file to point to those

title quirky
root (hd0,2)
kernel /quirky/vmlinuz
initrd /quirky/initrd

and booted. ..... and as per usual for my setup it locked up when switching to graphics mode (I normally have to toy around with getting this nvidia based pc to correctly start pup's).

Dropped those vmlinuz and initrd.gz into my PXE server directory and PXE booted another PC .... and got tied up in some kind of tty5 crash loop. But most of the way to fully booting a version that is somewhat like a full install - but into/running from ram.

I have run a few other pups that way - which I called non-layered pup as its a frugal without the normal puppy layers (/initrd/pup_rw ...etc). For such a non-layered pup (or memory based full install...whatever you want to call it) you have to edit the source directory contents to make changes (and rebuild a new initrd.gz). What I sometimes do is copy /root outside of the initrd file (to somewhere on RW HDD space) so that many config changes and program config file changes are preserved across reboots. Can't recall the exact commands offhand, but something like

mv /root/root-orig
ln -s /mnt/sda3/root /root
restartwm

where /mnt/sda3/root initially contained a copy of /root and is on a RW HDD

[rufwoof]

There is a way to in effect load a sfs under a full install - by mounting the sfs and then copying its contents to /root

Or - as I more usually do, simply recursive sym link copy the entire contents of the sfs to the / root directory

mkdir -p /mnt/some
mount -t squashfs /some.sfs /mnt/some
cd /
cp -rs /mnt/some/* .

That way the sfs app's can be run as though the sfs had been mounted and when you use sym links instead of copying the source files/programs being used by Linux are the ones inside the compressed filesystem (sfs).

I've toyed around with using relatively small main puppy loaded as a memory based full install (non layered frugal) and having the bulk of files inside a squashed file system - so a memory based full install in effect running using compressed file system for much of its total size.

[Ted Dog]

Turns out UDF is not as useful anymore as it once was, newer ISO formats offer better usefulness in data roles. UDF is still needed for Video formats. There is patched tools for full use of optical drives such as multisession with larger than 4G files sizes allowed such as BluRay.
However common boot just see the first session Other 64bit and pBurn support the updated isofile formats. Been using and testing with it for past two years, BluRay is 8X faster ( as a minimum ) than DVD and easily equals class 10 flashdrives on write speed, generally far faster on reads then any Flashdrive ( about equal to IDE harddrives ) and only 4 pennies per G.
However does not seem compatible with CD but I haven't looked into that since the early work with BluRay.

[Ted Dog]

A 32 bit "equavalent" will be nice. I have a 1.7GHz, 384Mb RAM machine and am running 412, 431 and Wary but hey we have to move with the times. Being able to do a frugal install like with the older puppies will round it off nicely.

Quirky doesn't do frugal installs.

You have to do a full install, to a drive (such as a Flash stick) or a HD partition.

EDIT:
Well, that is what I have been saying about Quirky, as there is no support for SFS files and the layered filesystem modes as per normal pups.

However, the way I am building the live-CD, could also be implemented as a frugal install on a HD. I never thought of that before, but the live-CD, as I am currently building it, is just a "humongous vmlinuz" with everything inside it, and everything runs in RAM. There is no reason why that vmlinuz can't be anywhere, for example on a HD.

It would be easy to save a session, by opening up the vmlinuz on the HD, save changes into it, rebuild the vmlinuz, replace original.
This could just be a "save" icon on the desktop, so you can choose whether to save session of not.

Thanks, you have got me thinking of new possibilities!

Lol guess you didn't read my thread for UEFI bootloader, Already done that as bootloop mounted iso, works great. save back would be easy since the grub.lst is editible even in windows8.

http://murga-linux.com/puppy/viewtopic.php?t=97141
[/url]

[Ted Dog]

Code: Select all

mkisofs -iso-level 4 -D -R -o $OUTPUT -b isolinux.bin -no-emul-boot -boot-load-size 4 -boot-info-table \
      -eltorito-alt-boot -eltorito-platform efi -b efiboot.img -no-emul-boot "$tmp_isoroot"      

      isohybrid -u $OUTPUT

Since not using EFI leave out the alt boot section. This iso-level is supported by newest windows8 and 10 ( beta ) with naming restrictions. Allows large file sizes ( to size of media, ie 23.5 G limit for BluRay singles ) etc.

[gcmartin]

Thanks @Ted Dog. Much insight and accuracy in the items you point to. And for the running filesystem, don't forget the benefit(s) provided by "growisofs" for the results I think you are trying to achieve. The ability runs the gamut from DVD's to BluRay

Hope this is helpful

Seems I will have to back away from April64/WARY64 due to unexplained problems seen in the HDDs on the 2 systems this has been tested.

Lastly, the offering you are presenting us 64bit users is NOT its size. Its the beneficial functionality that PUPs bring as they exploit the PC for our benefit. It similar to what you get with SeaMonkey in all its glory. Its similar to what you get with Libre in all its glory. Its similar to those things which bring stability and functionality on a platform design to provide the hardware to make our lives easy and useful.

I would not care if it was 100kb or 1000MB as long as its stable, perform fast, and is functional without hesitation when applications are used and, again, is stable and fast. In my 50 years on these beasts, I have never once thought in terms of their size. I don't use them because of their size. I use them for what they do for my needs. And my needs have moved from a "text only world" to one where their is text, and multimedia, and automation, and ...

This all started with 8bit to 16bit to 32bit to 64bit. Believe me, as you are as old as I, you have heard the same size argument, today, that you heard in the 8bit days. Same is try for "bloat": Another word used when someone disapproves of something done by someone else.

No offense to anyone. This is a history I have seen. It may not be welcomed, but, it is a history.

Lastly, @BarryK I will continue to monitor progress. But, I must take down the running WARY64. I am hopeful some insight emerges to shed light on why I have had HDD problems using the 2 recent 64bit PUPs. If I find something of interest, I will continue to monitor for any assistance anyone can provide to explain the 2 problems.

[don570]

Right click menu utility updated - open xine full screen
Note that this package works for April64 and Wary64

http://www.datafilehost.com/d/5399778e
(untick download box to avoid the download app)
Right-click-64bit-6.9.7.pet 2.46mb

___________________________________________

I've been using it for a day. The only two problems--->

-pschedule doesn't work if hours are set
-after a day's use my USB stick icon disappeared mysteriously from desktop,
but it was still mounted.
pmount was able to safely unmount it.

[rufwoof]

Well, that is what I have been saying about Quirky, as there is no support for SFS files and the layered filesystem modes as per normal pups.

However, the way I am building the live-CD, could also be implemented as a frugal install on a HD. I never thought of that before, but the live-CD, as I am currently building it, is just a "humongous vmlinuz" with everything inside it, and everything runs in RAM. There is no reason why that vmlinuz can't be anywhere, for example on a HD.

Having squashfs and mksquashfs compiled/built-in is desirable IMO.

A full install type installation into ram with a small vmlinuz, small initrd that mounts/loads a sfs using the likes of sym links enables that main/large sfs to remain compressed (potentially highly compressed) with only the required bits being pulled out (decompressed/loaded into main memory) as/when required.

vmlinuz runs
which starts init
init mounts -t squashfs some large sfs to some mount point
cp -rs (sym link) the entire contents of that mount point (large sfs) to the root directory

additional sfs's can be loaded also by sym linking the contents. And there's no need for aufs or unionfs (layered file system). For saving/persistence, some kind of rsync (difference synchronisation) might suffice.

3.19 kernels are starting to more fully support LZ4 compression which generally is faster than shifting non compressed data. Half the size after being compressed, runs through decompression 4 times faster than I/O type processing speeds (arbitrary choice of figures). Such that read and decompress say 50MB of LZ4 compressed data is faster than just reading 100MB of non compressed. My own mksquashfs currently supports LZ4, but my kernel doesn't support lz4 squashfs (so I can't currently load a sfs that was produced using mksquashfs with lz4 compression as mount -t squashfs doesn't recognise lz4 compressed format, i.e. I can only unsquash the sfs).

In short dropping layered fs is ok, but ignoring/dropping squashfs might lead to subsequent regret.

To reiterate/highlight what I posted earlier and assuming you're ok with having hundreds/thousands of sym links : (see attached - they are all sym links into a highly compressed squashed file system on a no layers pup, so the root part overhead is relatively low/little (sym link pointer cost), whilst each individual program/file can be accessed (decompressed into main memory) by the kernel as/when required).

[BarryK]

@BarryK asks for these results:

Code: Select all

# gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.10

Problem opening /dev/sda for reading! Error is 2.
The specified file does not exist!

Hello @LiBL, I like your picture called "QuickSetup". BarryK built "Quicksetup FirstRUN..." that is used thruout Puppyland, now. I feel that it would be great added feature for user selection on Barry's FirstRUN to also have a selection for language. Would certainly add to the user friendliness at systems starts empowering the user of all types.

I know this was discussed in the past, and wonder if, today with the advancements made, that would be a good approach?

Looking forward, everyone.

As /dev/sda* device nodes are not there, it is a problem with the Linux kernel.

Unless... you used the Childproof thing in the Filesystem menu.

Childproofing can be used to hide partitions, by deleting the device nodes. If you had run this application, then /etc/init.d/.childproof would exist.

..but, you said your system is pristine Wary64. So, it looks like a kernel problem with your drive.

[BarryK]

A 32 bit "equavalent" will be nice. I have a 1.7GHz, 384Mb RAM machine and am running 412, 431 and Wary but hey we have to move with the times. Being able to do a frugal install like with the older puppies will round it off nicely.

Quirky doesn't do frugal installs.

You have to do a full install, to a drive (such as a Flash stick) or a HD partition.

EDIT:
Well, that is what I have been saying about Quirky, as there is no support for SFS files and the layered filesystem modes as per normal pups.

However, the way I am building the live-CD, could also be implemented as a frugal install on a HD. I never thought of that before, but the live-CD, as I am currently building it, is just a "humongous vmlinuz" with everything inside it, and everything runs in RAM. There is no reason why that vmlinuz can't be anywhere, for example on a HD.

It would be easy to save a session, by opening up the vmlinuz on the HD, save changes into it, rebuild the vmlinuz, replace original.
This could just be a "save" icon on the desktop, so you can choose whether to save session of not.

Thanks, you have got me thinking of new possibilities!

For reference, I downloaded quirky64, created a empty partition on my external USB HDD (sdc3) and ran the install quirky to partition script. Failed saying I needed to download the ...xz file and I had to remove a virtual-sort (or something like that) switch from the install script to get it to run and install to the partition OK.

Next I mounted the partition and created a init file in /mnt/sdc3 that contained just

#!/bin/bash
exec /sbin/init

and gave that init executable permissions

Then I copied the vmlinuz file out of the /boot directory to where I frugal boot to (cp /mnt/sdc3/boot/vmlinuz /mnt/sda3/quirky/vmlinuz) and created a initrd.gz by

cd /mnt/sdc3
find | cpio -o -H newc | gzip >/mnt/sda3/quirky/initrd.gz

Added a entry to grub4dos menu.lst file to point to those

title quirky
root (hd0,2)
kernel /quirky/vmlinuz
initrd /quirky/initrd

and booted. ..... and as per usual for my setup it locked up when switching to graphics mode (I normally have to toy around with getting this nvidia based pc to correctly start pup's).

Dropped those vmlinuz and initrd.gz into my PXE server directory and PXE booted another PC .... and got tied up in some kind of tty5 crash loop. But most of the way to fully booting a version that is somewhat like a full install - but into/running from ram.

I have run a few other pups that way - which I called non-layered pup as its a frugal without the normal puppy layers (/initrd/pup_rw ...etc). For such a non-layered pup (or memory based full install...whatever you want to call it) you have to edit the source directory contents to make changes (and rebuild a new initrd.gz). What I sometimes do is copy /root outside of the initrd file (to somewhere on RW HDD space) so that many config changes and program config file changes are preserved across reboots. Can't recall the exact commands offhand, but something like

mv /root/root-orig
ln -s /mnt/sda3/root /root
restartwm

where /mnt/sda3/root initially contained a copy of /root and is on a RW HDD

That is all about to change, see my blog post:

http://bkhome.org/news/?viewDetailed=00172

This is a non-layered frugal, using zram, runs totally in ram. Works great!

[Ted Dog]

So will it be just an kernel image or will it be wrapped in an ISO. There are ways around the first session boot file issue, but some hardware does have a bug with sessions.. I have lot of RW optical media so that is still possible.
Looks like a long weekend for us... waiting..

[rufwoof]

Great!

Does zram also imply zswap?

I don't run with a swap partition/file, so I presume the kernel splits available ram down the middle and backends half as swap space. Ideally both front and back ends would be using compression (zram and zswap).

I find that even with just 1.5GB of available ram puppy works very well (at least for me) and that its not worth having disk based swap areas/regions into which confidential data might at times be written.

I also don't use a savefile - and just remaster whenever I need to preserve any changes (I keep puppy light, running totally in ram and store all docs/data on HDD (outside of pup space)). I very much like having the exact same pristine factory fresh core files (puppy) at each and every reboot.