Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 28 Jan 2020, 18:38
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
DebianDog - Jessie (21 June 2017)
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 37 of 68 [1013 Posts]   Goto page: Previous 1, 2, 3, ..., 35, 36, 37, 38, 39, ..., 66, 67, 68 Next
Author Message
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Thu 18 Feb 2016, 23:23    Post subject:  

Hi Fred/rufwoof,

I'm admittedly currently using MintPup, not DD Jessie, but wondered if I am missing something (?) when I recently upgraded libc6 using (I think...) procedure described in link:

http://www.cyberciti.biz/faq/linux-patch-cve-2015-7547-glibc-getaddrinfo-stack-based-buffer-overflow/

I'm using Porteus boot save on exit with changes directory and immediately rebooted system (choosing save option) on upgrade. Unfortunately, I can't actually remember if I followed the above link's apt-get update; apt-get upgrade recommendation or simply did apt-get update && apt-get install libc6... I suspect the latter - sorry, I should have taken note more carefully...

Now, ldd --version gives:

Code:
ldd (Ubuntu EGLIBC 2.19-0ubuntu6.7) 2.19


Above link title is:

Quote:
How To Patch and Protect Linux Glibc Getaddrinfo Stack-based Buffer Overflow Zero Day Vulnerability CVE-2015-7547 and CVE-2015-5229 [ 16/Feb/2016 ]
by Vivek Gite on February 17, 2016 last updated February 17, 2016
in CentOS, Debian / Ubuntu, Linux, RedHat and Friends, Suse


Cheers,

William

_________________
github mcewanw
Back to top
View user's profile Send private message Visit poster's website 
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Fri 19 Feb 2016, 03:43    Post subject:  

oops... seems to be something wrong with my MintPup install now - at least, Open Link to new Tab in Firefox suddenly not working at all. I suspect my upgrade libc attempt caused a problem afterall. I don't have time to look into it - I'm just clearing my changes file and starting from blank again...

William

EDIT: Okay, I used rufwoof's HOWTO method and that seems to have worked.

_________________
github mcewanw
Back to top
View user's profile Send private message Visit poster's website 
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Fri 19 Feb 2016, 05:11    Post subject:  

Hmmm... Actually "Open Link in New Tab" still no longer working in Firefox (version 44.0.2) in MintPup after apt-get update && apt-get upgrade using Howto method given by rufwoof.

Not sure if it is Firefox issue, but suspect the libc upgrade.

William

_________________
github mcewanw
Back to top
View user's profile Send private message Visit poster's website 
saintless


Joined: 11 Jun 2011
Posts: 3882
Location: Bulgaria

PostPosted: Fri 19 Feb 2016, 07:06    Post subject:  

Hi William, Fred, rufwoof.

mcewanw wrote:
Not sure if it is Firefox issue, but suspect the libc upgrade.

It is firefox issue but it is better not to post MintPup problems in DD-Jessie thread. Only few people read few posts back and understand what the discussion is about.
I will post the solution in MintPup thread.

To make it clear:

1. DebianDog doesn't have problem with Firefox.

2. DebianDog-Jessie (Wheezy, Squeeze and MintPup) do not have problem upgrading to any libc6 version.
The problem appears only in one situation using porteus-boot:
After upgrading libc6 in save file (folder) and then booting with the same save file (folder), but this time using changes=EXIT:/ boot code. And then upgrading again libc6 with newer version and then trying to save the changes. Most probably you will never have the same situation.

This problem has nothing to do with libc6 upgrade. Using dpkg/apt-get/synaptic to replace the active libc6 libs in your system will use preinstall (preremove) scripts, stopping and starting depending services in official and safe way to replace the old libc6 files.
This is what porteus-boot save on EXIT also does, but saving the changes only in RAM (outside the saved system). Then using save2flash (and snapmergepuppy) scripts to copy the libc6 files process fails, because the files included in libc6 package in the last saved and loaded in read-write mode "module" (/mnt/live/memory/images/changes-exit) are in use by the system and other services also use them at the same time. I don't know if this is a bug or not in porteus-boot. (Edit: By bug I mean changes-exit should be mounted in read-only mode on boot and remounted RW only when saving changes in my opinion, but it is impossible to remount it read-only and this means some files are in use by the system and can't be replaced without crash. But it is also possible the problem is somewhere else and I'm wrong about that).

