Menu
▾
▴
devil-linux-develop — developer discussions
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(55) |
Oct
(44) |
Nov
(156) |
Dec
(123) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(130) |
Feb
(156) |
Mar
(162) |
Apr
(171) |
May
(97) |
Jun
(127) |
Jul
(58) |
Aug
(81) |
Sep
(86) |
Oct
(45) |
Nov
(41) |
Dec
(84) |
| 2003 |
Jan
(71) |
Feb
(87) |
Mar
(133) |
Apr
(152) |
May
(151) |
Jun
(232) |
Jul
(320) |
Aug
(237) |
Sep
(271) |
Oct
(536) |
Nov
(301) |
Dec
(393) |
| 2004 |
Jan
(393) |
Feb
(184) |
Mar
(314) |
Apr
(225) |
May
(139) |
Jun
(77) |
Jul
(87) |
Aug
(75) |
Sep
(139) |
Oct
(50) |
Nov
(8) |
Dec
(28) |
| 2005 |
Jan
(66) |
Feb
(63) |
Mar
(14) |
Apr
(14) |
May
(8) |
Jun
(23) |
Jul
(21) |
Aug
(6) |
Sep
(29) |
Oct
(55) |
Nov
(38) |
Dec
(8) |
| 2006 |
Jan
(5) |
Feb
(10) |
Mar
(1) |
Apr
(15) |
May
(32) |
Jun
(44) |
Jul
(11) |
Aug
(8) |
Sep
(9) |
Oct
(14) |
Nov
(4) |
Dec
(3) |
| 2007 |
Jan
(3) |
Feb
(3) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(35) |
Aug
(49) |
Sep
(8) |
Oct
(42) |
Nov
(44) |
Dec
(7) |
| 2008 |
Jan
(2) |
Feb
(7) |
Mar
(8) |
Apr
(80) |
May
(74) |
Jun
(29) |
Jul
(5) |
Aug
(7) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
|
| 2009 |
Jan
(8) |
Feb
(19) |
Mar
(3) |
Apr
(24) |
May
(22) |
Jun
(23) |
Jul
(8) |
Aug
(23) |
Sep
(8) |
Oct
(27) |
Nov
(52) |
Dec
(27) |
| 2010 |
Jan
(36) |
Feb
(29) |
Mar
(17) |
Apr
(28) |
May
(21) |
Jun
(4) |
Jul
|
Aug
(28) |
Sep
(18) |
Oct
(6) |
Nov
(34) |
Dec
(16) |
| 2011 |
Jan
(18) |
Feb
(12) |
Mar
|
Apr
|
May
(9) |
Jun
(1) |
Jul
(5) |
Aug
(5) |
Sep
(7) |
Oct
(16) |
Nov
(26) |
Dec
(17) |
| 2012 |
Jan
(6) |
Feb
(34) |
Mar
(52) |
Apr
(10) |
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(4) |
Nov
(1) |
Dec
(4) |
| 2013 |
Jan
(5) |
Feb
|
Mar
|
Apr
(5) |
May
(4) |
Jun
|
Jul
|
Aug
(14) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
(2) |
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(11) |
| 2015 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Heiko Z. <he...@zu...> - 2012-04-12 13:30:23
|
Hello DL Community. It has finally happend: Devil-Linux 1.6 has been released! This new release brings many new features, lot's of improvements, many software updates, Kernel 3.2, and a 64 bit version! Please read the changelog for details. -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Serge L. <ser...@gm...> - 2012-04-06 16:20:30
|
Heiko, our current "login" apparently ignores /etc/login.defs. We can replace it by binary from the last util-linux (from the description - it should use /etc/login.defs AND use pam), but it's a bit more "serious" change. I checked on my systems that this modification is enough to start using sha512 (and it doesn't break old md5 hashes of course). So, we don't need to change /etc/login.defs , but we can :) And actually you are right - it's better to keep the system settings consistent. Serge On 04/06/2012 04:54 AM, Heiko Zuerker wrote: > Serge, > > Don't we also need to change /etc/login.defs ? > ENCRYPT_METHOD SHA512 > > Or is that not required with PAM ? > |
|
From: Heiko Z. <he...@zu...> - 2012-04-06 11:54:32
|
Serge, Don't we also need to change /etc/login.defs ? ENCRYPT_METHOD SHA512 Or is that not required with PAM ? -- Regards Heiko Zuerker http://www.devil-linux.org > -----Original Message----- > From: Serge Leschinsky [mailto:sma...@us...] > Sent: Friday, April 06, 2012 2:31 AM > To: dev...@li... > Subject: [Devil-linux-commit] build/config/etc/pam.d login, 1.3, 1.4 passwd, > 1.4, 1.5 > > Update of /cvsroot/devil-linux/build/config/etc/pam.d > In directory vz-cvs-3.sog:/tmp/cvs-serv23906 > > Modified Files: > login passwd > Log Message: > improve protection of local passwords - switch from md5 to sha512 > > > Index: passwd > ========================================================== > ========= > RCS file: /cvsroot/devil-linux/build/config/etc/pam.d/passwd,v > retrieving revision 1.4 > retrieving revision 1.5 > diff -u -d -r1.4 -r1.5 > --- passwd 6 Sep 2008 20:52:25 -0000 1.4 > +++ passwd 6 Apr 2012 07:30:27 -0000 1.5 > @@ -5,6 +5,6 @@ > dcredit=1 ucredit=1 lcredit=1 \ > ocredit=1 \ > dictpath=/lib/cracklib/pw_dict > -password required pam_unix.so md5 shadow use_authtok > +password required pam_unix.so sha512 shadow use_authtok > > # End /etc/pam.d/passwd > > Index: login > ========================================================== > ========= > RCS file: /cvsroot/devil-linux/build/config/etc/pam.d/login,v > retrieving revision 1.3 > retrieving revision 1.4 > diff -u -d -r1.3 -r1.4 > --- login 27 Mar 2008 14:27:03 -0000 1.3 > +++ login 6 Apr 2012 07:30:27 -0000 1.4 > @@ -12,6 +12,6 @@ > session optional pam_lastlog.so > session required pam_unix.so > password required pam_cracklib.so retry=3 > -password required pam_unix.so md5 shadow use_authtok > +password required pam_unix.so sha512 shadow use_authtok > > # End /etc/pam.d/login > > > ---------------------------------------------------------------------------- -- > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Devil-linux-commit mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-commit |
|
From: Serge L. <ser...@gm...> - 2012-04-06 07:45:00
|
I don't know about the open issues. Everything seems to be fine. Serge On 04/04/2012 04:56 AM, Heiko Zuerker wrote: > Hi everyone, > > I just wanted to check if anybody found any problems with RC3. > It has been pretty quiet, which is a very good sign. > > If no new issues surface, I'm planning to release the official 1.6 soon. > |
|
From: Andrzej O. <an...@ma...> - 2012-04-05 13:47:47
|
Heiko Zuerker wrote: > Andrzej, > > Could you please re-submit the patch as an attachment? > Of course. But there are only basic corrections, for start and check filesystems. As I see, in /etc/init.d/checkfs scrip, there are dependency from presence of files /fastboot and /forcefsck, but this files are checked in root directory, but root directory is readonly so without changing boot image there is no possibility to control fastboot (without fsck) or forced fsck. Maybe this files should be tested in /etc, or on usb/disk boot partition? But this is to Your decision. -- Andrzej Odyniec |
|
From: Heiko Z. <he...@zu...> - 2012-04-05 00:38:35
|
Andrzej, Could you please re-submit the patch as an attachment? -- Regards Heiko Zuerker http://www.devil-linux.org > -----Original Message----- > From: Andrzej Odyniec [mailto:an...@ma...] > Sent: Wednesday, April 04, 2012 12:35 PM > To: dev...@li... > Subject: Re: [Devil-linux-develop] 1.6.0-RC3 > > Heiko Zuerker wrote: > > > Hi everyone, > > > > I just wanted to check if anybody found any problems with RC3. > > It has been pretty quiet, which is a very good sign. > > > > If no new issues surface, I'm planning to release the official 1.6 soon. > > Heiko, > > I found only a cosmetic error. checkfs startup script is not executing and thus > does not check the disks listed in fstab with six non-zero field as should be. > Ofcourse anybody, who mounts nonramdisks, can change this script and > store in own configuration. There is patch: > > > --- ../../lfssystem/build/config/etc/init.d/checkfs.orig 2011-12-18 > 18:46:34.000000000 +0100 > > +++ ../../lfssystem/build/config/etc/init.d/checkfs 2012-04-01 > 18:04:34.280769382 +0200 > > @@ -19,7 +19,7 @@ > > source /etc/init.d/functions > > > > # exit if there is no entry in /etc/fstab -test -z "$( grep -v ^# > > /etc/fstab | grep ^$ )" && exit 0 > > +test -z "$( grep -v ^# /etc/fstab | grep -v ^$ )" && exit 0 > > > > # > > # Activate all the swap partitions declared in the /etc/fstab file @@ > > -110,6 +110,4 @@ else > > fi > > fi > > > > -;; > > - > > # End /etc/init.d/checkfs > > The rest of the packages used by me, works fine. > > Best Regards > > -- > Andrzej Odyniec > > ---------------------------------------------------------------------------- -- > Better than sec? Nothing is better than sec when it comes to monitoring Big > Data applications. Try Boundary one-second resolution app monitoring today. > Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop |
|
From: Andrzej O. <an...@ma...> - 2012-04-04 17:35:04
|
Heiko Zuerker wrote: > Hi everyone, > > I just wanted to check if anybody found any problems with RC3. > It has been pretty quiet, which is a very good sign. > > If no new issues surface, I'm planning to release the official 1.6 soon. Heiko, I found only a cosmetic error. checkfs startup script is not executing and thus does not check the disks listed in fstab with six non-zero field as should be. Ofcourse anybody, who mounts nonramdisks, can change this script and store in own configuration. There is patch: > --- ../../lfssystem/build/config/etc/init.d/checkfs.orig 2011-12-18 18:46:34.000000000 +0100 > +++ ../../lfssystem/build/config/etc/init.d/checkfs 2012-04-01 18:04:34.280769382 +0200 > @@ -19,7 +19,7 @@ > source /etc/init.d/functions > > # exit if there is no entry in /etc/fstab > -test -z "$( grep -v ^# /etc/fstab | grep ^$ )" && exit 0 > +test -z "$( grep -v ^# /etc/fstab | grep -v ^$ )" && exit 0 > > # > # Activate all the swap partitions declared in the /etc/fstab file > @@ -110,6 +110,4 @@ else > fi > fi > > -;; > - > # End /etc/init.d/checkfs The rest of the packages used by me, works fine. Best Regards -- Andrzej Odyniec |
|
From: Dominic R. <dl...@ed...> - 2012-04-04 13:45:48
|
all good here, no problems. Dominic On 04/04/2012 13:46, Bruce Smith wrote: > I think Serge fixed the only problem I found. > > - BS > > > On Wed, Apr 4, 2012 at 07:56, Heiko Zuerker <he...@zu... > <mailto:he...@zu...>> wrote: > > Hi everyone, > > I just wanted to check if anybody found any problems with RC3. > It has been pretty quiet, which is a very good sign. > > If no new issues surface, I'm planning to release the official 1.6 > soon. > > -- > > Regards > Heiko Zuerker > http://www.devil-linux.org > > > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > <mailto:Dev...@li...> > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > > > > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > > > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop |
|
From: Bruce S. <bw...@re...> - 2012-04-04 13:14:19
|
I think Serge fixed the only problem I found. - BS On Wed, Apr 4, 2012 at 07:56, Heiko Zuerker <he...@zu...> wrote: > Hi everyone, > > I just wanted to check if anybody found any problems with RC3. > It has been pretty quiet, which is a very good sign. > > If no new issues surface, I'm planning to release the official 1.6 soon. > > -- > > Regards > Heiko Zuerker > http://www.devil-linux.org > > > > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > |
|
From: Heiko Z. <he...@zu...> - 2012-04-04 11:56:14
|
Hi everyone, I just wanted to check if anybody found any problems with RC3. It has been pretty quiet, which is a very good sign. If no new issues surface, I'm planning to release the official 1.6 soon. -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Serge L. <ser...@gm...> - 2012-03-29 03:51:24
|
I'd say yes. I have not done a thorough testing yet, but it seems to be working. Serge On 03/28/2012 01:29 PM, Heiko Zuerker wrote: > Do we want to include the latest util-linux in the final 1.6 or should > we wait? > > Heiko |
|
From: Heiko Z. <he...@zu...> - 2012-03-28 20:29:16
|
Do we want to include the latest util-linux in the final 1.6 or should we wait? Heiko Quoting Serge Leschinsky <ser...@gm...>: > Heiko, > > yes, that does the trick - with the patch it works fine. > > Thanks, > Serge > > > On 03/27/2012 04:52 AM, Heiko Zuerker wrote: >> Serge, >> >> there's a new loop-aes patch for the new util-linux: >> http://loop-aes.sourceforge.net/updates/util-linux-2.21-20120228.diff.bz2 >> >> Maybe this helps >> >> Heiko >> >> Quoting Serge Leschinsky<ser...@gm...>: >> >>> Dominic, >>> >>> thank you and sorry for the false alarm. >>> The problem was narrowed down to util-linux-2.21. >>> >>> Sincerely, >>> Serge >>> >>> >>> On 03/26/2012 03:05 AM, Dominic Raferd wrote: >>>> On 26/03/2012 04:01, Serge Leschinsky wrote: >>>>> Hi everybody, >>>>> >>>>> I probably found a problem with loop devices, but would like to >>>>> make sure it's >>>>> not the only my problem. >>>>> >>>>> root@temp:~ # cat /proc/partitions >>>>> major minor #blocks name >>>>> >>>>> 8 0 31285248 sda >>>>> 8 1 999956 sda1 >>>>> 8 2 125004 sda2 >>>>> 8 3 30160243 sda3 >>>>> 7 0 97036 loop0 >>>>> 252 0 7340032 dm-0 >>>>> root@temp:~ # losetup -f >>>>> /dev/loop0 >>>>> root@temp:~ # losetup -a >>>>> root@temp:~ # >>>>> >>>>> I.e. I booted from usb (/dev/loop0 is a system image) and it's listed in >>>>> /proc/partitions, but losetup tool doesn't recognize this loop. It >>>>> cause a hang >>>>> during the next "mount -o loop". >>>>> >>>>> Thanks >>>>> Serge >>>> >>>> It seems to work okay for me (Devil-Linux 1.6.0-RC3 32bit, server >>>> version, running from 2-partition USB, booting with Syslinux): >>>> >>>> root@Samba:~ # cat /proc/partitions >>>> major minor #blocks name >>>> >>>> 3 64 156290904 hdb >>>> ... >>>> 7 0 509118 loop0 >>>> 9 0 156290816 md0 >>>> 253 0 262144 dm-0 >>>> 253 1 573440 dm-1 >>>> 253 2 524288 dm-2 >>>> 253 3 131072 dm-3 >>>> 253 4 152043520 dm-4 >>>> root@dl1:~ # losetup -f >>>> /dev/loop1 >>>> root@dl1:~ # losetup -a >>>> /dev/loop0: [0801]:33 (/cd/bootcd.iso) read-only >>>> >>>> Regards >>>> >>>> Dominic > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Serge L. <ser...@gm...> - 2012-03-28 20:04:58
|
Heiko, yes, that does the trick - with the patch it works fine. Thanks, Serge On 03/27/2012 04:52 AM, Heiko Zuerker wrote: > Serge, > > there's a new loop-aes patch for the new util-linux: > http://loop-aes.sourceforge.net/updates/util-linux-2.21-20120228.diff.bz2 > > Maybe this helps > > Heiko > > Quoting Serge Leschinsky<ser...@gm...>: > >> Dominic, >> >> thank you and sorry for the false alarm. >> The problem was narrowed down to util-linux-2.21. >> >> Sincerely, >> Serge >> >> >> On 03/26/2012 03:05 AM, Dominic Raferd wrote: >>> On 26/03/2012 04:01, Serge Leschinsky wrote: >>>> Hi everybody, >>>> >>>> I probably found a problem with loop devices, but would like to >>>> make sure it's >>>> not the only my problem. >>>> >>>> root@temp:~ # cat /proc/partitions >>>> major minor #blocks name >>>> >>>> 8 0 31285248 sda >>>> 8 1 999956 sda1 >>>> 8 2 125004 sda2 >>>> 8 3 30160243 sda3 >>>> 7 0 97036 loop0 >>>> 252 0 7340032 dm-0 >>>> root@temp:~ # losetup -f >>>> /dev/loop0 >>>> root@temp:~ # losetup -a >>>> root@temp:~ # >>>> >>>> I.e. I booted from usb (/dev/loop0 is a system image) and it's listed in >>>> /proc/partitions, but losetup tool doesn't recognize this loop. It >>>> cause a hang >>>> during the next "mount -o loop". >>>> >>>> Thanks >>>> Serge >>> >>> It seems to work okay for me (Devil-Linux 1.6.0-RC3 32bit, server >>> version, running from 2-partition USB, booting with Syslinux): >>> >>> root@Samba:~ # cat /proc/partitions >>> major minor #blocks name >>> >>> 3 64 156290904 hdb >>> ... >>> 7 0 509118 loop0 >>> 9 0 156290816 md0 >>> 253 0 262144 dm-0 >>> 253 1 573440 dm-1 >>> 253 2 524288 dm-2 >>> 253 3 131072 dm-3 >>> 253 4 152043520 dm-4 >>> root@dl1:~ # losetup -f >>> /dev/loop1 >>> root@dl1:~ # losetup -a >>> /dev/loop0: [0801]:33 (/cd/bootcd.iso) read-only >>> >>> Regards >>> >>> Dominic |
|
From: Heiko Z. <he...@zu...> - 2012-03-27 11:52:58
|
Serge, there's a new loop-aes patch for the new util-linux: http://loop-aes.sourceforge.net/updates/util-linux-2.21-20120228.diff.bz2 Maybe this helps Heiko Quoting Serge Leschinsky <ser...@gm...>: > Dominic, > > thank you and sorry for the false alarm. > The problem was narrowed down to util-linux-2.21. > > Sincerely, > Serge > > > On 03/26/2012 03:05 AM, Dominic Raferd wrote: >> On 26/03/2012 04:01, Serge Leschinsky wrote: >>> Hi everybody, >>> >>> I probably found a problem with loop devices, but would like to >>> make sure it's >>> not the only my problem. >>> >>> root@temp:~ # cat /proc/partitions >>> major minor #blocks name >>> >>> 8 0 31285248 sda >>> 8 1 999956 sda1 >>> 8 2 125004 sda2 >>> 8 3 30160243 sda3 >>> 7 0 97036 loop0 >>> 252 0 7340032 dm-0 >>> root@temp:~ # losetup -f >>> /dev/loop0 >>> root@temp:~ # losetup -a >>> root@temp:~ # >>> >>> I.e. I booted from usb (/dev/loop0 is a system image) and it's listed in >>> /proc/partitions, but losetup tool doesn't recognize this loop. It >>> cause a hang >>> during the next "mount -o loop". >>> >>> Thanks >>> Serge >> >> It seems to work okay for me (Devil-Linux 1.6.0-RC3 32bit, server >> version, running from 2-partition USB, booting with Syslinux): >> >> root@Samba:~ # cat /proc/partitions >> major minor #blocks name >> >> 3 64 156290904 hdb >> ... >> 7 0 509118 loop0 >> 9 0 156290816 md0 >> 253 0 262144 dm-0 >> 253 1 573440 dm-1 >> 253 2 524288 dm-2 >> 253 3 131072 dm-3 >> 253 4 152043520 dm-4 >> root@dl1:~ # losetup -f >> /dev/loop1 >> root@dl1:~ # losetup -a >> /dev/loop0: [0801]:33 (/cd/bootcd.iso) read-only >> >> Regards >> >> Dominic >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> _______________________________________________ >> Devil-linux-develop mailing list >> Dev...@li... >> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop >> > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Serge L. <ser...@gm...> - 2012-03-27 03:21:59
|
Dominic, thank you and sorry for the false alarm. The problem was narrowed down to util-linux-2.21. Sincerely, Serge On 03/26/2012 03:05 AM, Dominic Raferd wrote: > On 26/03/2012 04:01, Serge Leschinsky wrote: >> Hi everybody, >> >> I probably found a problem with loop devices, but would like to make sure it's >> not the only my problem. >> >> root@temp:~ # cat /proc/partitions >> major minor #blocks name >> >> 8 0 31285248 sda >> 8 1 999956 sda1 >> 8 2 125004 sda2 >> 8 3 30160243 sda3 >> 7 0 97036 loop0 >> 252 0 7340032 dm-0 >> root@temp:~ # losetup -f >> /dev/loop0 >> root@temp:~ # losetup -a >> root@temp:~ # >> >> I.e. I booted from usb (/dev/loop0 is a system image) and it's listed in >> /proc/partitions, but losetup tool doesn't recognize this loop. It cause a hang >> during the next "mount -o loop". >> >> Thanks >> Serge > > It seems to work okay for me (Devil-Linux 1.6.0-RC3 32bit, server > version, running from 2-partition USB, booting with Syslinux): > > root@Samba:~ # cat /proc/partitions > major minor #blocks name > > 3 64 156290904 hdb > ... > 7 0 509118 loop0 > 9 0 156290816 md0 > 253 0 262144 dm-0 > 253 1 573440 dm-1 > 253 2 524288 dm-2 > 253 3 131072 dm-3 > 253 4 152043520 dm-4 > root@dl1:~ # losetup -f > /dev/loop1 > root@dl1:~ # losetup -a > /dev/loop0: [0801]:33 (/cd/bootcd.iso) read-only > > Regards > > Dominic > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > |
|
From: Dominic R. <dl...@ed...> - 2012-03-26 10:06:00
|
On 26/03/2012 04:01, Serge Leschinsky wrote:
> Hi everybody,
>
> I probably found a problem with loop devices, but would like to make sure it's
> not the only my problem.
>
> root@temp:~ # cat /proc/partitions
> major minor #blocks name
>
> 8 0 31285248 sda
> 8 1 999956 sda1
> 8 2 125004 sda2
> 8 3 30160243 sda3
> 7 0 97036 loop0
> 252 0 7340032 dm-0
> root@temp:~ # losetup -f
> /dev/loop0
> root@temp:~ # losetup -a
> root@temp:~ #
>
> I.e. I booted from usb (/dev/loop0 is a system image) and it's listed in
> /proc/partitions, but losetup tool doesn't recognize this loop. It cause a hang
> during the next "mount -o loop".
>
> Thanks
> Serge
It seems to work okay for me (Devil-Linux 1.6.0-RC3 32bit, server
version, running from 2-partition USB, booting with Syslinux):
root@Samba:~ # cat /proc/partitions
major minor #blocks name
3 64 156290904 hdb
...
7 0 509118 loop0
9 0 156290816 md0
253 0 262144 dm-0
253 1 573440 dm-1
253 2 524288 dm-2
253 3 131072 dm-3
253 4 152043520 dm-4
root@dl1:~ # losetup -f
/dev/loop1
root@dl1:~ # losetup -a
/dev/loop0: [0801]:33 (/cd/bootcd.iso) read-only
Regards
Dominic
|
|
From: Serge L. <ser...@gm...> - 2012-03-26 03:02:04
|
Hi everybody,
I probably found a problem with loop devices, but would like to make sure it's
not the only my problem.
root@temp:~ # cat /proc/partitions
major minor #blocks name
8 0 31285248 sda
8 1 999956 sda1
8 2 125004 sda2
8 3 30160243 sda3
7 0 97036 loop0
252 0 7340032 dm-0
root@temp:~ # losetup -f
/dev/loop0
root@temp:~ # losetup -a
root@temp:~ #
I.e. I booted from usb (/dev/loop0 is a system image) and it's listed in
/proc/partitions, but losetup tool doesn't recognize this loop. It cause a hang
during the next "mount -o loop".
Thanks
Serge
|
|
From: Bruce S. <bw...@re...> - 2012-03-25 02:02:18
|
>> I don't understand it either. > Hmm. I'll ask udev developers. Let us know what they say. I'm curious too. >>> Yes, it's exactly "75-persistent-net-generator.rules" file. Done as a patch >>> because we cannot remove the rules file. >> >> Why can't the file just be removed in the install script? > Technically it's not a problem to remove a file, but it is a rule > (configuration) file for write_net_rules which generates > /etc/udev/rules.d/70-persistent-net.rules. It's a pretty big config, we removed > only a small part from it. If we delete the file, write_net_rules will work > incorrectly. Okay. - BS |
|
From: Serge L. <ser...@gm...> - 2012-03-25 01:52:32
|
On 03/24/2012 03:12 PM, Bruce Smith wrote: >>> I did a little research and it sounds like many virtualized >>> environments reuse MAC address ranges assigned to other manufacturers, >>> so I guess they don't want a conflict. >> I'd say if we have more than 1 NIC in a VM, we have to fixate name<-> mac >> regardless of possible conflict (if there is a conflict, we have to re-generate >> mac addresses - but it's a bit different story). To be honest, I don't >> understand the reason of ignoring NIC name persistence in VM, but those line >> were intentionally added - so, the reason apparently exists. It goads my >> curiosity :) > > I don't understand it either. Hmm. I'll ask udev developers. > > Does KVM keep the same Mac address every time it boots the same VM? > (if not, then it makes sense) It's configurable. Usually mac addresses are "static" for each VM. > >>> Is there a file in /lib/udev/rules.d/ that has a rule to omit KVM >>> devices? (like "75-persistent-net-generator.rules") If so, I'd be >>> okay with editing the file to remove the VM rules, or just removing >>> that file. >> Yes, it's exactly "75-persistent-net-generator.rules" file. Done as a patch >> because we cannot remove the rules file. > > Why can't the file just be removed in the install script? Technically it's not a problem to remove a file, but it is a rule (configuration) file for write_net_rules which generates /etc/udev/rules.d/70-persistent-net.rules. It's a pretty big config, we removed only a small part from it. If we delete the file, write_net_rules will work incorrectly. Serge |
|
From: Bruce S. <bw...@re...> - 2012-03-24 22:13:04
|
>> I did a little research and it sounds like many virtualized >> environments reuse MAC address ranges assigned to other manufacturers, >> so I guess they don't want a conflict. > I'd say if we have more than 1 NIC in a VM, we have to fixate name <-> mac > regardless of possible conflict (if there is a conflict, we have to re-generate > mac addresses - but it's a bit different story). To be honest, I don't > understand the reason of ignoring NIC name persistence in VM, but those line > were intentionally added - so, the reason apparently exists. It goads my > curiosity :) I don't understand it either. Does KVM keep the same Mac address every time it boots the same VM? (if not, then it makes sense) >> Is there a file in /lib/udev/rules.d/ that has a rule to omit KVM >> devices? (like "75-persistent-net-generator.rules") If so, I'd be >> okay with editing the file to remove the VM rules, or just removing >> that file. > Yes, it's exactly "75-persistent-net-generator.rules" file. Done as a patch > because we cannot remove the rules file. Why can't the file just be removed in the install script? - BS |
|
From: Serge L. <ser...@gm...> - 2012-03-24 21:53:16
|
On 03/24/2012 05:05 AM, Bruce Smith wrote: >> OK, the brief update. "--enable-rule_generator" works (adds persistent-net and >> persistent-cd). > > OK, good. Are you going to commit that change? Yes. > > And do we need to add anything in the boot scripts to run the script > that creates persistent-net? No. > I did a little research and it sounds like many virtualized > environments reuse MAC address ranges assigned to other manufacturers, > so I guess they don't want a conflict. I'd say if we have more than 1 NIC in a VM, we have to fixate name <-> mac regardless of possible conflict (if there is a conflict, we have to re-generate mac addresses - but it's a bit different story). To be honest, I don't understand the reason of ignoring NIC name persistence in VM, but those line were intentionally added - so, the reason apparently exists. It goads my curiosity :) > Is there a file in /lib/udev/rules.d/ that has a rule to omit KVM > devices? (like "75-persistent-net-generator.rules") If so, I'd be > okay with editing the file to remove the VM rules, or just removing > that file. Yes, it's exactly "75-persistent-net-generator.rules" file. Done as a patch because we cannot remove the rules file. Serge |
|
From: Bruce S. <bw...@re...> - 2012-03-24 12:05:51
|
> OK, the brief update. "--enable-rule_generator" works (adds persistent-net and
> persistent-cd).
OK, good. Are you going to commit that change?
And do we need to add anything in the boot scripts to run the script
that creates persistent-net?
> During the testing (in KVM) I found the following lines in
> persistent_net_generator which floored me:
>
> # ignore KVM virtual interfaces
> ENV{MATCHADDR}=="52:54:00:*", GOTO="persistent_net_generator_end"
> # ignore VMWare virtual interfaces
> ENV{MATCHADDR}=="00:0c:29:*|00:50:56:*", GOTO="persistent_net_generator_end"
> # ignore Hyper-V virtual interfaces
> ENV{MATCHADDR}=="00:15:5d:*", GOTO="persistent_net_generator_end"
>
> I have no idea why persistent_net should not work in virtualized environments.
> For me it looks like a bug/mistake.
> I'd be happy if you share your opinion.
I did a little research and it sounds like many virtualized
environments reuse MAC address ranges assigned to other manufacturers,
so I guess they don't want a conflict.
Is there a file in /lib/udev/rules.d/ that has a rule to omit KVM
devices? (like "75-persistent-net-generator.rules") If so, I'd be
okay with editing the file to remove the VM rules, or just removing
that file.
- BS
|
|
From: Serge L. <ser...@gm...> - 2012-03-24 10:15:59
|
Hi,
OK, the brief update. "--enable-rule_generator" works (adds persistent-net and
persistent-cd).
During the testing (in KVM) I found the following lines in
persistent_net_generator which floored me:
# ignore KVM virtual interfaces
ENV{MATCHADDR}=="52:54:00:*", GOTO="persistent_net_generator_end"
# ignore VMWare virtual interfaces
ENV{MATCHADDR}=="00:0c:29:*|00:50:56:*", GOTO="persistent_net_generator_end"
# ignore Hyper-V virtual interfaces
ENV{MATCHADDR}=="00:15:5d:*", GOTO="persistent_net_generator_end"
I have no idea why persistent_net should not work in virtualized environments.
For me it looks like a bug/mistake.
I'd be happy if you share your opinion.
Serge
On 03/23/2012 07:14 PM, Serge Leschinsky wrote:
> Hi Bruce,
>
> you are right... We missed "--enable-rule_generator" in udev script.
> Will test the script during weekend.
>
> BTW: There is a problem with 2 instances of devfs (/dev/, /shm/dev).
> A quick research shows that we should change init scripts a bit, i.e.
>
> --- pre_init 2012-03-23 19:06:49.000000000 -0700
> +++ pre_init 2012-03-23 19:07:55.000000000 -0700
> @@ -58,7 +58,8 @@
> # this won't completely umount, because the loop device is still using it
> # that's why we use the lazy option
> umount /initrd -l &> /dev/null
> -umount /shm/dev &> /dev/null
> +# it will fail because /shm/dev/console is locked
> +#umount /shm/dev &> /dev/null
>
> echo "Freeing InitRD memory"
> freeramdisk /dev/ram0
>
> and
>
> --- etc/init.d/boot 2012-03-23 19:12:17.000000000 -0700
> +++ /etc/init.d/boot 2012-03-23 19:11:28.000000000 -0700
> @@ -49,6 +49,10 @@
> /sbin/udevadm settle
> evaluate_retval
>
> +# unmount "old" devtmpfs and remove the dir
> +umount /shm/dev &> /dev/null
> +rm -rf /shm/dev &> /dev/null
> +
> # ls /dev/
>
> if [ -f /proc/sys/kernel/sysrq ]; then
>
>
>
> Sincerely,
> Serge
>
>
> On 03/23/2012 06:28 PM, Bruce Smith wrote:
>> I'm installing DL 1.6.0-RC3 on a new firewall and it assigns eth0&
>> eth1 to different network cards depending if I cold boot (power on)
>> vs. a warm reboot.
>>
>> The script that writes /etc/udev/rules.d/70-persistent-net.rules
>> doesn't seem to exist any longer, and that file is never getting
>> created automatically. I had to create it manually to fix the random
>> NIC name assignment problem.
>>
>> Is this a bug, or are we handling the naming of NIC's differently now?
>>
>> BTW, I tried assigning the module names in setup, instead of using
>> autoselect. That made no difference, and did not assign the names as
>> I specified.
>>
>> - BS
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>
>
|
|
From: Serge L. <ser...@gm...> - 2012-03-24 02:14:29
|
Hi Bruce, you are right... We missed "--enable-rule_generator" in udev script. Will test the script during weekend. BTW: There is a problem with 2 instances of devfs (/dev/, /shm/dev). A quick research shows that we should change init scripts a bit, i.e. --- pre_init 2012-03-23 19:06:49.000000000 -0700 +++ pre_init 2012-03-23 19:07:55.000000000 -0700 @@ -58,7 +58,8 @@ # this won't completely umount, because the loop device is still using it # that's why we use the lazy option umount /initrd -l &> /dev/null -umount /shm/dev &> /dev/null +# it will fail because /shm/dev/console is locked +#umount /shm/dev &> /dev/null echo "Freeing InitRD memory" freeramdisk /dev/ram0 and --- etc/init.d/boot 2012-03-23 19:12:17.000000000 -0700 +++ /etc/init.d/boot 2012-03-23 19:11:28.000000000 -0700 @@ -49,6 +49,10 @@ /sbin/udevadm settle evaluate_retval +# unmount "old" devtmpfs and remove the dir +umount /shm/dev &> /dev/null +rm -rf /shm/dev &> /dev/null + # ls /dev/ if [ -f /proc/sys/kernel/sysrq ]; then Sincerely, Serge On 03/23/2012 06:28 PM, Bruce Smith wrote: > I'm installing DL 1.6.0-RC3 on a new firewall and it assigns eth0& > eth1 to different network cards depending if I cold boot (power on) > vs. a warm reboot. > > The script that writes /etc/udev/rules.d/70-persistent-net.rules > doesn't seem to exist any longer, and that file is never getting > created automatically. I had to create it manually to fix the random > NIC name assignment problem. > > Is this a bug, or are we handling the naming of NIC's differently now? > > BTW, I tried assigning the module names in setup, instead of using > autoselect. That made no difference, and did not assign the names as > I specified. > > - BS > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > |
|
From: Bruce S. <bw...@re...> - 2012-03-24 01:28:47
|
I'm installing DL 1.6.0-RC3 on a new firewall and it assigns eth0 & eth1 to different network cards depending if I cold boot (power on) vs. a warm reboot. The script that writes /etc/udev/rules.d/70-persistent-net.rules doesn't seem to exist any longer, and that file is never getting created automatically. I had to create it manually to fix the random NIC name assignment problem. Is this a bug, or are we handling the naming of NIC's differently now? BTW, I tried assigning the module names in setup, instead of using autoselect. That made no difference, and did not assign the names as I specified. - BS |
35 messages has been excluded from this view by a project administrator.
