Porteus Nemesis v3.2 BUG REPORTS

Arch based Porteus community project

Moderator: M. Eerie

User avatar
brokenman
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: Porteus Nemesis v3.2 BUG REPORTS

Post#46 by brokenman » 17 Nov 2015, 13:37

It is hanging because /etc/mtab is copied into changes. Removing this file from changes allows bootup. I am in the process of fixing this.

EDIT:
Some great finds here guys. Thanks very much for your work. A lot for me to sift through. I will address some now and the rest after more investigation.

this is not making it to pacman-settings.xzm:
/var/lib/pacman/local/ALPM_DB_VERSION

Thanks I was looking for this.

@aus9
The shared object permissions are stock standard out of the arch packages.
I will start creating relative symlinks. Later coreutils has this function: ln -rs

you may have inadvertantly stripped the certs?
I haven't stripped anything from certificates. Strange. I will check it out.

/etc/arch-release is an empty file
This is normal from old time arch version days. No harm symlinking it though, will do it.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
normalGuy
Black ninja
Black ninja
Posts: 52
Joined: 06 Nov 2015, 23:36
Distribution: porteus 3.2 xfce archBang
Location: uk & portugal

Re: Porteus Nemesis v3.2 BUG REPORTS

Post#47 by normalGuy » 17 Nov 2015, 19:13

Ok I hope this is not my mistake but:
- Install in a usb pen from linux with ext4
- All was working pman and firefox wifi etc
- Reboot: during shutdown: red letters "fail to unmount live..." too fast to read. **
- Startup: "live system is ready now - starting Porteus" and then it hangs
- Reboot again: Always fresh> delete the folder changes created during setup.pman and pman -S firefox.
- Pman stuff again but answer no to changes folder.
- Some situation after reboot: only in fresh mode working.
- From windows with fat32 the some=**

aus9

Re: Porteus Nemesis v3.2 BUG REPORTS

Post#48 by aus9 » 17 Nov 2015, 22:53

The shared object permissions are stock standard out of the arch packages.
ArchLinux IMHO has errors if they have not made them 755
not a bug, contents removed
Last edited by aus9 on 18 Nov 2015, 23:32, edited 1 time in total.

User avatar
francois
Contributor
Contributor
Posts: 6434
Joined: 28 Dec 2010, 14:25
Distribution: xfce plank porteus nemesis
Location: Le printemps, le printemps, le printemps... ... l'hiver s'essoufle.

Re: Porteus Nemesis v3.2 BUG REPORTS

Post#49 by francois » 18 Nov 2015, 01:25

1.0 Activating function does not work here, either with double-click or resorting to right-click contextual menu.

2.0 Is there a way to inactivate the first run wizard?
Prendre son temps, profiter de celui qui passe.

User avatar
brokenman
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: Porteus Nemesis v3.2 BUG REPORTS

Post#50 by brokenman » 18 Nov 2015, 01:51

The first run wizard was removed from auto startup Francois. Also double click on a module works ok to activate.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
brokenman
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: Porteus Nemesis v3.2 BUG REPORTS

Post#51 by brokenman » 18 Nov 2015, 02:24

@ncmprhnsbl
I just redownloaded ca-certificates-cacerts and this is the file content.
root /mnt/sda10/mystuff/archporteus/git # tar xvf /var/cache/pacman/pkg/ca-certificates-cacert-20140824-2-any.pkg.tar.xz -C /tmp/un/
.PKGINFO
.INSTALL
.MTREE
usr/
usr/share/
usr/share/ca-certificates/
usr/share/licenses/
usr/share/licenses/ca-certificates-cacert/
usr/share/licenses/ca-certificates-cacert/LICENSE
usr/share/ca-certificates/trust-source/
usr/share/ca-certificates/trust-source/anchors/
usr/share/ca-certificates/trust-source/anchors/CAcert.org_class3.crt
usr/share/ca-certificates/trust-source/anchors/CAcert.org_root.crt

Am I missing something here?
How do i become super user?
Wear your underpants on the outside and put on a cape.

northpeter1954
White ninja
White ninja
Posts: 8
Joined: 09 Jul 2014, 08:33
Distribution: mepis
Location: Havering

Re: Porteus Nemesis v3.2 BUG REPORTS

Post#52 by northpeter1954 » 18 Nov 2015, 02:57