BTW in Jwm version using save2flash makes Jwm restart and typing safe2flash second time makes the copy process finish. After reboot the libc6 is upgraded. Probably it depends on the WM or hardware specifications.

In my opinion the only fix we need is line at top of snapmergepuppy script to exit if there is libc6 file in /mnt/live/memory/changes and in /mnt/live/memory/images/changes-exit at the same time. With some GUI warning or echo command about possible crash. Or just keep it documented as rufwoof suggests.

Toni

_________________
Farewell, Nooby, you will be missed...
Back to top
View user's profile Send private message MSN Messenger 
fredx181


Joined: 11 Dec 2013
Posts: 4258
Location: holland

PostPosted: Fri 19 Feb 2016, 17:04    Post subject:  

Hi Toni, William, rufwoof,

I think (should test some more) the solution for the GLIBC upgrade using save-on-exit is this (really simple Smile ):
Change line 89 in /usr/bin/snapmergepuppy from this;
Code:
# Finally, copy files unconditionally.
cp -a -f "$N" "$BASE/$N"

To this:
Code:
# Finally, copy files unconditionally.
cp -a --remove-destination "$N" "$BASE/$N"


I found out with experimenting first by copying libc-2.19.so to .renamed first e.g:
Code:
# copy to renamed:
cp -a  /mnt/live/memory/changes/lib/i386-linux-gnu/libc-2.19.so /mnt/saved/lib/i386-linux-gnu/libc-2.19.so.renamed
# rename to original name in changes-exit
mv -f  /mnt/saved/lib/i386-linux-gnu/libc-2.19.so.renamed /mnt/saved/lib/i386-linux-gnu/libc-2.19.so

No crash doing the above, but doing just this (not renamed first) gives the crash:
Code:
cp -a  /mnt/live/memory/changes/lib/i386-linux-gnu/libc-2.19.so /mnt/saved/lib/i386-linux-gnu/libc-2.19.so

Also I tried rsync command on line 89 in snapmergepuppy, no crashing.
But save2flash using rsync is much slower.

To test easy after making the change in snapmergepuppy:
Code:
apt-get install --reinstall libc6
save2flash


Edit: Tested more now with older version of libc6 installed:
Code:
apt-get install libc6=2.19-18+deb8u2 libc-bin=2.19-18+deb8u2

Rebooted
Changed line 89 in snapmergepuppy, then:
Code:
apt-get upgrade

350 MB upgrade including latest libc6
save2flash
Everything just fine, GLIBC upgraded to latest.

Fred
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3717

PostPosted: Fri 19 Feb 2016, 19:01    Post subject:  

Nice one Fred. That's really great.
Back to top
View user's profile Send private message 
saintless


Joined: 11 Jun 2011
Posts: 3882
Location: Bulgaria

PostPosted: Sat 20 Feb 2016, 05:25    Post subject:  

Hi Fred.

I can't reproduce the crash in a way to force hard reboot. I get something like jwm restart - the background disappears and appears again - and typing second time save2flash works saving the upgraded libc6. So the problem depends on window manager or hardware.
fredx181 wrote:
I think (should test some more) the solution for the GLIBC upgrade using save-on-exit is this (really simple Smile ):
Change line 89 in /usr/bin/snapmergepuppy from this;
Code:
# Finally, copy files unconditionally.
cp -a -f "$N" "$BASE/$N"

To this:
Code:
# Finally, copy files unconditionally.
cp -a --remove-destination "$N" "$BASE/$N"

