System: Porteus 2.1rc2, x86-64, with nVidia graphics driver (304.88) and always fresh mode, XFCe.
According to dmesg, my eth0 is a RTL8168b/8111b
Code: Select all
root@porteus:/mnt/live/memory/images# dmesg |grep -i eth0
[ 34.660767] r8169 0000:02:00.0 eth0: RTL8168b/8111b at 0xffffc9000063c000, 00:1a:92:31:92:08, XID 18000000 IRQ 44
[ 34.660773] r8169 0000:02:00.0 eth0: jumbo features [frames: 4080 bytes, tx checksumming: ko]
[ 39.184431] r8169 0000:02:00.0 eth0: link down
[ 163.280779] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
As you can see, when starting 2.1 porteus, /etc/rc.d/FireWall is
not being started... for whatever reason. After I start it manually, you see the diffecence in "status" it gives back.
Code: Select all
root@porteus:/mnt/live/memory/images# /etc/rc.d/rc.FireWall status
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
root@porteus:/mnt/live/memory/images# /etc/rc.d/rc.FireWall start
WARNING: The state match is obsolete. Use conntrack instead.
root@porteus:/mnt/live/memory/images# /etc/rc.d/rc.FireWall status
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo any anywhere anywhere
0 0 ACCEPT udp -- any any anywhere anywhere udp dpt:domain
0 0 ACCEPT udp -- any any anywhere anywhere udp spt:domain
0 0 ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ftp-data
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ftp
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:smtp
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:http
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:pop3
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:imap
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:https
0 0 LOG_DROP all -- any any anywhere anywhere
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 LOG_DROP all -- any any anywhere anywhere
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- any any anywhere anywhere
0 0 ACCEPT udp -- any any anywhere anywhere udp dpt:domain
0 0 ACCEPT udp -- any any anywhere anywhere udp spt:domain
Chain LOG_DROP (2 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- any any anywhere anywhere
Why is that still the case in 2.1rc2? Could it be because eth0 was not connected at boot time? ... But the firewall should be initiallized no matter what, right?
Code: Select all
root@porteus:/mnt/live/memory/images# ls -oa --time-style=long-iso $(find . -name rc.FireWall)
-rwxr-xr-x 1 root 2645 2010-12-20 07:18 ./001-core.xzm/etc/rc.d/rc.FireWall
root@porteus:/mnt/live/memory/images# l /etc/rc.d/rc.FireWall
-rwxr-xr-x 1 root 2645 2010-12-20 07:18 /etc/rc.d/rc.FireWall
root@porteus:/mnt/live/memory/images# md5sum /etc/rc.d/rc.FireWall ./001-core.xzm/etc/rc.d/rc.FireWall
c7bfe11b7a3e50f3874708fc7de40b0e /etc/rc.d/rc.FireWall
c7bfe11b7a3e50f3874708fc7de40b0e ./001-core.xzm/etc/rc.d/rc.FireWall
______________________________________________________________
@donald
asunder: the CD doesn't eject,the same as in Pburn
So, it's the same issue? The same reason it fails? Then it could be fixed by the same solution... or not?
The command "eject" does what it should do, just FYI...
but renaming Tracks is
easy.Select One in the list and then leftclick on the line again and rename.
Maybe I did not understand exactly what you mean.
(two germans speaking english lol)
.. lol indeed... Anyhow, I want it to change the track numbers it sets at the beginning of each file name, like W-OS "EAC" can do it.
When I have, say, 3 CDs of a audio book, it calls the first ones 01 *whatever* to 18 *whatever, and should call the 2nd part of files from CD2 NOT 01 *whatever* to 10 *whatever*, but instead 19 *whatever* to 28 *whatever*, and the files from CD3 then starting with 29 *whatever* ... and so on.
"EAC" had an edit field where I can put in a track offset, in the above examples: 19 for CD2, and 29 for CD3... (or maybe it was: 18 for CD1 and 28 for CD2... since it is 0 by default)