Puppy Linux Discussion Forum

Took a long time, but finally uploaded. Blog announcement:

https://bkhome.org/news/202206/easyos-d ... eased.html

I have a fixed 'easy-update' script. Place it at /usr/local/easy_version, and make sure executable flags set. Attached, with false ".gz" appended.

However, I tried to use it twice, and rsync disconnected. I think that the rsync server at ibiblio.org is getting overloaded certain times of the day.

You can try it, but as I posted in the blog post, might be better off using the old method to update.

I will probably have to change to script not to use rsync.

A photo:

Feedback welcome!

Fresh dd to sandisk 14GB stick. Booted and nice to see a 2sec to 5min prompt warning as mine was at the upper end of that. Set up and configured, rebooted and the storage space icon in the tray indicating 2.7GB of available space (4GB ram laptop).

Editing init (inside initrd) to sym link easy.sfs instead of copying it to ram and rebooting and indicates 4.9GB of available space. Quicker to boot (no copy of easy sfs), slower initial starting of programs.

Booted with easy sfs sym linked to ram rather than copied to ram, 4.9GB indicated as available/free and cp -ar a unsquashed fatdog sfs content to /root/tst resulted in around 2.6GB of data under /root/tst and df -h still showing 2.3GB being available 'Average' data averaging out at a average 2:1 compression rate.

When easy sfs is sym linked into ram, tmpfs space allocation for that can be reduced

mount -t tmpfs -o size=500000 tmpfs /easy_ro (otherwise for /mnt/.easy_ro)

and more space allocated to zram (I used twice freemem)

create_top_level_zram1()
...
ALLOCK=$(($FREEK*2))

With that booted and over 5GB of common data (such as extracted fatdog sfs) copied into /root, the system is still running. Re-opened initrd, fired up firefox to post this after capturing a image

is running slower, so I guess reading more from usb than otherwise might be the case, but still reasonably quick. Of the suggested 6.5GB of available space, 1.4GB is still being indicated as beig available. Not bad on a 4GB ram system that more usually sees just 3.4GB being available after GPU ...etc has taken its slice. And with no swap allocated either.

dd'd to a Toshiba usb3 external mechanical HDD, installed/configured/worked OK ... except at shutdown when the HDD heads clearly just drop rather than parking.

Tried modifying the tail end of /etc/rc.shutdown code to

#busybox umount -ar > /dev/null 2>&1
SDPARM=/usr/bin/sdparm
BB=/bin/busybox
devs=$($BB ls /sys/block | $BB grep -vE "^ram|^loop|^nbd|^dm-|^md|^nand|^zram")	# get devs for spin down
$BB umount -a -r -d
echo Filesystems stopped.

# lastly - sync & stop all disks so that rotating devices don't lose data
#if [ -z "$IS_REBOOT" ]; then # only if we're powering off
	echo -n Spin down disks ...
	for dev in $devs; do
		echo -n " $dev"
		$SDPARM -C sync /dev/$dev > /dev/null
		$SDPARM -r -C stop /dev/$dev > /dev/null
	done
	echo
#fi

#Sleep to give time for devices to quiesce.
/bin/busybox sleep 2

#the end#

as well as copying across sdparm from Fatdog to /usr/bin/sdparm. i.e. Fatdog style of parking the heads.

Works to a degree, BUT the hdd's light goes off for a second or so, and then 'fires up' again, and before the power is cut ... so the heads still just drop.

