devil-linux-discuss — General Mailing List for all discussions

Re: [Devil-Linux-discuss] Interface Install

[Serge L. <ser...@gm...>]

Brad,

could you please show the output from "lspci -v"?


Serge

On 09/21/2011 12:13 PM, Bradlee Landis wrote:
> I am trying Devil Linux on a server. I was told to use igb drivers,
> but the interfaces aren't showing up. I tried adding "alias eth0 igb"
> and "alias eth0 e1000" and running "modprobe eth0", but neither
> worked. Any idea how to get it working?
>

[Devil-Linux-discuss] Interface Install

[Bradlee L. <bra...@gm...>]

I am trying Devil Linux on a server. I was told to use igb drivers,
but the interfaces aren't showing up. I tried adding "alias eth0 igb"
and "alias eth0 e1000" and running "modprobe eth0", but neither
worked. Any idea how to get it working?

-- 
Thanks,
Brad Landis

Re: [Devil-Linux-discuss] portmap in config?

[Dominic R. <dl...@ed...>]

On 16/09/11 17:14, Heiko Zuerker wrote:
> Quoting Dominic Raferd<dl...@ed...>:
>
>> I have moved both my machines to DL 1.4.3-2011-09-02 [server edition]
>> from the previous DL 1.4.3 testing release. In one case I was asked to
>> go through the normal 'upgrade' process at boot time, in the other I wasn't.
>>
>> On the machine that did not 'upgrade' I have an [unselected] entry for
>> 'PORTMAP' in setup (both in the setup program [no explanatory text at
>> the bottom though] and in /etc/sysconfig/config), on the machine that
>> did 'upgrade' there is no such entry.
> Not sure about that. If it's empty, simply remove it. Upgrade-config
> will create any missing entries automatically.
>
>> Re-running save-config maintains these configurations i.e. they stay
>> different.
>>
>> I try to maintain these machines as mirrors so this difference gets
>> flagged, that's why I noticed it.
>>
>> Which is right? Is there a way to force the upgrade script to run (if it
>> has not run when it should)?
> Change the file /etc/Devil-release, so it reflects an older version.
> This will invoke the upgrade-config during the next boot.
>
I did that but it still didn't run. So I remade the flash drive, this 
time selecting Syslinux without serial console, and then it worked okay.

Originally for this machine I selected 'Syslinux with serial console' 
(just as an experiment, I have never used serial console), and found 
that most of the start-up information never appears on the screen, and 
similarly the upgrade never appears.

After this successful upgrade, the /etc/sysconfig/config file was broken 
(so that setup / services does not run) - the same situation that arose 
with my other machine, see my Mantis report. I wonder if the new broken 
line in this file, which I have to remove manually, is meant to relate 
to portmap?

Re: [Devil-Linux-discuss] portmap in config?

[Heiko Z. <he...@zu...>]

Quoting Dominic Raferd <dl...@ed...>:

> I have moved both my machines to DL 1.4.3-2011-09-02 [server edition]
> from the previous DL 1.4.3 testing release. In one case I was asked to
> go through the normal 'upgrade' process at boot time, in the other I wasn't.
>
> On the machine that did not 'upgrade' I have an [unselected] entry for
> 'PORTMAP' in setup (both in the setup program [no explanatory text at
> the bottom though] and in /etc/sysconfig/config), on the machine that
> did 'upgrade' there is no such entry.

Not sure about that. If it's empty, simply remove it. Upgrade-config  
will create any missing entries automatically.

> Re-running save-config maintains these configurations i.e. they stay
> different.
>
> I try to maintain these machines as mirrors so this difference gets
> flagged, that's why I noticed it.
>
> Which is right? Is there a way to force the upgrade script to run (if it
> has not run when it should)?

Change the file /etc/Devil-release, so it reflects an older version.  
This will invoke the upgrade-config during the next boot.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org

[Devil-Linux-discuss] portmap in config?

[Dominic R. <dl...@ed...>]

I have moved both my machines to DL 1.4.3-2011-09-02 [server edition] 
from the previous DL 1.4.3 testing release. In one case I was asked to 
go through the normal 'upgrade' process at boot time, in the other I wasn't.

On the machine that did not 'upgrade' I have an [unselected] entry for 
'PORTMAP' in setup (both in the setup program [no explanatory text at 
the bottom though] and in /etc/sysconfig/config), on the machine that 
did 'upgrade' there is no such entry.

Re-running save-config maintains these configurations i.e. they stay 
different.

I try to maintain these machines as mirrors so this difference gets 
flagged, that's why I noticed it.

