Porteus-v1.1rc2-x86_64 ready for testing

New features which should be implemented in Porteus; suggestions are welcome. All questions or problems with testing releases (alpha, beta, or rc) should go in their relevant thread here, rather than the Bug Reports section.
User avatar
Hamza
Warlord
Warlord
Posts: 1908
Joined: 28 Dec 2010, 07:41
Distribution: Porteus
Location: France

Re: Porteus-v1.1rc2-x86_64 ready for testing

Post#16 by Hamza » 29 Nov 2011, 16:25

Tonio wrote:First of all, thank you for an rc2 edition of both versions. Testing 64 bit version, I startup in text mode and login as root and type startx get nice KDE. Fireup firefox and there is no connection :( I check network with

Code: Select all

# ifconfig -a
and there is no ip address. I remedy the situation with dhcpcd, is this a desired change not to pick up IP address at boot?

Code: Select all

root@porteus:~# ifconfig -a
eth0      Link encap:Ethernet  HWaddr d0:27:88:01:37:9c  
          inet6 addr: fe80::d227:88ff:fe01:379c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:357 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:31210 (30.4 KiB)  TX bytes:3526 (3.4 KiB)
          Interrupt:41 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:184 errors:0 dropped:0 overruns:0 frame:0
          TX packets:184 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:13940 (13.6 KiB)  TX bytes:13940 (13.6 KiB)

root@porteus:~# dhclient eth0
bash: dhclient: command not found
root@porteus:~# dhcpcd eth0
dhcpcd[2724]: version 5.2.12 starting
dhcpcd[2724]: eth0: broadcasting for a lease
dhcpcd[2724]: eth0: offered 10.155.132.215 from 10.155.132.10
dhcpcd[2724]: eth0: acknowledged 10.155.132.215 from 10.155.132.10
dhcpcd[2724]: eth0: checking for 10.155.132.215
dhcpcd[2724]: eth0: leased 10.155.132.215 for 691200 seconds
dhcpcd[2724]: forked to background, child pid 2748
root@porteus:~# uname -r
3.1.1-porteus
root@porteus:~# cat /etc/porteus-version 
Porteus-v1.1
root@porteus:~# 
Running with copy2ram and so far no issues other than this issue. Will let you know on other machines. Thanks!

Sorry for late answer,
You have an IP Address, but this one has been converted to ipv6 format.
The IP Address format you know is the ipv4. Some providers around the world are updating their routers and their customer's box to switch the local network to full ipv6 compatibility. That is what you have the ipv6 format instead ipv4 format. You will understand, please have a look on your ifconfig's output. You will see a line with inet6. The inet6 is the name of the line which give you the local ip address to ipv6 format. Most of Linux Distributions are ready to works with full ipv6 today. On Internet if you find out some servers compatible with ipv6, you should see the line with their ipv6 address.

Here is your ipv6 address from your ifconfig's output : fe80::d227:88ff:fe01:379c/64
If you want more explanations..The /64 is for type of ip address which it is for local network interface.
The /64 can changes if you uses a sub network.

If you have a network (old) with still ipv4 only activated. You should see the inet instead of inet6.
I have migrated my local network to full ipv6 and this doesn't change anythings to the speed/reliability of my local network.
The thing to know with the ipv6 is, now we have more ip address (ipv6 format) available than when we used ipv4.

To understand how this type of ip address, you have to know your mac address.
The IPv6 address is generated with your mac address. If you uses the pns-tool and give the same mac address to two computers, they should have the same ip addresses but this problem has been solved by most of routers of the current market by giving the ip_address+1 like the old routers with the ipv4.
If you have 192.168.1.41 on one computer, the next ip address given to the second computer should be 192.168.1.42.

To prove that you ip address is generated by using your mac address.
Your MAC Address : d0:27:88:01:37:9c
Your IPv6 Address : fe80::d227:88ff:fe01:379c/64

You should see something common on these two type address.
Your MAC Address : d0:27:88:01:37:9c
Your IPv6 Address : fe80::d227:88ff:fe01:379c/64
I hope this help you!
NjVFQzY2Rg==

User avatar
Rava
Contributor
Contributor
Posts: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Re: Porteus-v1.1rc2-x86_64 ready for testing

Post#17 by Rava » 07 Dec 2011, 20:43

Hi folks,
I was out a bit with testing Porteus due to lack of time. :unknown:

Anyhow... My System: Porteus-v1.1rc2-x86_64 with the KDE modules removed, since I want a non KDE and LXDE (or even more preferred: a XFCe only system)

It seems that "nVidia-legacy-96.43.20-porteus-v1.1-rc2-x86_64-1beny.xzm" is not really 64 bit, but only 32 bit...
I activated it running Porteus 1.1 x86_64

Code: Select all

root@porteus:/mnt# nvidia-xconfig
-bash: /usr/bin/nvidia-xconfig: No such file or directory
root@porteus:/mnt# file /usr/bin/nvidia-xconfig
/usr/bin/nvidia-xconfig: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped
(The other nVidia module by beny works okay, though.)
__________________________________________________________

And LXDE has some issues as well...
Image
The icon to the file manager seems broken, and so are all icons for the file manager itself.
Could it be that these icons are stored in the KDE module?
Cheers!
Yours Rava

User avatar
fanthom
Moderator Team
Moderator Team
Posts: 5666
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland
Contact:

Re: Porteus-v1.1rc2-x86_64 ready for testing

Post#18 by fanthom » 07 Dec 2011, 21:06

It seems that "nVidia-legacy-96.43.20-porteus-v1.1-rc2-x86_64-1beny.xzm" is not really 64 bit, but only 32 bit...
i have mixed up modules during upload - fixed now so please download again.
And LXDE has some issues as well...
leafpad is not added to the taskbar by default. i would suggest you running "Always Fresh" and empty /rootcopy dir.
All should be fine then.
Please add [Solved] to your thread title if the solution was found.

Falcony
Full of knowledge
Full of knowledge
Posts: 237
Joined: 01 Jan 2011, 12:44
Location: Russia

Re: Porteus-v1.1rc2-x86_64 ready for testing

Post#19 by Falcony » 09 Dec 2011, 05:57

Hi, fantom, brockenman!

Is it possible to add xzm and lzm files integration to Midnight Commander?

For 64-bit and 32-bit 1.1 v?

For mc it have to be like ordinary arhive - like zip, tar.pkg, deb etc.

Thuis is small thing but convinient. In FIDOSlax I included update for configuration files but better in my understanding to make in in Porteus beforhand as default settings:

here is solution:

/etc/mc

filehighlight.ini
...
[archive]
extensions=gz;bz2;tar;tgz;rpm;Z;rar;zip;arj;cab;lzh;lha;zoo;arc;ark;xz;tbz;tbz2;xzm;lzm;
...
mc.ext

# lzma
regex/\.lzma$
Open=lzma -dc %f | %var{PAGER:more}
View=%view{ascii} lzma -dc %f 2>/dev/null



# lzm
regex/\.(lzm|lZM)$
Open=rm -rf /tmp/%p; mkdir -p /tmp/%p ; xzm2dir %f /tmp/%p ; echo "File %p exctracted to /tmp/%p directory"
View=%view{ascii} unsquashfs -l %f 2>/dev/null


# xzm
regex/\.(xzm|XZM)$
Open=rm -rf /tmp/%p; mkdir -p /tmp/%p ; xzm2dir %f /tmp/%p ; echo "File %p exctracted to /tmp/%p directory"
View=%view{ascii} unsquashfs -l %f 2>/dev/null

#xz
regex/\.xz
Open=xz -dc %f | %var{PAGER:more}
View=%view{ascii} xz -dc %f 2>/dev/null

### Default ###
After pressing F3 it shows list of directories and files

If you press Enter it exctract xzm and lzm to /tmp automatically

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

Re: Porteus-v1.1rc2-x86_64 ready for testing

Post#20 by brokenman » 09 Dec 2011, 12:41

I cab add this to next release however support for lzm may be dropped.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
fanthom
Moderator Team
Moderator Team
Posts: 5666
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland
Contact:

Re: Porteus-v1.1rc2-x86_64 ready for testing

Post#21 by fanthom » 10 Dec 2011, 03:04

agree with brokenman: no go for lzm.

@Falcony
what about this code:

Code: Select all

# xzm
regex/\.xzm$               (capital XZM wont be accepted by linuxrc anyway)
Open=mloop %p; %cd /mnt/loop 
View=%view{ascii} unsquashfs -l %f 2>/dev/null
works much faster than unsquashing and is not filling up /tmp folder (i'm worrying about pressing enter on big modules by accident).

disadventages:
- modules are mounted as read only so no direct modifications possible
- working dir is changed to /mnt/loop (this could be changed)
Please add [Solved] to your thread title if the solution was found.

User avatar
Hamza
Warlord
Warlord
Posts: 1908
Joined: 28 Dec 2010, 07:41
Distribution: Porteus
Location: France

Re: Porteus-v1.1rc2-x86_64 ready for testing

Post#22 by Hamza » 10 Dec 2011, 12:27

i'm worrying about pressing enter on big modules by accident
Add a warning if the size is bigger than 50 or 100 Mb ?
Hmm... size=$(stat -c%s "$file") :roll:
NjVFQzY2Rg==

Kriss
Samurai
Samurai
Posts: 135
Joined: 06 Jul 2011, 07:07
Location: Russia

Re: Porteus-v1.1rc2-x86_64 ready for testing

Post#23 by Kriss » 12 Dec 2011, 02:58

I noticed that USB flash with Porteus 1.1rc2 x86_64 mounts to /mnt/live/mnt/sd* instead of /mnt/sd*
I'm still not sure if it's normal or not, but just so you know...
Also I can't unmount it (with copy2ram cheatcode)...
Last edited by Kriss on 13 Dec 2011, 03:25, edited 1 time in total.
Suggestions/corrections/additions are always welcome.

Falcony
Full of knowledge
Full of knowledge
Posts: 237
Joined: 01 Jan 2011, 12:44
Location: Russia

Re: Porteus-v1.1rc2-x86_64 ready for testing

Post#24 by Falcony » 12 Dec 2011, 07:32

what about this code:
# xzm
regex/\.xzm$ (capital XZM wont be accepted by linuxrc anyway)
Open=mloop %p; %cd /mnt/loop
View=%view{ascii} unsquashfs -l %f 2>/dev/null
That better. I liked
For lzm also add, please.

Regarding disadvantages - this not big,
readonly is native begavour for Midnight Commander like deb, txz packages, etc
It is also possible to add third action "Edit" by pressing F4 key - extract it to /tmp
But may be it is overkill...

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

Re: Porteus-v1.1rc2-x86_64 ready for testing

Post#25 by brokenman » 12 Dec 2011, 15:06

Done for 32bit Falcony.

I stand firm on dropping support for lzm though. I can create a module for supporting squashfs3 that users can download if they want support for old formats.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
Ahau
King of Docs
King of Docs
Posts: 1331
Joined: 28 Dec 2010, 15:18
Distribution: LXDE & Xfce 32/64-bit
Location: USA

Re: Porteus-v1.1rc2-x86_64 ready for testing

Post#26 by Ahau » 12 Dec 2011, 17:00

@Kriss,

I noticed that one of my flash drives will fail to have it's partitions mounted in /mnt/ some times (but other times they are mounted fine) in 64-bit V1.1 RC2. I added 'delay=2' to my porteus.cfg, and it seems to be mounting properly each time.

You can't unmount the partition from which you are booting Porteus in /mnt/live/mnt unless you use the copy2ram cheatcode.
Please take a look at our online documentation, here. Suggestions are welcome!

User avatar
Hamza
Warlord
Warlord
Posts: 1908
Joined: 28 Dec 2010, 07:41
Distribution: Porteus
Location: France

Re: Porteus-v1.1rc2-x86_64 ready for testing

Post#27 by Hamza » 12 Dec 2011, 20:15

Normally , You cannot unmount a partition which is currently running, but I won't show you how to bypass this problem, I am not here for this :roll:

@Falcony,
I am agree with you about the quick uncompress function - This should be very useful!
The problem we have right now is the retro compatibly of the modules. We have to move on another compression format due to high performance with the new format but we cannot drop directly and remove definitely the lzm compatibly under Porteus (I am not using any lzm modules).
Another thing about your sample code, If the user doesn't know that his module has been extracted to /tmp, He will not be able to find our where his module has been extracted and If He has not enough ram, his system can be unstable or crash in some extremes cases.

About your question on /mnt/live/mnt/sdXY.
fanthom has written a linuxrc script which it should be compatible with Porteus and it can be modified for Porteus as we want and as we requested.
The convention of mount the boot device in /mnt/live/mnt is more secure and avoid the problem of mistake in cases the user has a lot of devices/partitions mounted. Every devices mounted inside /mnt/live/mnt are mounted only and only linuxrc. I am not saying this is not possible to mount a device in this directory. The decision has been taken like this, I was also searching a way to mount all devices inside /media like Ubuntu/Gnome (but most apps uses /mnt as mounted's base path. You should see that when you plug in a device, this device when it has been mounted with a loop, the relative access path is /mnt/sdXY and not /mnt/live/mnt/sdXY.

Don't forgot that everythings inside /mnt/live has been mounted by linuxrc (expect images of modules mounted after boot). If you want to read and understand how linuxrc works, you can view the source code inside this file /mnt/live/linuxrc.

About the fanthom's advice, I am agree with him too. One of main power of Porteus is too be crazy fast!!
We have made a system to "install" a software/libraries on the fly just uses your mouse with a double click, you have installed a software. Any distributions than Porteus can do this. We have the power to be very fast at boot. Today, most of Linux distributions can boot fastly but the problem is they cannot be installed inside a USB Device.

Today, Porteus can be installed on a USB Device and IT can boot very fastly!
When I am using Always Fresh Mode, and I am booting Porteus about 30-40 seconds. With other OS, this fast boot is mostly impossible to due to a lot of unnecessary things started and used at boot. A popular linux distribution (no ads here!) has taken the challenge to boot up under 10 seconds, I am agree, their system was able to boot under 10 seconds but with a computer using a developer's hardware configuration and a common hardware like most people have today. This linux distro was unable to boot up under these 10 seconds when it has installed on a USB Device.

Porteus can be installed from the older computer to the newer computer,
We have the prefect mix with Porteus 32bit which is able to boot up on most old computers and Porteus 64bit which is able to boot up most recent computers.

If you know another distro which its size is 300MB and it can boot up under less than 30 seconds on an old computer with a USB Device using the USB 1.0 Technology. Please let us know


I hope you understand what we can do and we cannot do on Porteus. We have a plan to take over the world, and we need to be most prefect distro of the market. This is the deal.

Regards,
NjVFQzY2Rg==

Kriss
Samurai
Samurai
Posts: 135
Joined: 06 Jul 2011, 07:07
Location: Russia

Re: Porteus-v1.1rc2-x86_64 ready for testing

Post#28 by Kriss » 13 Dec 2011, 03:45

@Ahau
Yes, I always use copy2ram I just forgot to mention it...
And actually I just wanted to know if mounting boot partition to /mnt/live/mnt was intentional =)

@Hamza
... Ok I understand that use of /mnt/live/mnt/. was intentional. As I said, it's not a problem.
Although it's weird that usb flash drive mounts only there and HDDs mounts to /mnt/live/mnt/. and to /mnt/. (two mount points for one partition?)
Well, as I said earlier, I always use copy2ram cheatcode and (if memory serves me correctly) it was possible to unmount source partition later. Of course it should be fairly safe to just unplug something if it's not being used (probably with "sync") but I'd prefer to do it "properly".
Last edited by Kriss on 13 Dec 2011, 06:07, edited 1 time in total.
Suggestions/corrections/additions are always welcome.

Falcony
Full of knowledge
Full of knowledge
Posts: 237
Joined: 01 Jan 2011, 12:44
Location: Russia

Re: Porteus-v1.1rc2-x86_64 ready for testing

Post#29 by Falcony » 13 Dec 2011, 05:58

@Hamza
The problem we have right now is the retro compatibly of the modules. We have to move on another compression format due to high performance with the new format but we cannot drop directly and remove definitely the lzm compatibly under Porteus (I am not using any lzm modules).
basically for LZM I mean not support by porteus but support in midnight commander. Which have to treat it as arhive - for well know types.

Shurely I understand some complexity - as we had 2 types of lzm(remix and slax.) But I meant remix lzm in mc. lzm from slax - is past, past - so need not to use

@brokenman
Done for 32bit Falcony.
Thank you

Regarding LZM - your choice, no problem, guys! L)

User avatar
Hamza
Warlord
Warlord
Posts: 1908
Joined: 28 Dec 2010, 07:41
Distribution: Porteus
Location: France

Re: Porteus-v1.1rc2-x86_64 ready for testing

Post#30 by Hamza » 13 Dec 2011, 06:03

You can unplug your USB device after boot using copy2ram. This will not make you some troubles. :)

Sorry, but if you give the power to use the squashfs4 (lzma) module to mc..you will also give it to Porteus. Where is installed mc ? For this, we need to put squashfs3 in /usr/bin as squashfs3.

We haven't the same version of squashfs betwwen slax remix and Porteus.
NjVFQzY2Rg==

Post Reply