Earlier code to umount sdb (the external HDD's device) simply fails, as / (aufs) is active, even with a -force switch.

I did try another mod, trying to cut the power immediately after stopping the HDD i.e. in the brief second when it was 'off' and before near immediately restarting again - but that didn't work either.

I suspect the same might equally apply in Fatdog, haven't ever tried that.

Not a major issue for me, as its just a 500GB device that I have laying around and isn't what I'd use for a regular boot anyway. But for those that might regularly use a mechanical external USB3 HDD as a boot system, repeated head dropping from regular use could accumulate to shorten the life of the device or cause corruptions/data loss.

I've also cross posted this to the Fatdog section viewtopic.php?p=59266#p59266

With sdparm pinched from Fatdog as attached (rename without .tar suffix) and the end of /etc/rc.d/rc.shutdown modified to the following

 #attempt unmount, so f.s. without journal marked clean...
 busybox umount /mnt/${WKG_DEV} 2>/dev/console
fi

IS_POWEROFF=`cat /tmp/wmexitmode.txt`

if [ $IS_POWEROFF != "poweroff" ]; then
	busybox umount -ar > /dev/null 2>&1
else
	SDPARM=/usr/bin/sdparm
	BB=/bin/busybox
	devs=$($BB ls /sys/block | $BB grep -vE "^ram|^loop|^nbd|^dm-|^md|^nand|^zram")	# get devs for spin down
	$BB umount -a -r -d
	echo Filesystems stopped.

	# lastly - sync & stop all disks so that rotating devices don't lose data
	echo -n Spin down disks ...
	for dev in $devs; do
	    echo -n " $dev"
	    $SDPARM -C sync /dev/$dev > /dev/null
	    $SDPARM -r -C stop /dev/$dev > /dev/null
	done
	echo

	/bin/busybox umount -a -r -d
	/usr/bin/sdparm -r -C stop /dev/sdb
	/bin/busybox poweroff -f
fi	
#the end#

.. that works in my case, but where the /dev/sdb device is hard coded (hard mounted device containing the second partition of the Easy system boot). No more dinging of the usb3 external HDD heads at poweroff.

rufwoof,
hmm, yeah ok, will think about that head parking.

Regarding updating an existing installation, I have not yet tested it. After rsync disconnected twice yesterday, after a about an hour -- very slow download due to my current restricted speed by my telco -- never got to the point of testing it.

Of course, can do it the old way.

However, updating does have one fundamental problem; you can't rollback to before 4.0. Well, you can, but there is a problem...

Let's see, the rollback script is /usr/local/easy_version/easy-rollback, which creates file /.rollback.flg then reboots. The actual rollback happens in the initrd, in script /sbin/rollback

If you look in the 'rollback' script, you will see that it rolls back vmlinuz and easy.sfs, but not 'initrd' -- keeps the latest 'initrd'.

This is a problem. For example 4.0 'initrd' has EOS_TOP_LEVEL_ZRAM variable inside it, so initrd will setup top-level zram. However, the older easy.sfs does not recognise, will not have a "save" icon on desktop, etc.

I need to modify that rollback script, also rollback 'initrd'.

Another important point: the snapshot in first post shows "buster" and "pyro" containers. I have rebuilt those sfs files with lz4-hc compression.

That means they won't work with old versions of Easy that have kernel and squashfs that doesn't support lz4.

@rufwoof
When booting 4.0 on your slow flash stick, the screen first displays "looking for drives..." then it shows a speed test value.

What value do you get?

looking good so far. thanks for the choices at shutdown dialog, (and the related run in ram schema)

I went to put bookworm in a container, and sfsget is working well, except when I choose the bookworm radio button, the dialog does not populate.
(all the rest of the radio buttons populate)

BarryK wrote: Thu Jun 09, 2022 2:57 am

@rufwoof
When booting 4.0 on your slow flash stick, the screen first displays "looking for drives..." then it shows a speed test value.

What value do you get?

read speed 116.

Generally that sandisk is quite good/quick for reads, slow for writes. A couple of years old now and been written quite a few times so perhaps near EOL.

Oddly, my external usb3 HDD shows 426 when plugged into a usb3 port, and 393 when plugged into a usb2 port. All seems upside-down to 'lower is better'.

rufwoof,
I have posted to the blog about the speed test:

https://bkhome.org/news/202206/results- ... ootup.html

williwaw wrote: Thu Jun 09, 2022 3:24 am

looking good so far. thanks for the choices at shutdown dialog, (and the related run in ram schema)

I went to put bookworm in a container, and sfsget is working well, except when I choose the bookworm radio button, the dialog does not populate.
(all the rest of the radio buttons populate)

Yes, SFSget now filters out all easy*.sfs files.

You will notice in easyos/oe/pyro and easyos/debian/buster radiobuttons, that there are pyro*.sfs and buster*.sfs
I will need to use dir2sfs to build bookworm*.sfs

Will get back onto bookworm soon.

BarryK wrote: Wed Jun 08, 2022 2:41 pm

I have a fixed 'easy-update' script. Place it at /usr/local/easy_version, and make sure executable flags set. Attached, with false ".gz" appended.

The update icon on the Desktop points to /usr/sbin/easy-update and not /usr/local/easy_version/easy-update. Should both locations be updated?

I also noticed a minor hiccup on icon placement - the Trash and Lock icons are in the same location (upper right corner or desktop - see below). This is on a Dell Latitude E6400 with a 1440x900 screen resolution

Why does the 'file' icon on the desktop open the /root directory rather than /path/to/wkg_dir/files

I know /root is the historical home directory for user root, but I like Barry's new scheme better, so I just change the Rox icon link myself for instant access.

Also, with Barry's new scheme, /root/my-documents is now obsolete, so I just delete it to avoid inadvertently putting files there.

seamonkey mail missing - just at a time when google (gmail) are pretty much enforcing google also knowing your phone number (2 factor authentication, that isn't any more secure against man in middle attacks who gets to see/forward whatever 6 digit code was sms'd to your phone that you enter as confirmation that its-you).

There is claws in the repo, which is nicer in some ways IMO and only around 18MB I believe. Might be nice to squeeze that into the main system rather than new users having internet/IRC (hexchat) ...etc. but no mail option by default.

Ventoy live boot problem again.

I don't know what the first screen said, but the second screen starts about mkmod -m then finding drives can't read '/etc/fstab' no such file or directory.

Error: BOOT_FS=' ' Boot filesystem is incorrect

I don't know if it is a Ventoy or EasyOS vs Ventoy problem.

My 'bigger' Easy 3.4.7 on the Ventoy mod version is doing just fine; I'm still exploring it.

I tried the old manual upgrade before coming here to see your upgrade script fix
Like said earlier in the blog, the new Easy.sfs is too big for the boot partition
Moving the main ext4 partition with a resize, (to also be able to resize the FAT boot partition) brings up a warning in gparted that shifting the start of ext4 can cause booting to fail with linux (gparted also suggesting it has addition info somewhere to fix this error)
I chickened out, & resized the other end of the ext4 partition, & copied (& expanded) the boot partition there to manually upgrade (& using the 'manage flags' feature to have the new partition have the 'boot' & 'esp' flags)
Booting doesn't like having 2 boot partitions, so I used Pudd to backup the original boot partition to a file (*remembering Pudd's secret Step 2 of 3, mounting the destination partition/drive) then deleted the original boot partition
Next step was create an account here, after successfully booting version 4.0 with my wacky n00b method Thanks!