I don't mind if you like to fix it this way. But it sounds like "cp -f" command has a bug and the fix is to use "cp --remove-destination" instead. The real bug in my opinion is the system keeps libc6 files in /mnt/live/memory/images/changes-exit busy even after the upgraded version in /mnt/live/memory/changes is installed. And I can't see any good reason to keep /mnt/live/memory/images/changes-exit mounted read-and-write all the tiime. Even just because you can delete some files by mistake there and break the save file while using Save on Exit boot code without saving the changes.
We use "cp -f" command in many scripts for a long time and this is the only case it fails so far. And it is not cp command fault.
What happens when "cp --remove-destination" fails in some other situation?
The real bug in the system is not fixed and we don't even know yet what is the cause for it. Changing cp command option is just another workaround.

Toni

_________________
Farewell, Nooby, you will be missed...
Back to top
View user's profile Send private message MSN Messenger 
fredx181


Joined: 11 Dec 2013
Posts: 4258
Location: holland

PostPosted: Sat 20 Feb 2016, 07:41    Post subject:  

Hi Toni,

Quote:
I can't reproduce the crash in a way to force hard reboot. I get something like jwm restart - the background disappears and appears again - and typing second time save2flash works saving the upgraded libc6. So the problem depends on window manager or hardware.


Did you test the way I described on my Edit in previous post?
Doesn't need to be a full upgrade in the end, just libc6 and libc-bin.

All I'm saying from my tests is that --remove-destination is more suitable for the job that snapmergepuppy needs to do, not a bug in "cp -f".
I disagree on calling this "another workaround" because it works well from my tests.
But we better do more testing of course.

Some force option is needed, otherwise some files will not be overwritten (cp error: " Cannot create regular file")
From what I understand is that:
- the --remove-destination option removes the destination file in any case.
- with the --force option it tries to overwrite first in a normal way, if that doesn't succeed it will remove the file first.

In case of copying libc-2.19.so
Code:
cp -a --remove-destination /mnt/live/memory/changes/lib/i386-linux-gnu/libc-2.19.so /mnt/saved/lib/i386-linux-gnu/libc-2.19.so

No crash happens for me, but in case of:
Code:
cp -a -f /mnt/live/memory/changes/lib/i386-linux-gnu/libc-2.19.so /mnt/saved/lib/i386-linux-gnu/libc-2.19.so

It crashes, I *think* because the file doesn't get removed first.

In my opinion there is no bug (well, only in snapmergepuppy), as I said, replacing in snapmergepuppy the "cp" command by "rsync" all works fine, no crashing.

Edit:
Quote:
And I can't see any good reason to keep /mnt/live/memory/images/changes-exit mounted read-and-write all the tiime. Even just because you can delete some files by mistake there and break the save file while using Save on Exit boot code without saving the changes.


Sorry, I don't understand what you mean exactly, can you explain how you see it as optimal?

Fred
Back to top
View user's profile Send private message 
saintless


Joined: 11 Jun 2011
Posts: 3882
Location: Bulgaria

PostPosted: Sat 20 Feb 2016, 09:34    Post subject:  

Hi Fred.
fredx181 wrote:
Hi Toni,

Quote:
I can't reproduce the crash in a way to force hard reboot. I get something like jwm restart - the background disappears and appears again - and typing second time save2flash works saving the upgraded libc6. So the problem depends on window manager or hardware.


Did you test the way I described on my Edit in previous post?
Doesn't need to be a full upgrade in the end, just libc6 and libc-bin.

Yes, I did. And I did a lot of testing yesterday removing and renaming libc-2.19.so before running save2flash and always I get jwm restart issue instead hard reboot crash.

Quote:
Code:
cp -a -f /mnt/live/memory/changes/lib/i386-linux-gnu/libc-2.19.so /mnt/saved/lib/i386-linux-gnu/libc-2.19.so

It crashes, I *think* because the file doesn't get removed first.

Why it doesn't get removed? This is where the bug appears and it is real bug in porteus-boot. Try this with save on Exit boot using save folder with some already installed packages inside.
Code:
ls /mnt/live/memory/images/changes-exit