normalGuy wrote:Ok I hope this is not my mistake but:
- Install in a usb pen from linux with ext4
- All was working pman and firefox wifi etc
- Reboot: during shutdown: red letters "fail to unmount live..." too fast to read. **
- Startup: "live system is ready now - starting Porteus" and then it hangs
- Reboot again: Always fresh> delete the folder changes created during setup.pman and pman -S firefox.
- Pman stuff again but answer no to changes folder.
- Some situation after reboot: only in fresh mode working.
- From windows with fat32 the some=**
I get this every time.
I can bypass the problem by re-starting in text mode (without persistence) then using mc to delete /mnt/sda4/nemesis/changes/etc/mtab.
Restart in graphics mode with changes=/mnt/sda4/nemesis then works.
brokenman wrote:It is hanging because /etc/mtab is copied into changes. Removing this file from changes allows bootup. I am in the process of fixing this.

User avatar
brokenman
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: Porteus Nemesis v3.2 BUG REPORTS

Post#53 by brokenman » 18 Nov 2015, 03:18

aus9, can you find any other sources that state that all shared objects should be set 755?

I am loath to change the defaults of the developers of the packages. Not all shared objects need to be executable. In fact, as guest, I can execute a non-executable owned by root. Consider this:

Code: Select all

root# ls -l `which ls`
-rwxr-xr-x 1 root root 122352 Nov 14 19:36 /usr/bin/ls
root# cp `which ls` .
root# chmod -x ls
guest$ ./ls
bash: ./ls: Permission denied
guest$ /usr/lib/ld-linux-x86-64.so.2 ./ls
Desktop  Documents  Downloads  ls  Music  Pictures  Public  Templates  Videos
If dlopen() is run against an object with 0644 permissions it will simply open a new file handle. No harm done. I see no reason to set all shared objects to 755 ... but the guys that are smarter than me probably see a reason NOT to set all shared objects this way. I am always open to being convinced.

It is going to be a few days before I get time to clean up he current bugs and release a new ISO so hopefully the irresponsible mtab screwup doesn't annoy too many people. mtab was deprecated in favour of symlinking directly to /proc/self/mounts which I didn't account for. My bad. Next release I will test more instead of rushing something out for you guys to tinker with.
How do i become super user?
Wear your underpants on the outside and put on a cape.

aus9

Re: Porteus Nemesis v3.2 BUG REPORTS

Post#54 by aus9 » 18 Nov 2015, 04:09

@brokenman
aus9, can you find any other sources that state that all shared objects should be set 755?
I have not looked, IMHO a more relevant question is .....if Arch or Manjaro say it should be 755 would that suffice?
I would then join up to pose such a question. I have not joined up yet as I am not sure how you will react. Apparently my good looks alone were not enough to convince you :D

Yes I have read your test.

2) No need to reply if wasting your time, but setup-pman command ???

How do I get it to run without a read function that asks if I want to create a module for setup-pman
line 161 concerns itself with normal module building.

I saw setup-config-pman but when I ran that, it gave no options that suit my purpose.

If you understand my purpose, that might help? My purpose is that anyone starting Nemesis for the first time, might have an auto script or just a readme saying
run setup-pman and it becomes non-interactive. IMHO we need it to create the pacman-settings.xzm and not allow newbies to not create it.

Irrespective that it might have gremlin detected by ncmprhnsbl for the missing /var/lib/pacman/local/ALPM_DB_VERSION which I lacked the skills to detect so good job there!

Thanks for reading no matter what your decision becomes

aus9

Re: Porteus Nemesis v3.2 BUG REPORTS

Post#55 by aus9 » 18 Nov 2015, 04:16

In the meantime, a quick search found rute and another discussing shared object 755

http://rute.2038bug.com/node26.html.gz

This looks better
http://www.cprogramming.com/tutorial/sh ... x-gcc.html
Using ldconfig to modify ld.so

What if we want to install our library so everybody on the system can use it? For that, you will need admin privileges. You will need this for two reasons: first, to put the library in a standard location, probably /usr/lib or /usr/local/lib, which normal users don’t have write access to. Second, you will need to modify the ld.so config file and cache. As root, do the following:

snip

Code: Select all

$ cp /home/username/foo/libfoo.so /usr/lib
$ chmod 0755 /usr/lib/libfoo.so

User avatar
ncmprhnsbl
DEV Team
DEV Team
Posts: 3924
Joined: 20 Mar 2012, 03:42
Distribution: v5.0-64bit
Location: australia
Contact:

Re: Porteus Nemesis v3.2 BUG REPORTS

Post#56 by ncmprhnsbl » 18 Nov 2015, 08:03

must part of the install process creates these files...cause they appear on reinstall.....

Code: Select all