rudyt wrote: Thu Jun 09, 2022 3:04 pm

BarryK wrote: Wed Jun 08, 2022 2:41 pm

I have a fixed 'easy-update' script. Place it at /usr/local/easy_version, and make sure executable flags set. Attached, with false ".gz" appended.

The update icon on the Desktop points to /usr/sbin/easy-update and not /usr/local/easy_version/easy-update. Should both locations be updated?

I also noticed a minor hiccup on icon placement - the Trash and Lock icons are in the same location (upper right corner or desktop - see below). This is on a Dell Latitude E6400 with a 1440x900 screen resolution

Screenshot.png

/usr/sbin/easy-update just runs /usr/local/easy_version/easy-update

You are the first person to test updating!

I should have been the first, but ran into problems with the slow internet connection and rsync disconnecting. Then was busy with other stuff, so updating didn't get tested.

I'm surprised that trash and lock icons got overlapped. What version of Easy have you updated from?

rudyt wrote: Thu Jun 09, 2022 3:22 pm

Why does the 'file' icon on the desktop open the /root directory rather than /path/to/wkg_dir/files

I know /root is the historical home directory for user root, but I like Barry's new scheme better, so I just change the Rox icon link myself for instant access.

Also, with Barry's new scheme, /root/my-documents is now obsolete, so I just delete it to avoid inadvertently putting files there.

This is hinting to me that you have updated from a much older version of Easy.
Does the desktop label have "file" or "files"?
It is now "files"
The label "file" was quite a while ago, don't recall what version had that.

Anyway, if they are the only issues with upgrading, then you are good-to-go

fanlessFREAK wrote: Thu Jun 09, 2022 7:21 pm

I tried the old manual upgrade before coming here to see your upgrade script fix
Like said earlier in the blog, the new Easy.sfs is too big for the boot partition
Moving the main ext4 partition with a resize, (to also be able to resize the FAT boot partition) brings up a warning in gparted that shifting the start of ext4 can cause booting to fail with linux (gparted also suggesting it has addition info somewhere to fix this error)
I chickened out, & resized the other end of the ext4 partition, & copied (& expanded) the boot partition there to manually upgrade (& using the 'manage flags' feature to have the new partition have the 'boot' & 'esp' flags)
Booting doesn't like having 2 boot partitions, so I used Pudd to backup the original boot partition to a file (*remembering Pudd's secret Step 2 of 3, mounting the destination partition/drive) then deleted the original boot partition
Next step was create an account here, after successfully booting version 4.0 with my wacky n00b method Thanks!

That's great that you devised a workaround. Yes, updating the flash stick to 4.0 is a problem, as 'easy.sfs' is too big.

Prior to 4.0, the first partition is 639MiB, it is now 767MiB

You can update an installation on an internal drive, with bigger boot partition.

I might just have to advise everyone not to try and update Easy running on a flash-stick, do a new install instead.

rufwoof wrote: Thu Jun 09, 2022 3:47 pm