Then run (make sure you don't have some drive partition mounted manually there first):
Code:
rm -fr /mnt/live/memory/images/changes-exit

Tell me what happens and does "save on Exit" save changes only on reboot or running save2flash?

Now lets check out how live-boot works upgrading libc6 using the same "save on Exit" method (yes, live-boot does that easy).
Boot live-boot-3 frugal with persistence save file and do the same test:
Code:
apt-get update
apt-get install libc6=2.19-18+deb8u2

Reboot adding persistence-read-only

Code:
title DebianDog persistence-read-only
root=(hd0,0)
kernel /live/vmlinuz1 boot=live config quickreboot noeject showmounts persistence persistence-read-only
initrd /live/initrd.img

Check out mount command and you will see /dev/loop1 (your save file) mounted read-only and all changes will be saved in RAM and lost after reboot.
Upgrade to the latest libc6:
Code:
apt-get install libc6

Now use mnt-img to mount persistence save file and try the same "cp -a -f" command that fails with porteus-boot save on Exit:
Code:
cp -a -f /lib/live/mount/overlay/root/* /media/+lib+live+mount+persistence+sda1+persistence/

Reboot and check out the libc6 version. It is upgraded and saved without crash, without jwm restart, without copy errors.

Do you still think it is snapmergepuppy script bug and changing cp command is a fix?

Toni

_________________
Farewell, Nooby, you will be missed...
Back to top
View user's profile Send private message MSN Messenger 
fredx181


Joined: 11 Dec 2013
Posts: 4258
Location: holland

PostPosted: Sat 20 Feb 2016, 10:59    Post subject:  

Hi Toni,

Ok, I think I see what you mean now:
A real fix in your opinion would be to mount changes-exit readonly from the start and only (re)mount it read-write at the point of using save2flash (at shutdown or during a session), right?

Maybe it's possible to have the same save-on-exit option for live-boot (don't know if you are thinking in that direction)

Btw, looking at linuxrc it seems mounted read-only (ro+wh, or maybe it should be rr+wh):
Code:
 echo "  $m  changes-exit"; mount -no remount,add:1:/memory/images/changes-exit=ro+wh aufs /union


The comparison with live-boot as you described is different case as there's no aufs involved when mounting with mnt-img:
Quote:
Now use mnt-img to mount persistence save file and try the same "cp -a -f" command that fails with porteus-boot save on Exit:
Code:
cp -a -f /lib/live/mount/overlay/root/* /media/+lib+live+mount+persistence+sda1+persistence/



I will think about this more anyway.

Fred
Back to top
View user's profile Send private message 
saintless


Joined: 11 Jun 2011
Posts: 3882
Location: Bulgaria

PostPosted: Sat 20 Feb 2016, 11:45    Post subject:  

Hi Fred.

I don't think to add save on Exit option in live-boot. It is simple and easy to do it manually.
As I wrote I don't mind if you like to change cp command and It is fine for me to leave changes-exit mounted RW. But it is the possible reason for this problem. Keeping it RW mounted all the time probably leaves some process using libc6 files active even after the upgrade.

With or without aufs involved the older libc6 files should be replaced without errors from "cp -f". This is the real problem that needs fixing. Everything else is workaround with unpredictable results.

The point is we should not rush providing fix so easy just because it works now.
"cp -a -f" command is tested over two years and now when it fails in one situation you like to change it with different option tested only few hours. And still we don't know why "cp -f" fails. This type of fixes do not make DebianDog better.

Toni

_________________
Farewell, Nooby, you will be missed...
Back to top
View user's profile Send private message MSN Messenger 
rufwoof


Joined: 24 Feb 2014
Posts: 3717

PostPosted: Sat 20 Feb 2016, 13:49    Post subject:  

Hi Toni
saintless wrote:
With or without aufs involved the older libc6 files should be replaced without errors from "cp -f". This is the real problem that needs fixing

Looking around and it would seem that the -f option is known to be weaker in some cases than --remove-destination. I believe that -f will "attempt" to unlink the file and try again if the first case fails (and that unlink could also fail), whereas --remove-destination is a more forceful remove file before trying type choice.

I guess that libc6 perhaps is resilient to both being replaced or unlinked such that the -f switch choice fails, whereas --remove-destination is more successful.

Not really sure, just highlighting things that I've read recently.

Maybe the existing -f case should have a error number test being made afterwards, so mostly runs as currently coded, with a follow up --remove-destination additional piece of code if that -f based error number is non zero. (Note that I don't even know if the -f current case returns a non zero exit code when attempting to cp the libc6). Or maybe just extended to use cp --remove-destination only when the file being copied is libc6 otherwise the usual cp -f choice. ???
Back to top
View user's profile Send private message 
saintless


Joined: 11 Jun 2011
Posts: 3882
Location: Bulgaria

PostPosted: Sat 20 Feb 2016, 14:43    Post subject:  

Hi rufwoof.

This problem reminds me another one in remastering script caused by yad progress bar code. It took over 6 months for the same problem to reappear from DebianDog in MintPup in different situation till we can confirm serious bug in remastering script. Then and now we have different results testing some script (you get system crash and I get window manager restart instead). Then and now I'm the only one who finds different result from the same test suspicious. This makes me think the real problem is hidden for us yet.

If it proves to be copy --force option it is easy to fix it. But I see nothing wrong if we wait and don't mark this problem as solved yet. If it is a bug in the way porteus-boot overlays/mounts the changes-exit save file or something else - it will appear again. And it will reappear in ten DebianDog and one MintPup iso images (when we make iso updates).

Toni

_________________
Farewell, Nooby, you will be missed...
Back to top
View user's profile Send private message MSN Messenger 
fredx181


Joined: 11 Dec 2013
Posts: 4258
Location: holland

PostPosted: Sun 21 Feb 2016, 06:07    Post subject:  

Hi Toni, rufwoof,

Just some testing results for the save-on-exit problem:

- On JWM version the result is the same as Toni, no crashing, libc version updated.
So the bug is definitely WM related anyway, but I have no clue what is the cause.

- Tried some different options for mounting changes-exit in linuxrc (the init script in initrd1.xz):
ro, rr+wh
Made no difference.

I think it's not a good idea to further try changing linuxrc, because:
- Porteus-boot save-on-exit is working really well, I use it all the time during 2 years and never had a problem.
Changing it drastically (if I'm capable) could give other problems and needs a lot of testing.
- Maybe there's no bug at all in porteus-boot, as I said above it's WM issue anyway.

rufwoof wrote:
Looking around and it would seem that the -f option is known to be weaker in some cases than --remove-destination. I believe that -f will "attempt" to unlink the file and try again if the first case fails (and that unlink could also fail), whereas --remove-destination is a more forceful remove file before trying type choice.


Yes, from what I tested (the -v 'verbose' option is helpful);
Using cp -a in some cases cannot unlink the file, when using -f it forces by removing the file first.
The --remove-destination option removes the file in any case.

Quote:
Maybe the existing -f case should have a error number test being made afterwards, so mostly runs as currently coded, with a follow up --remove-destination additional piece of code if that -f based error number is non zero.


I thought about that also but it's not possible, I think, because the crash already occurs with cp -a -f , so there's no chance to continue (to get the return value, follow up...)

Fred
Back to top
View user's profile Send private message 
saintless


Joined: 11 Jun 2011
Posts: 3882
Location: Bulgaria

PostPosted: Sun 21 Feb 2016, 11:17    Post subject:  

Hi Fred.

I agree it is better not to touch initrd1.xz (or any other important scripts) and since you also confirm the problem depends on Window Manager it is your choice how to provide the copy option change in snapmergepuppy.
I don't think it is good idea to make deb package because uninstalling the deb will break porteus-boot functions. Probably archive with snapmergepuppy for download and information about the workaround post from rufwoof in fixes post is enough. But maybe you have different idea.

I still think changes-exit should be mounted read-only and remounted RW only when saving changes but there is no good reason to face the possible complications after such change yet. Lets just keep it in mind if similar problems appear later with save on exit.

Toni

_________________
Farewell, Nooby, you will be missed...
Back to top
View user's profile Send private message MSN Messenger 
Display posts from previous:   Sort by:   
Page 37 of 68 [1013 Posts]   Goto page: Previous 1, 2, 3, ..., 35, 36, 37, 38, 39, ..., 66, 67, 68 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0841s ][ Queries: 12 (0.0136s) ][ GZIP on ]