/etc/ca-certificates/extracted/
ca-bundle.trust.crt  cadir  email-ca-bundle.pem  objsign-ca-bundle.pem  tls-ca-bundle.pem
probly this from
/var/lib/pacman/local/ca-certificates-cacert-20140824-2/install

Code: Select all

post_install() {
  usr/bin/update-ca-trust
}
same for other cert pkgs
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44

aus9

Re: Porteus Nemesis v3.2 BUG REPORTS

Post#57 by aus9 » 18 Nov 2015, 12:20

@ncmprhnsbl
I forgot to mention that brokenman has already asked me in the suggestions posts to do this before complaining about certificates

root powers

Code: Select all

update-ca-trust
2) git no longer in this build?

Code: Select all

su
pman -S git
grabs 2 packages git and perl-error*

3) You can now test the ca bundle
ls -al /etc/ssl/certs/ca-certificates.crt
lrwxrwxrwx 1 root root 17 Nov 15 16:37 /etc/ssl/certs/ca-certificates.crt -> /etc/ssl/cert.pem

4) a quick test you have certificates working is use lynx as it does not have its own certificates so relies on system certs

Code: Select all

lynx https://cert-test.sandbox.google.com/
5) slightly longer test using git, as guest or root

Code: Select all

cd /tmp
git clone https://code.google.com/p/setuid-sandbox/
Cloning into 'setuid-sandbox'...
Unpacking objects: 100% (89/89), done.
Checking connectivity... done.
Last edited by aus9 on 18 Nov 2015, 12:47, edited 1 time in total.

aus9

Re: Porteus Nemesis v3.2 BUG REPORTS

Post#58 by aus9 » 18 Nov 2015, 12:42

@brokenman @ncmprhnsbl

This now allows me to voice some concerns I have with certificates and I assume the update command has be run and then you install the other certificates as mentioned above a few posts

ONE
update-ca-trust leads to certs now existing at /etc/ca-certificates, while most other distros and this one initially had ca-certificates at /usr/share
TWO
The original "trusted" package was at /usr/share/ca-certificates but on update command its not!
THREE
a casual observer might be mislead by the folder called "trust-source". They might think this package is somehow better than other Certificate Authority (CA) certificates.

I then unsquashed the package to look at the reason why brokenman was querying it in the earlier post. Here is my verdict. Its the original package that brokenman installed in the iso.
It contains the folder trust-source

In other words, this package maintainer did something right in having original certificates started in /usr/share but the update puts certificates in /etc/ca-certificates

THIS MEANS YOU NOW HAVE 2 FOLDERS CALLED CA-CERTIFICATES I angry so sorry for shout
:evil:

certifcates must be also be in /etc/ssl/certs but he/she has certificates at /etc/ca-certificates on the update command. I have looked at this and still can't explain it. So to answer brokenman's question to our Arch guru
Am I missing something here?
Yes the builder has not got it right IMHO. Unfortunately I have yet to complete 2 build scripts to give us openssl and mozilla certificates. I am still learning Arch but hope to have more to say in about 10 days time....yes I need to do lots of testing and certs is not yet built the arch way.

User avatar
brokenman
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: Porteus Nemesis v3.2 BUG REPORTS

Post#59 by brokenman » 18 Nov 2015, 12:58

IMHO we need it to create the pacman-settings.xzm and not allow newbies to not create it.
Understood. The firstrun wizard will take care of this. I removed it until I can create a GUI popup. Yes I agree it is essential to run these things for the newcomer.
setup-pman now updates the certificates too.

Thanks for digging into the certificates thing. I was scratching my head for a while. If this is an upstream bug, then the best I can do is create a missing symlink and run update-ca-trus and wait for upstream to fix it. In this scenario things work and I don't have to revert changes once it gets fixed.

IMHO a more relevant question is .....if Arch or Manjaro say it should be 755 would that suffice?
I don't mean to second guess, but if I am not 100% on something myself, I prefer to have 2 or 3 sources confirming facts.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
brokenman
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: Porteus Nemesis v3.2 BUG REPORTS

Post#60 by brokenman » 18 Nov 2015, 14:06

On some synaptics touchpads I experience touchpad freezes. The mouse becomes inactive for some seconds for apparently no reason. The 'Disable While Typing' is causing this.

Code: Select all

xinput --list   # <-- get name/number of touchpad
xinput list-props 12
# Look to see if disable touchpad while typing is set to 1, if so disable it.
xinput set-prop 12 "libinput Disable While Typing Enabled" 0
How do i become super user?
Wear your underpants on the outside and put on a cape.

Locked