seamonkey mail missing - just at a time when google (gmail) are pretty much enforcing google also knowing your phone number (2 factor authentication, that isn't any more secure against man in middle attacks who gets to see/forward whatever 6 digit code was sms'd to your phone that you enter as confirmation that its-you).

There is claws in the repo, which is nicer in some ways IMO and only around 18MB I believe. Might be nice to squeeze that into the main system rather than new users having internet/IRC (hexchat) ...etc. but no mail option by default.

Yes, I was wondering if anyone still wants an email client.

SM is a PET package, so you can of course install it, but if there is demand for a email client, then probably should look at putting one into the build.

BarryK:

I was wondering if anyone still wants an email client.

I use a mail/news agent to communicate on usenet where it is useful to help resolve problems by being able to C&P from such as Easy into a usenet msg.

I recently resolved a difficult problem w/ the current LXLE focal and Claws compatibility w/ the help of Paul in alt.os.linux.

Claws 3.18.0 is in the repo/s and works fine for that.

BarryK wrote: Thu Jun 09, 2022 9:06 pm

You are the first person to test updating!

I should have been the first, but ran into problems with the slow internet connection and rsync disconnecting. Then was busy with other stuff, so updating didn't get tested.

I'm surprised that trash and lock icons got overlapped. What version of Easy have you updated from?

Sorry, I wasn't clear. I did NOT do the scripted updte for the same reason you cited. rsync wasn't cooperating for me either, so I went old-school. I extracted the three files. fixed the initrd and rebooted.

I updated from the previous version - 3.4.7

BarryK wrote: Thu Jun 09, 2022 9:12 pm

This is hinting to me that you have updated from a much older version of Easy.
Does the desktop label have "file" or "files"?
It is now "files"
The label "file" was quite a while ago, don't recall what version had that.

Anyway, if they are the only issues with upgrading, then you are good-to-go

My installation dates back to around version 3.1 or 3.2, updated with almost every release including version 3.4.7. I definitely have the 'file' icon - not 'files'. Time for a clean install. BTW, every version I've played with was good to go after upgrading. I don't mind having to do minor manual tweaks here and there, in fact, that's how I learn stuff

rudyt wrote: Thu Jun 09, 2022 11:16 pm

BarryK wrote: Thu Jun 09, 2022 9:12 pm

This is hinting to me that you have updated from a much older version of Easy.
Does the desktop label have "file" or "files"?
It is now "files"
The label "file" was quite a while ago, don't recall what version had that.

My installation dates back to around version 3.1 or 3.2, updated with almost every release including version 3.4.7. I definitely have the 'file' icon - not 'files'.

My first easy was 3.4.6 just a few weeks ago, updated to 3.4.7 will update to 4 soon maybe next weekend.
Back to the question - it is named 'File' here.

Just tried this on my new Acer M540 touch with a Ryzen 7 5700 and it fails at video setup, even when trying xorgwizard. Failing part relates to No screens found and may relate to it using a Radeon Vega GPU. I'll try to attach the Xorg.0.log for you (fake .gz as usual) in case it helps. As I have an asus PN51 on the way with the same configuration we do need to work out what's wrong (please and thank you).
ps haven't tried bookworm yet as the acer M540 is only back up today, the ram module that was origonally supplied and fitted turned out to be the problem, it was a 1x16 not 2x8 matrix, I shall create a stick and try bookworm later today, but suspect that may also fail.

measter wrote: Thu Jun 09, 2022 6:54 pm

Ventoy live boot problem again.

I don't know what the first screen said, but the second screen starts about mkmod -m then finding drives can't read '/etc/fstab' no such file or directory.

Error: BOOT_FS=' ' Boot filesystem is incorrect

I don't know if it is a Ventoy or EasyOS vs Ventoy problem.

My 'bigger' Easy 3.4.7 on the Ventoy mod version is doing just fine; I'm still exploring it.

Ventoy has released a newer v. 1.0.76 which changes how the boot of EasyOS 4.0 fails. Now the boot process proceeds to where I used to see 3.4.7 stop before there was a 'bigger'.

Creating a snapshot. This copy failed:
cp /mnt/ventoy1/initrd /mnt/ventoy2/easyos/releases/easy-4.0/inird

The ventoy dev thinks the boot of easy os 4 is fixed.

That report of Ventoy 1.0.76 + EasyOS 4 could have been more complete.

Populating: /mnt/ventoy2/easyof/release/easy-4.0
initrdcp: write error: No space left on device
This copy failed: cp /mnt/ventoy1/initrd /mn/ventoy2/easyos/releases/easy-4.0/initrd
Attempting to copy again...
cap:write error: No space left on device

Ventoy 1.0.76 + tweaked Easy OS 4.0:

# truncate -s 2G easy-4.0-amd64.img

... works.

Thanks.