Which is right? Is there a way to force the upgrade script to run (if it 
has not run when it should)?

Dominic

Re: [Devil-Linux-discuss] sieve-support for dovecot

[Heiko Z. <he...@zu...>]

Yes please create a feature request, otherwise it's very likely we'll forget
about your request. ;-)

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


> -----Original Message-----
> From: Udo Lembke [mailto:udo...@al...]
> Sent: Friday, September 02, 2011 3:37 AM
> To: dev...@li...
> Subject: [Devil-Linux-discuss] sieve-support for dovecot
> 
> 
> Hi all,
> is it possible to add the sieve-plugin to dovecot (Pigeonhole Sieve and
> ManageSieve - see http://pigeonhole.dovecot.org/ )?
> 
> Would be nice. Should i create an feature-request on mantis?
> 
> 
> Greetings
> 
> Udo
> 
> 
>
----------------------------------------------------------------------------
--
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
price-free!
> And you'll get a free "Love Thy Logs" t-shirt when you download Logger.
> Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Devil-linux-discuss mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss

[Devil-Linux-discuss] new 1.4.3 test version has been uploaded

[Heiko Z. <he...@zu...>]

All,

 

I uploaded the current CVS version of DL into the testing directory.

ftp://ftp.devil-linux.org/pub/devel/testing/

 

-- 

 

Regards

   Heiko Zuerker

    <http://www.devil-linux.org> http://www.devil-linux.org

 

[Devil-Linux-discuss] sieve-support for dovecot

[Udo L. <udo...@al...>]

Hi all,
is it possible to add the sieve-plugin to dovecot (Pigeonhole Sieve and 
ManageSieve - see http://pigeonhole.dovecot.org/ )?

Would be nice. Should i create an feature-request on mantis?


Greetings

Udo

Re: [Devil-Linux-discuss] Problems with make prepare - makedepend failed

[Udo L. <udo...@al...>]

Hi,
sorry for the noise. You are right! There was some old stuff in the 
lfssystem.

After a clean start, make prepare work without trouble.

Thanks again

Udo

Am 26.08.2011 14:47, schrieb Heiko Zuerker:
> Udo,
>
> Quoting Udo Lembke<udo...@al...>:
>> I try to create an build-system from scratch. Using
>> lfssystem-SVN-20070314-cleaned.tar.bz2.
>>
>> prepare: makedepand failed with following error:
>> gcc -c -I. -I.    -DHAVE_STDARG_H=1  -mtune=i686 -march=i686 cppsetup.c
>> In file included from cppsetup.c:70:
>> find . -name :164: error: conflicting types for 'getline'
>> /usr/include/stdio.h:653: error: previous declaration of 'getline' was here
>>
>> I googled and found that in newer glibc the getline are defined.
>> But in which package i had to rename the getline (eg. local_getline)?
>> Can somebody give me an hint, please? Or an patch?
> Are you starting with a new and clean lfssystem?
> If yes, what's the host OS? Do you have any security features enabled?
>

Re: [Devil-Linux-discuss] Problems with make prepare - makedepend failed

[Heiko Z. <he...@zu...>]

Udo,

Quoting Udo Lembke <udo...@al...>:
> I try to create an build-system from scratch. Using
> lfssystem-SVN-20070314-cleaned.tar.bz2.
>
> prepare: makedepand failed with following error:
> gcc -c -I. -I.    -DHAVE_STDARG_H=1  -mtune=i686 -march=i686 cppsetup.c
> In file included from cppsetup.c:70:
> find . -name :164: error: conflicting types for 'getline'
> /usr/include/stdio.h:653: error: previous declaration of 'getline' was here
>
> I googled and found that in newer glibc the getline are defined.
> But in which package i had to rename the getline (eg. local_getline)?
> Can somebody give me an hint, please? Or an patch?

Are you starting with a new and clean lfssystem?
If yes, what's the host OS? Do you have any security features enabled?

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org

Re: [Devil-Linux-discuss] Problems with make prepare - gcc failed <solved>

[Heiko Z. <he...@zu...>]

Quoting Udo Lembke <udo...@al...>:

> Hi,
> i just try to build a new build-system from scratch and get an error
> during "make prepare / gcc":
>
> In file included from ../../gcc-4.1.2/libiberty/floatformat.c:40:
> ../../gcc-4.1.2/libiberty/../include/libiberty.h:526: error: expected
> declaration specifiers or '...' before numeric constant
> ../../gcc-4.1.2/libiberty/../include/libiberty.h:526: error: conflicting
> types for '__asprintf_chk'
> /usr/include/bits/stdio2.h:135: error: previous declaration of
> '__asprintf_chk' was here
> make[2]: *** [floatformat.o] Error 1
> make[2]: Leaving directory `/build/tmp/gcc4-prepare/libiberty'
> make[1]: *** [all-libiberty] Error 2
> make[1]: Leaving directory `/build/tmp/gcc4-prepare'
> make: *** [all] Error 2
>
> This patch of /build/tmp/gcc-4.1.2/include/libiberty.h solved the issue
> (found at https://bugs.gentoo.org/attachment.cgi?id=161379&action=diff )
> diff -U 3 libiberty.h.org libiberty.h
> --- libiberty.h.org     2005-09-26 22:55:10.000000000 +0200
> +++ libiberty.h 2011-08-26 08:57:31.000000000 +0200
> @@ -523,8 +523,12 @@
>   /* Like sprintf but provides a pointer to malloc'd storage, which must
>      be freed by the caller.  */
>
> +/* asprintf may be declared as a macro by glibc with
> __USE_FORTIFY_LEVEL.  */
> +
> +#ifndef asprintf
>   extern int asprintf (char **, const char *, ...) ATTRIBUTE_PRINTF_2;
>   #endif
> +#endif
>
>   #if !HAVE_DECL_VASPRINTF
>   /* Like vsprintf but provides a pointer to malloc'd storage, which
>
>
> Perhaps it's help someone else.

I assume you didn't start with a fresh lfssystem and this patch fixes  
the problem that you can't compile gcc the 2nd time around?

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org

[Devil-Linux-discuss] Problems with make prepare - makedepend failed

[Udo L. <udo...@al...>]

Hi,
I try to create an build-system from scratch. Using 
lfssystem-SVN-20070314-cleaned.tar.bz2.

prepare: makedepand failed with following error:
gcc -c -I. -I.    -DHAVE_STDARG_H=1  -mtune=i686 -march=i686 cppsetup.c
In file included from cppsetup.c:70:
find . -name :164: error: conflicting types for 'getline'
/usr/include/stdio.h:653: error: previous declaration of 'getline' was here

I googled and found that in newer glibc the getline are defined.
But in which package i had to rename the getline (eg. local_getline)?
Can somebody give me an hint, please? Or an patch?

Regards

Udo

[Devil-Linux-discuss] Problems with make prepare - gcc failed <solved>

[Udo L. <udo...@al...>]

Hi,
i just try to build a new build-system from scratch and get an error 
during "make prepare / gcc":

In file included from ../../gcc-4.1.2/libiberty/floatformat.c:40:
../../gcc-4.1.2/libiberty/../include/libiberty.h:526: error: expected 
declaration specifiers or '...' before numeric constant
../../gcc-4.1.2/libiberty/../include/libiberty.h:526: error: conflicting 
types for '__asprintf_chk'
/usr/include/bits/stdio2.h:135: error: previous declaration of 
'__asprintf_chk' was here
make[2]: *** [floatformat.o] Error 1
make[2]: Leaving directory `/build/tmp/gcc4-prepare/libiberty'
make[1]: *** [all-libiberty] Error 2
make[1]: Leaving directory `/build/tmp/gcc4-prepare'
make: *** [all] Error 2

This patch of /build/tmp/gcc-4.1.2/include/libiberty.h solved the issue 
(found at https://bugs.gentoo.org/attachment.cgi?id=161379&action=diff )
diff -U 3 libiberty.h.org libiberty.h
--- libiberty.h.org     2005-09-26 22:55:10.000000000 +0200
+++ libiberty.h 2011-08-26 08:57:31.000000000 +0200
@@ -523,8 +523,12 @@
  /* Like sprintf but provides a pointer to malloc'd storage, which must
     be freed by the caller.  */

+/* asprintf may be declared as a macro by glibc with 
__USE_FORTIFY_LEVEL.  */
+
+#ifndef asprintf
  extern int asprintf (char **, const char *, ...) ATTRIBUTE_PRINTF_2;
  #endif
+#endif

  #if !HAVE_DECL_VASPRINTF
  /* Like vsprintf but provides a pointer to malloc'd storage, which


Perhaps it's help someone else.

Udo

Re: [Devil-Linux-discuss] remote upgrade

[Andrzej O. <an...@ma...>]

Serge,

Sorry for uncomplete previous answer. I will continue.

You wrote:
> Hmm.... Probably I don't completely understand you. Yes, to update DL I have to
> have an access to the system. Somehow. ssh or serial or SOL (serial over lan) or something else. In
> essence my idea was to modify boot loader config file every time I update DL - merely create an
> additional record there to simplify rollback. I suppose I'd add this records with "boot once"
> option, to be able to load the previous BE in case of inability to boot (and reset the box by
> power). However, I still need an access at least for power management.

But how You will prefabricate proper, dedicated, config for newly installed boot image
even if you will associate config with boot immediately on kernel params.

> I don't think it's critical what loader to use. I like grub2 because it can do
> everything I need - boot from LVM, from RAID, recognize XFS and BTRFS.
> Text mode and serial console
> are also exist, but probably not so fully as in syslinux. I'm not sure if bootchain can help in
> your case, but nobody prevents from using syslinux instead on grub2.


My try with grub was unsuccesfull in connection with Intel AMT.

>> if we have remote access to grub menu. The only cheap method to remote access I know is Intel
>> AMT.
>> Can You suggest another?
>>
>
> ip-kvm, hardware serial console or SOL (aka  Intel AMT, ipmi or iLOM).

Serge, I asked about cheap solution.
Only Intel AMT SOL is built into MB and don't need separate hardware.
But AMT SOL is to hard to cooperate with grub, so I use syslinux.

Best Regards

-- 
Andrzej Odyniec

Re: [Devil-Linux-discuss] remote upgrade

[Andrzej O. <an...@ma...>]

Serge,

You wrote:
> So, you identify the proper image specifying the different name. OK. What about
> configs? Do you have the same trick for the configuration file?

No. As for now, I'm not identyfying config file according to used boot image.
I'm using this from auto-search. The only difference is inversion of question
about wrong config file version (if boot image is new) - script is waiting one minute (not 5)
and after no answer wrong config is accepted without interactive conversion.

Main is to make up remote system. Rest we can do via ssh.

Ofcourse as last before last resort we can use DL_config kernel parameter.
And absolute last resort is remote boot from remote redirected CD small diagnostic linux.
>From this linux I can do wget on new image and install it using modified install-on-usb
script working on busybox.

Multiple boot is for me as reserve for bad new DL image or broken one of boot source.
I do not alternate switched/convertible system. So typically I don't need alternate configs.

> That's fine. I don't see any problem to have more than one boot device. However,
> I'd prefer to get the loader config files synchronized. Maybe install loader on
> RAID1.

RAID solves only broken boot device problem. Problem with not booting new DL image
in particular remote context is not solved by RAID. So I need possibility to boot from
old working image if new image in this remote contaxt is broken (even if it was tested on table).

Imagine remote departament router not booting after upgrade...
Next day router must be working. But if remote site is 400km from us?...

> Hmm.... Probably I don't completely understand you. Yes, to update DL I have to
> have an access to the system. Somehow. ssh or serial or SOL (serial over lan) or something else. In
> essence my idea was to modify boot loader config file every time I update DL - merely create an
> additional record there to simplify rollback. I suppose I'd add this records with "boot once"
> option, to be able to load the previous BE in case of inability to boot (and reset the box by
> power). However, I still need an access at least for power management.


Boot how You will prefa
>
>
>
>>
>>> - The only boot-loader I know (which is capable to work with UUID and
>>> understands a lot of filesystem) is grub2 :).
>>
>> Unfortunately, Intel AMT technology use serial with semi-random i/o port, and the only
>> boot-loader with possibility to set serial console i/o port is syslinux. Autodetect of this i/o
>> port is complicated, and not supported via boot-loaders. In kernel this is relatively big code.
>> Because of
>> this I use syslinux only.
>
> I don't think it's critical what loader to use. I like grub2 because it can do
> everything I need - boot from LVM, from RAID, recognize XFS and BTRFS. Text mode and serial console
> are also exist, but probably not so fully as in syslinux. I'm not sure if bootchain can help in
> your case, but nobody prevents from using syslinux instead on grub2.
>
>
>>
>>> So, in general it looks like we have a boot loader (grub2) menu, where we can
>>> choose BE
>>
>> if we have remote access to grub menu. The only cheap method to remote access I know is Intel
>> AMT.
>> Can You suggest another?
>>
>
> ip-kvm, hardware serial console or SOL (aka  Intel AMT, ipmi or iLOM).
>
>
> Sincerely,
> Serge
>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take the hassle out of deploying and
> managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Devil-linux-discuss mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
>
>


-- 
Andrzej Odyniec

<an...@ma...>
Rada Nadzorcza Macrologic SA
ul. Kłopotowskiego 22, 03-717 Warszawa
tel. +48-222566332, kom. +48-601276572
Skype: andrzej.odyniec
Rejestr: Sąd Rejonowy dla m.st. Warszawy,
         XIII Wydział Gospodarczy Krajowego
         Rejestru Sądowego, numer 0000045462
Numer identyfikacji podatkowej: PL 5220002825
Kapitał zakładowy: 1888719 zł opłacony w całości

Re: [Devil-Linux-discuss] remote upgrade

[Serge L. <ser...@gm...>]

Andrzej,

On 08/23/2011 04:05 AM, Andrzej Odyniec wrote:
> Dears,
>
> Serge Leschinsky wrote:
>> - we have to distinguish different BEs, i.e. instead of counting on auto-search
>
> So I'm identyfying boot image using version id. This is working on my over ten remote DL
> installations. Auto-search check version on image with version on initrd. On near all instalations
> I have two or more boot devices. On each boot partition I append unique suffix to version id, i.e.
> -SD, -HD, -SSD to find proper image for boot.

So, you identify the proper image specifying the different name. OK. What about 
configs? Do you have the same trick for the configuration file?

> But boot device is selected via BIOS. so, if there is a problem with boot from one device, I
> connect to remote console via Intel AMT technology and change BIOS settings.
That's fine. I don't see any problem to have more than one boot device. However, 
I'd prefer to get the loader config files synchronized. Maybe install loader on 
RAID1.


>
>> I'd suggest using the following addition to
>> the kernel boot parameters: image=<BLOCK_DEVICE>,</PATH>,<NAME>
>> configs=<BLOCK_DEVICE>,</PATH>,<NAME>
>
> But for use kernel boot parameters, You need remote console access too.
Hmm.... Probably I don't completely understand you. Yes, to update DL I have to 
have an access to the system. Somehow. ssh or serial or SOL (serial over lan) or 
something else. In essence my idea was to modify boot loader config file every 
time I update DL - merely create an additional record there to simplify 
rollback. I suppose I'd add this records with "boot once" option, to be able to 
load the previous BE in case of inability to boot (and reset the box by power). 
However, I still need an access at least for power management.


>
>> - The only boot-loader I know (which is capable to work with UUID and
>> understands a lot of filesystem) is grub2 :).
>
> Unfortunately, Intel AMT technology use serial with semi-random i/o port, and the only boot-loader
> with possibility to set serial console i/o port is syslinux. Autodetect of this i/o port is
> complicated, and not supported via boot-loaders. In kernel this is relatively big code. Because of
> this I use syslinux only.

I don't think it's critical what loader to use. I like grub2 because it can do 
everything I need - boot from LVM, from RAID, recognize XFS and BTRFS. Text mode 
and serial console are also exist, but probably not so fully as in syslinux. I'm 
not sure if bootchain can help in your case, but nobody prevents from using 
syslinux instead on grub2.


>
>> So, in general it looks like we have a boot loader (grub2) menu, where we can
>> choose BE
>
> if we have remote access to grub menu. The only cheap method to remote access I know is Intel AMT.
> Can You suggest another?

ip-kvm, hardware serial console or SOL (aka  Intel AMT, ipmi or iLOM).


Sincerely,
Serge

Re: [Devil-Linux-discuss] remote upgrade

[Andrzej O. <an...@ma...>]

Dears,

Serge Leschinsky wrote:
> - we have to distinguish different BEs, i.e. instead of counting on auto-search

So I'm identyfying boot image using version id. This is working on my over ten remote DL
installations. Auto-search check version on image with version on initrd. On near all instalations
I have two or more boot devices. On each boot partition I append unique suffix to version id, i.e.
-SD, -HD, -SSD to find proper image for boot.

But boot device is selected via BIOS. so, if there is a problem with boot from one device, I
connect to remote console via Intel AMT technology and change BIOS settings.

> I'd suggest using the following addition to
> the kernel boot parameters: image=<BLOCK_DEVICE>,</PATH>,<NAME>
> configs=<BLOCK_DEVICE>,</PATH>,<NAME>

But for use kernel boot parameters, You need remote console access too.

> - The only boot-loader I know (which is capable to work with UUID and
> understands a lot of filesystem) is grub2 :).

Unfortunately, Intel AMT technology use serial with semi-random i/o port, and the only boot-loader
with possibility to set serial console i/o port is syslinux. Autodetect of this i/o port is
complicated, and not supported via boot-loaders. In kernel this is relatively big code. Because of
this I use syslinux only.

> So, in general it looks like we have a boot loader (grub2) menu, where we can
> choose BE

if we have remote access to grub menu. The only cheap method to remote access I know is Intel AMT.
Can You suggest another?

Regards

Andrzej Odyniec

Re: [Devil-Linux-discuss] remote upgrade

[Serge L. <ser...@gm...>]

Hi Dominic,

On 08/19/2011 11:44 PM, Dominic Raferd wrote:
..
> More generally, remote upgrade is tricky with DL (which some might see
> as a good thing).
I'm afraid you are right.... I spent some time thinking how we can improve the 
situation and now I'd like to share my idea (and code, if volunteers exist)

for the system designed with security and 'recoverability' in mind (i.e. image 
and configs are the only things which are necessary to recover the system) we 
should be able to have more than one Boot Environment (BE, image + configs) for 
really fast rollbacks. The consequences from the statement above are:

- CDROM as a primary image source is not vital anymore, because it's a paint to 
change/swap disks in it. I guess this is fine, because almost everybody uses 
flash-drives now.

- we have to distinguish different BEs, i.e. instead of counting on auto-search 
we should be able to identify where those files are. I'd suggest using the 
following addition to the kernel boot parameters:
image=<BLOCK_DEVICE>,</PATH>,<NAME> configs=<BLOCK_DEVICE>,</PATH>,<NAME>

it allows to have configs and images on different partitions or on different 
devices and have all images/configs in different directories. I'd also wold like 
to have an ability to rename those files.

- <BLOCK_DEVICE> can be identified as a device name, as a FS LABEL or UUID (see 
blkid output). I personally prefer to use UUID to be immune to volatile device 
names.

- The only boot-loader I know (which is capable to work with UUID and 
understands a lot of filesystem) is grub2 :).


So, in general it looks like we have a boot loader (grub2) menu, where we can 
choose BE. DL update is equivalent of an additional BE creating, rollback is 
equivalent of reboot into different BE.

I believe it will simplify the upgrade and rollbacks and make remote management 
a bit less tricky.

Serge

Re: [Devil-Linux-discuss] grsec / remote upgrade

[Dominic R. <dl...@ed...>]

Well, maybe you don't need to upgrade (if it is all working okay apart 
from this one mystery message)?

More generally, remote upgrade is tricky with DL (which some might see 
as a good thing). Upgrading via  DL's ethernet connection is out because 
the upgrade process starts before networking does. Possible workarounds 
that I can think of:

    * If DL machine is a VM then you can presumably get access to its
      local screen via the host
    * Serial port connection (if you have a serial connection from DL
      machine to another local machine which you then access remotely by
      SSH/VPN/whatever)
    * Peppercon Eric Express or similar device which presents the DL
      machine's local screen as a web page under Java (also allowing
      local keyboard input). You might pick one up cheaply on eBay?

Also (except in VM situation) you probably need a minion locally to do 
the physical switch-over of CD or flash drive, and in practice this is a 
must so that you can regress the upgrade if necessary.

Dominic

On 19/08/11 21:40, Bradlee Landis wrote:
> It's a little difficult to update when the servers are 2 states away,
> and I only go once a year. Luckily, this one is only an hour away, so
> I can update this one, but we want to get them all to one version.
>
> I don't think I can just copy the boot/ files to update, because then
> it makes some binaries unusable (such as shutdown), and would be
> catastrophic if it broke the system.
>
> Thanks for the help.
>
> On Fri, Aug 19, 2011 at 9:26 AM, Dominic Raferd
> <dl...@ed...>  wrote:
>> I think grsec is only found in the 'non-server' version of DL. Also
>> Heiko reported there may be some issues with grsec in 1.4.1, probably
>> better to move to current release 1.4.2 (or 1.4.3-testing).
>>
>> HTH
>>
>> Dominic (who only uses DL-server version)
>>
>> On 19/08/2011 15:14, Bradlee Landis wrote:
>>> I have multiple Devil Linux's in the field, and I thought I installed
>>> them all from the same source, but I'm seeing one that says it is
>>> kernel 2.6.32.27-grsec, where as all the others don't have grsec. This
>>> is making a line show up in the logs:
>>>
>>> src@localhost kernel: : grsec: From 76.77.16.176: denied use of ioperm() ...
>>>
>>> Most machines are running 1.4.1, but I only see this one machine with
>>> grsec enabled. Why is it turned on here and not elsewhere, did I
>>> download a different binary? Or was the 1.4.1 changed at some point?
>>> Will having grsec enabled affect programs?
>>>
>> ------------------------------------------------------------------------------
>> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
>> user administration capabilities and model configuration. Take
>> the hassle out of deploying and managing Subversion and the
>> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
>> _______________________________________________
>> Devil-linux-discuss mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
>>
>
>

Re: [Devil-Linux-discuss] grsec

[Bradlee L. <bra...@gm...>]

It's a little difficult to update when the servers are 2 states away,
and I only go once a year. Luckily, this one is only an hour away, so
I can update this one, but we want to get them all to one version.

I don't think I can just copy the boot/ files to update, because then
it makes some binaries unusable (such as shutdown), and would be
catastrophic if it broke the system.

Thanks for the help.

On Fri, Aug 19, 2011 at 9:26 AM, Dominic Raferd
<dl...@ed...> wrote:
> I think grsec is only found in the 'non-server' version of DL. Also
> Heiko reported there may be some issues with grsec in 1.4.1, probably
> better to move to current release 1.4.2 (or 1.4.3-testing).
>
> HTH
>
> Dominic (who only uses DL-server version)
>
> On 19/08/2011 15:14, Bradlee Landis wrote:
>> I have multiple Devil Linux's in the field, and I thought I installed
>> them all from the same source, but I'm seeing one that says it is
>> kernel 2.6.32.27-grsec, where as all the others don't have grsec. This
>> is making a line show up in the logs:
>>
>> src@localhost kernel: : grsec: From 76.77.16.176: denied use of ioperm() ...
>>
>> Most machines are running 1.4.1, but I only see this one machine with
>> grsec enabled. Why is it turned on here and not elsewhere, did I
>> download a different binary? Or was the 1.4.1 changed at some point?
>> Will having grsec enabled affect programs?
>>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Devil-linux-discuss mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
>



-- 
Thanks,
Brad Landis

Re: [Devil-Linux-discuss] grsec

[Dominic R. <dl...@ed...>]

I think grsec is only found in the 'non-server' version of DL. Also 
Heiko reported there may be some issues with grsec in 1.4.1, probably 
better to move to current release 1.4.2 (or 1.4.3-testing).

HTH

Dominic (who only uses DL-server version)

On 19/08/2011 15:14, Bradlee Landis wrote:
> I have multiple Devil Linux's in the field, and I thought I installed
> them all from the same source, but I'm seeing one that says it is
> kernel 2.6.32.27-grsec, where as all the others don't have grsec. This
> is making a line show up in the logs:
>
> src@localhost kernel: : grsec: From 76.77.16.176: denied use of ioperm() ...
>
> Most machines are running 1.4.1, but I only see this one machine with
> grsec enabled. Why is it turned on here and not elsewhere, did I
> download a different binary? Or was the 1.4.1 changed at some point?
> Will having grsec enabled affect programs?
>

[Devil-Linux-discuss] grsec

[Bradlee L. <bra...@gm...>]

I have multiple Devil Linux's in the field, and I thought I installed
them all from the same source, but I'm seeing one that says it is
kernel 2.6.32.27-grsec, where as all the others don't have grsec. This
is making a line show up in the logs:

src@localhost kernel: : grsec: From 76.77.16.176: denied use of ioperm() ...

Most machines are running 1.4.1, but I only see this one machine with
grsec enabled. Why is it turned on here and not elsewhere, did I
download a different binary? Or was the 1.4.1 changed at some point?
Will having grsec enabled affect programs?

-- 
Thanks,
Brad Landis

Re: [Devil-Linux-discuss] Huawei E220 USB 3G modem problem - device descriptor read/64, error -71

[Frank W. <Fra...@ct...>]

dm...@dz... wrote:

>
>Hello all!
>
>I'm having problems connecting Huawei e220 3G/HSDPA dongle to my DL box.
>
>Looks like DL does not recognize this USB device at all - I don't see it with lsusb and have the following errors in the dmesg output:
>
>hub 1-0:1.0: unable to enumerate USB device on port 1
>usb 1-1: new full speed USB device using uhci_hcd and address 26
>usb 1-1: device not accepting address 26, error -71
>usb 1-1: new full speed USB device using uhci_hcd and address 27
>usb 1-1: device not accepting address 27, error -71
>usb 1-1: new full speed USB device using uhci_hcd and address 28
>usb 1-1: device descriptor read/64, error -71
>usb 1-1: device descriptor read/64, error -71
>usb 1-1: new full speed USB device using uhci_hcd and address 29
>usb 1-1: device descriptor read/64, error -71
>usb 1-1: device descriptor read/64, error -71
>hub 1-0:1.0: unable to enumerate USB device on port 1
>
>Any ideas please?...
>
>This modem should have vendor=0x12d1 product=0x1003 if this matters...
>
>---
>Best Regards,
>Dmitry
>
>------------------------------------------------------------------------------
>Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
>user administration capabilities and model configuration. Take 
>the hassle out of deploying and managing Subversion and the 
>tools developers use with it. 
>http://p.sf.net/sfu/wandisco-dev2dev
>_______________________________________________
>Devil-linux-discuss mailing list
>Dev...@li...
>https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
>

Re: [Devil-Linux-discuss] Huawei E220 USB 3G modem problem - device descriptor read/64, error -71

[Dmitry K. <dm...@dz...>]

Hello,

yes, this is how it is intended to work. But the problem is that system does not enumerate USB dongle correctly - lsusb sees no USB device attached while it should.

Regsrds,
Dmitry

----- Original Message -----
From: "Dominic Raferd" <dl...@ed...>
To: dev...@li...
Sent: Thursday, August 11, 2011 5:08:33 PM GMT +02:00 Athens, Beirut, Bucharest, Istanbul
Subject: Re: [Devil-Linux-discuss] Huawei E220 USB 3G modem problem - device descriptor read/64, error -71

you could try:

modprobe usbserial vendor=0x12d1 product=0x1003

more info (Debian-based) at http://wiki.debian.org/Huawei/E220

If this doesn't work then maybe DL's kernel is not compiled with the 
necessary support?

Dominic

On 11/08/2011 14:14, dm...@dz... wrote:
> Hello all!
>
> I'm having problems connecting Huawei e220 3G/HSDPA dongle to my DL box.
>
> Looks like DL does not recognize this USB device at all - I don't see it with lsusb and have the following errors in the dmesg output:
>
> hub 1-0:1.0: unable to enumerate USB device on port 1
> usb 1-1: new full speed USB device using uhci_hcd and address 26
> usb 1-1: device not accepting address 26, error -71
> usb 1-1: new full speed USB device using uhci_hcd and address 27
> usb 1-1: device not accepting address 27, error -71
> usb 1-1: new full speed USB device using uhci_hcd and address 28
> usb 1-1: device descriptor read/64, error -71
> usb 1-1: device descriptor read/64, error -71
> usb 1-1: new full speed USB device using uhci_hcd and address 29
> usb 1-1: device descriptor read/64, error -71
> usb 1-1: device descriptor read/64, error -71
> hub 1-0:1.0: unable to enumerate USB device on port 1
>
> Any ideas please?...
>
> This modem should have vendor=0x12d1 product=0x1003 if this matters...
>
> ---
> Best Regards,
> Dmitry
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it.
> http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Devil-linux-discuss mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
>

------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. 
http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
Devil-linux-discuss mailing list
Dev...@li...
https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss

Re: [Devil-Linux-discuss] Huawei E220 USB 3G modem problem - device descriptor read/64, error -71

[Dominic R. <dl...@ed...>]

you could try:

modprobe usbserial vendor=0x12d1 product=0x1003

more info (Debian-based) at http://wiki.debian.org/Huawei/E220

If this doesn't work then maybe DL's kernel is not compiled with the 
necessary support?

Dominic

On 11/08/2011 14:14, dm...@dz... wrote:
> Hello all!
>
> I'm having problems connecting Huawei e220 3G/HSDPA dongle to my DL box.
>
> Looks like DL does not recognize this USB device at all - I don't see it with lsusb and have the following errors in the dmesg output:
>
> hub 1-0:1.0: unable to enumerate USB device on port 1
> usb 1-1: new full speed USB device using uhci_hcd and address 26
> usb 1-1: device not accepting address 26, error -71
> usb 1-1: new full speed USB device using uhci_hcd and address 27
> usb 1-1: device not accepting address 27, error -71
> usb 1-1: new full speed USB device using uhci_hcd and address 28
> usb 1-1: device descriptor read/64, error -71
> usb 1-1: device descriptor read/64, error -71
> usb 1-1: new full speed USB device using uhci_hcd and address 29
> usb 1-1: device descriptor read/64, error -71
> usb 1-1: device descriptor read/64, error -71
> hub 1-0:1.0: unable to enumerate USB device on port 1
>
> Any ideas please?...
>
> This modem should have vendor=0x12d1 product=0x1003 if this matters...
>
> ---
> Best Regards,
> Dmitry
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it.
> http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Devil-linux-discuss mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
>