Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
On Fri, Apr 15, 2022 at 09:07:10AM +0200, Elmar Stellnberger wrote: > That is not correct. You can make use of SSE instructions also in > x86_32/i386 mode. > > I found f.i.: > https://gcc.gcc.gnu.narkive.com/k0KqaZF2/i386-sse-test-question Well x86_64 uses it all the time, not just optionally, and twice the registers still matters. -- Len Sorensen
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
On Fri, Apr 15, 2022 at 10:18:17AM -0400, Hendrik Boom wrote: ... ... > > And i you're runnin Lisp programs, you'll definitely want a 32-bit > architecture, because Lisp fills memory with addresses. But you can do that > with add-architecture i286. Typo: Of course I meant i386. > > -- hendrik >
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
On Fri, Apr 15, 2022 at 10:12:23AM +0200, Elmar Stellnberger wrote: > On 14.04.22 15:45, Levis Yarema wrote: > > Is there in deed any reason to prefer amd64 over i586 if you have the > > choice and a machine with 2GB RAM or less, apart from perhaps long term > > support? > > > > Depends on the application. Encryption and decryption > requiring the simulation of very larger integers shall be faster > when being based on 64bit integers. However these are rather > special purposes. > CPU and memory intense applications like the SAT-solver I am > developing on the other hand will be faster on i386 since a > memory reference/ pointer only requires 4 byte instead of 8 > byte. Smaller size will yield less memory access cycles and more > cache hits and that can make an application considerably faster. > It is the cache that is effectively more important than the > register layout. Some SAT-solvers like f.i. the DNNF-c2d are > only available for Linux/i386, not for amd64. > Concerning general purpose applications normal integers keep > to be 32bit even on amd64. Note the sizeof(int). This is also > for the rationale described above. x86_32 programs can even be > smaller on disk and in memory. I personally don´t think that > there is much reason to use amd64 with 2GB ram or less, except > for bigint calculations. > Note however that with a 64bit kernel you can execute programs > in a 64bit and 32bit chroot while this is impossible with a > 32bit kernel. This is a reason why many people boot with a 64bit > kernel but use a 32bit installation. As for certain CPU and > memory intense programs you can run them as i386 binary even on > an x86_64 root given that i386 system libararies are installed > which is possible with dpkg --add-architecture i386. > And i you're runnin Lisp programs, you'll definitely want a 32-bit architecture, because Lisp fills memory with addresses. But you can do that with add-architecture i286. -- hendrik
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
On 14.04.22 15:45, Levis Yarema wrote: Is there in deed any reason to prefer amd64 over i586 if you have the choice and a machine with 2GB RAM or less, apart from perhaps long term support? Depends on the application. Encryption and decryption requiring the simulation of very larger integers shall be faster when being based on 64bit integers. However these are rather special purposes. CPU and memory intense applications like the SAT-solver I am developing on the other hand will be faster on i386 since a memory reference/ pointer only requires 4 byte instead of 8 byte. Smaller size will yield less memory access cycles and more cache hits and that can make an application considerably faster. It is the cache that is effectively more important than the register layout. Some SAT-solvers like f.i. the DNNF-c2d are only available for Linux/i386, not for amd64. Concerning general purpose applications normal integers keep to be 32bit even on amd64. Note the sizeof(int). This is also for the rationale described above. x86_32 programs can even be smaller on disk and in memory. I personally don´t think that there is much reason to use amd64 with 2GB ram or less, except for bigint calculations. Note however that with a 64bit kernel you can execute programs in a 64bit and 32bit chroot while this is impossible with a 32bit kernel. This is a reason why many people boot with a 64bit kernel but use a 32bit installation. As for certain CPU and memory intense programs you can run them as i386 binary even on an x86_64 root given that i386 system libararies are installed which is possible with dpkg --add-architecture i386.
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
On 15.04.22 04:50, Lennart Sorensen wrote: On Thu, Apr 14, 2022 at 03:45:37PM +0200, Levis Yarema wrote: Is there in deed any reason to prefer amd64 over i586 if you have the choice and a machine with 2GB RAM or less, apart from perhaps long term support? Twice the registers and sse instructions for fpu rather than x87? That is not correct. You can make use of SSE instructions also in x86_32/i386 mode. I found f.i.: https://gcc.gcc.gnu.narkive.com/k0KqaZF2/i386-sse-test-question
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
On Thu, Apr 14, 2022 at 03:45:37PM +0200, Levis Yarema wrote: > Is there in deed any reason to prefer amd64 over i586 if you have the > choice and a machine with 2GB RAM or less, apart from perhaps long term > support? Twice the registers and sse instructions for fpu rather than x87? -- Len Sorensen
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
Is there in deed any reason to prefer amd64 over i586 if you have the choice and a machine with 2GB RAM or less, apart from perhaps long term support? Am Do., 14. Apr. 2022 um 10:38 Uhr schrieb Paul Wise : > On Tue, 2022-04-12 at 05:59 +0200, Friedhelm Waitzmann wrote: > > > And if it is indeed possible, how can I switch from i386 to > > amd64? Can this be done with the apt tools? Then during the > > migrating some packages will be from amd64 already while others > > will be still i386. How does that go right? > > If your hardware supports it, you can either reinstall from scratch or > cross-grade an existing install from i386 to amd64, either using the > crossgrader tool or more manual methods of doing the same thing. > > https://packages.debian.org/crossgrader > https://wiki.debian.org/CrossGrading > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise >
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
On 14.04.22 10:37, Paul Wise wrote: On Tue, 2022-04-12 at 05:59 +0200, Friedhelm Waitzmann wrote: And if it is indeed possible, how can I switch from i386 to amd64? Can this be done with the apt tools? Then during the migrating some packages will be from amd64 already while others will be still i386. How does that go right? If your hardware supports it, you can either reinstall from scratch or cross-grade an existing install from i386 to amd64, either using the crossgrader tool or more manual methods of doing the same thing. https://packages.debian.org/crossgrader https://wiki.debian.org/CrossGrading If I had to do it, I would just upgrade to Debian 11. It is most easy to do and you do not need things like a crossgrader tool. Though the procedure seems somewhat difficult to me, it is interesting to know that something like crossgrading exists and where you find documentation about it.
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
On Tue, 2022-04-12 at 05:59 +0200, Friedhelm Waitzmann wrote: > And if it is indeed possible, how can I switch from i386 to > amd64? Can this be done with the apt tools? Then during the > migrating some packages will be from amd64 already while others > will be still i386. How does that go right? If your hardware supports it, you can either reinstall from scratch or cross-grade an existing install from i386 to amd64, either using the crossgrader tool or more manual methods of doing the same thing. https://packages.debian.org/crossgrader https://wiki.debian.org/CrossGrading -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
On Wed, Apr 13, 2022 at 1:22 PM Marianne Bayoy wrote: > > Unsubscribe https://www.debian.org/MailingLists/unsubscribe
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
Unsubscribe Le mar. 12 avr. 2022, 12 h 27 a.m., Friedhelm Waitzmann < fach220408.fw...@xoxy.net> a écrit : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Dear Moritz! > > Moritz Mühlenhoff: > >Friedhelm Waitzmann wrote: > >>> For the oldstable distribution (buster), these problems have > >>> been fixed in version 91.8.0esr-1~deb10u1. > >> > >> Where can I get this from for buster and architecture i386? > >> < > http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz > > > >> does not have it. > > >The Firefox ESR91 series triggers an internal compiler error > >with the GCC version included in Debian 10, so there's no build > >available currently. > > Thank you for defining this. > > > >There's one for Debian 11 (where GCC builds it correctly), > > > > In the near future I will migrate to Debian 11. > > > >but I'd instead suggest to switch to amd64 instead. > > > > You mean, that it is possible to run amd64 on my old hardware > > > 1# > > vendor_id : GenuineIntel > cpu family : 6 > model : 22 > model name : Intel(R) Celeron(R) CPU 440 @ 2.00GHz > stepping: 1 > microcode : 0x43 > cpu MHz : 1229.629 > cache size : 512 KB > > and > > 2# > > vendor_id : GenuineIntel > cpu family : 15 > model : 2 > model name : Intel(R) Pentium(R) 4 CPU 2.00GHz > stepping: 4 > cpu MHz : 1993.656 > cache size : 512 KB > > ? > > And if it is indeed possible, how can I switch from i386 to > amd64? Can this be done with the apt tools? Then during the > migrating some packages will be from amd64 already while others > will be still i386. How does that go right? > > > > I suggest, that further discussing should take place in > debian-amd64@lists.debian.org. > > > > Kind regards, > Friedhelm > > > My OpenPGP‐Key: > > - -BEGIN PGP PUBLIC KEY BLOCK- > > mQENBFoCvhgBCADnymmMgAzxsUqP9GPSK+QJATL4w/C8KS7ghUdu7TT4mdEfMfgI > BteRnqWJvLzlBFlQRBEXQphxfgtAdTAZDdAlcyXkcA19Sb0Z09/oQgPe4vp99Cnp > kq2GPOxSk6YQrfs4FF6p4lsQUz0TKONSztZGo4VSyT1G+LpsSxm7Q1YUzpO4j5fy > XfPMB/TdhpJbKlE4yVldwVdt4+Gc8oTeohVkZZtVx9bplmaVLaj35HrRTupj75IS > tooF5dTVLQVhQYKqDCd2DKiZiUuKt6K9ZtrpmjnWaWRayKmJdJ14R8/Q7VfSyXOx > fLb4DNDz4FNUPOvHdXYjhsTz1U6v1kaddMXdABEBAAG0E0ZyaWVkaGVsbSBXYWl0 > em1hbm6JAWAEEwEKAEoCGwECHgECF4ALCw0JCgwICwcEAwIIFQoJCAsDAgEFFgMC > AQACGQEFCQuP3SgWIQRGyPH+W3hgUPhyflPQtV81ksAM7QUCYbLp7wAKCRDQtV81 > ksAM7cr5B/wO1khGTl3dAh46DY2jxe3jTfPvicbQgZQVwOhhP2FPKIFC8dYVCEHk > oYQapW47YXufw/Qw71GILfMtZemiUJpHwa/thCPtP3clE53ZqsEdArHDX2ZYm3Ol > qDTxMuilQCDfGuatg6MVQ8SlUbhcGIGyr4O4cPeDe0kmUOQhp8wKTXkmhq3Yml5+ > 2XRu69TZUNsQh3TPi50hR+RB0YjI+KTBKYSanAYM44Bj6mti6+06UkRVMaFxLVzS > BAEyTf/SBaKkJq4cKe+gCzcc/Gg8jrxKVcQRPdUxOlvWUiYT5FYRaFuklgDW4B+g > 23FdO6RkE0Z+g/oLeAYSqj/JMfjv77bFtBlmYWNoMjIwNDA4LmZ3bnNwQHhveHku > bmV0iQFdBBMBCgBHFiEERsjx/lt4YFD4cn5T0LVfNZLADO0FAmJQFg8CGwEFCQuP > 3SgLCw0JCgwICwcEAwIIFQoJCAsDAgEFFgMCAQACHgECF4AACgkQ0LVfNZLADO2V > ygf9HQWjolhnGRNWG5845lh2uTrm/5q19+hKwnQHx7HApZia09kXp7QpxTCmSmnq > skWto08U/iT1sPqFTOojOZAM6e4zr7kz/VJksJx8lswUkTRyGXqGEQoQ7bZvd6XR > Yu0ZKfNNZhvjfPzzwyp+85lWWIaNA0cQyIa6BRzlNhgCbyLhksy4GDkzoBPxhNOp > mboohSVOnLjrUbQpfKCDJtAaNps95+4gv2t8JPtyFcZW9qKWFRIdJJvamc3lp4Il > JwzXRElB1htSHQb4SA2VN9M6ALdnfZXXT+H8UKKek+joE8Xm15FX83E5pmrE/8lp > imVg0s0BAUd0DxVj6zj4SI9yhrkBDQRaAsK/AQgAyBEE1hjgZ6F33GPSkfxsFqsN > L5lQrRTQtx5GKPt5UnIKK00TAevGoI8VDftuP6Fpp9kFJ+HSAiW3M+8S70H3UnbW > 8AFofSd28AUvnnhP4ATwRcVm35+HYUge4lKiy5bEvDS9bALJqlW9sHBUF+gebrmh > 0CgvD0sQSUE4PLAuHFUJG8/fezReXGB2MSVAbu8NXHdlJ6vPr5ERlg7A0JFR9Knx > s8PoI/1hd73mwGld9/Xo3xByDbJ7Uejjt3HpNZf9eOq3XPp02dpKsOQEB2QxxPHI > TcBH8IBZY78BJHq9UD4g3fD904oIvs38BzvX/WAMO9W0k1ZLfF1zyR0+QXQweQAR > AQABiQJEBBgBAgAPAhsCBQJcRWq9BQkU+H0OASnAXSAEGQECAAYFAloCwr8ACgkQ > gEIvCiHZTet1zwf/TUmPpwnBgoA6AXILI5R/NvZit30mbExa6byBOK9vEbGS8pSu > L/GN5tzTmyJoGbLNc24h8w6FwcoxE0xJSUJKp7nO95NWD/kO5n8alJZN9ph8I2yt > Cl3dhzZKw8+j+WBwTrKLdDP5lfarI0gz6+N1UtFH4U+tUCq56DQqu46xyTS5ASeM > iO/8Ykej9LiObZv9QYwnKkhM8y+Dw9dkPfIsqt47uE4j4czpJ4qv8236oV/luR44 > 8cCud5G7ZGxBj6DSnitZM2lbq5yTlIZ3EEvu/I9dE/vsPaWQmGeo6S03FJ8+S6Xn > eP8mgYWl9YGJTjDvUg3FU9fXfHzCuFtZ/1YZvAkQ0LVfNZLADO2zEggAi3myJcVA > yiftlZSkTrId9LNeQtXCw7tkJcuaGIC/FWJQhVofcp2CuEAm26w9xRN39Tp7pi2r > fta/xykj0iYNjmqgi7MWK6pZOY/LCTEOMfYiWX4LCJ89f51y2TTmWwgfWXxFVe8y > lyRMC1N2CXEd5xsEKA1ZI5vF3ikjVkMBAtLGiSxcyBi8YbcDFG4/fTBNpeEvXZ6n > CusDDYCArwFiQi4mRtDbZXBZIBVE+jwYlzw0bz3EeqkPFMJ/pvuWeQ5R9LSuVYhh > aVieqoLXmK6uwQLoJOFx67KX+BoEPpkVa/FmDhfpguQrKz5/Eq1Lhy8P28EAhLSG >
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
unsubscribe On Tue, Apr 12, 2022 at 12:27 AM Friedhelm Waitzmann < fach220408.fw...@xoxy.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Dear Moritz! > > Moritz Mühlenhoff: > >Friedhelm Waitzmann wrote: > >>> For the oldstable distribution (buster), these problems have > >>> been fixed in version 91.8.0esr-1~deb10u1. > >> > >> Where can I get this from for buster and architecture i386? > >> < > http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz > > > >> does not have it. > > >The Firefox ESR91 series triggers an internal compiler error > >with the GCC version included in Debian 10, so there's no build > >available currently. > > Thank you for defining this. > > > >There's one for Debian 11 (where GCC builds it correctly), > > > > In the near future I will migrate to Debian 11. > > > >but I'd instead suggest to switch to amd64 instead. > > > > You mean, that it is possible to run amd64 on my old hardware > > > 1# > > vendor_id : GenuineIntel > cpu family : 6 > model : 22 > model name : Intel(R) Celeron(R) CPU 440 @ 2.00GHz > stepping: 1 > microcode : 0x43 > cpu MHz : 1229.629 > cache size : 512 KB > > and > > 2# > > vendor_id : GenuineIntel > cpu family : 15 > model : 2 > model name : Intel(R) Pentium(R) 4 CPU 2.00GHz > stepping: 4 > cpu MHz : 1993.656 > cache size : 512 KB > > ? > > And if it is indeed possible, how can I switch from i386 to > amd64? Can this be done with the apt tools? Then during the > migrating some packages will be from amd64 already while others > will be still i386. How does that go right? > > > > I suggest, that further discussing should take place in > debian-amd64@lists.debian.org. > > > > Kind regards, > Friedhelm > > > My OpenPGP‐Key: > > - -BEGIN PGP PUBLIC KEY BLOCK- > > mQENBFoCvhgBCADnymmMgAzxsUqP9GPSK+QJATL4w/C8KS7ghUdu7TT4mdEfMfgI > BteRnqWJvLzlBFlQRBEXQphxfgtAdTAZDdAlcyXkcA19Sb0Z09/oQgPe4vp99Cnp > kq2GPOxSk6YQrfs4FF6p4lsQUz0TKONSztZGo4VSyT1G+LpsSxm7Q1YUzpO4j5fy > XfPMB/TdhpJbKlE4yVldwVdt4+Gc8oTeohVkZZtVx9bplmaVLaj35HrRTupj75IS > tooF5dTVLQVhQYKqDCd2DKiZiUuKt6K9ZtrpmjnWaWRayKmJdJ14R8/Q7VfSyXOx > fLb4DNDz4FNUPOvHdXYjhsTz1U6v1kaddMXdABEBAAG0E0ZyaWVkaGVsbSBXYWl0 > em1hbm6JAWAEEwEKAEoCGwECHgECF4ALCw0JCgwICwcEAwIIFQoJCAsDAgEFFgMC > AQACGQEFCQuP3SgWIQRGyPH+W3hgUPhyflPQtV81ksAM7QUCYbLp7wAKCRDQtV81 > ksAM7cr5B/wO1khGTl3dAh46DY2jxe3jTfPvicbQgZQVwOhhP2FPKIFC8dYVCEHk > oYQapW47YXufw/Qw71GILfMtZemiUJpHwa/thCPtP3clE53ZqsEdArHDX2ZYm3Ol > qDTxMuilQCDfGuatg6MVQ8SlUbhcGIGyr4O4cPeDe0kmUOQhp8wKTXkmhq3Yml5+ > 2XRu69TZUNsQh3TPi50hR+RB0YjI+KTBKYSanAYM44Bj6mti6+06UkRVMaFxLVzS > BAEyTf/SBaKkJq4cKe+gCzcc/Gg8jrxKVcQRPdUxOlvWUiYT5FYRaFuklgDW4B+g > 23FdO6RkE0Z+g/oLeAYSqj/JMfjv77bFtBlmYWNoMjIwNDA4LmZ3bnNwQHhveHku > bmV0iQFdBBMBCgBHFiEERsjx/lt4YFD4cn5T0LVfNZLADO0FAmJQFg8CGwEFCQuP > 3SgLCw0JCgwICwcEAwIIFQoJCAsDAgEFFgMCAQACHgECF4AACgkQ0LVfNZLADO2V > ygf9HQWjolhnGRNWG5845lh2uTrm/5q19+hKwnQHx7HApZia09kXp7QpxTCmSmnq > skWto08U/iT1sPqFTOojOZAM6e4zr7kz/VJksJx8lswUkTRyGXqGEQoQ7bZvd6XR > Yu0ZKfNNZhvjfPzzwyp+85lWWIaNA0cQyIa6BRzlNhgCbyLhksy4GDkzoBPxhNOp > mboohSVOnLjrUbQpfKCDJtAaNps95+4gv2t8JPtyFcZW9qKWFRIdJJvamc3lp4Il > JwzXRElB1htSHQb4SA2VN9M6ALdnfZXXT+H8UKKek+joE8Xm15FX83E5pmrE/8lp > imVg0s0BAUd0DxVj6zj4SI9yhrkBDQRaAsK/AQgAyBEE1hjgZ6F33GPSkfxsFqsN > L5lQrRTQtx5GKPt5UnIKK00TAevGoI8VDftuP6Fpp9kFJ+HSAiW3M+8S70H3UnbW > 8AFofSd28AUvnnhP4ATwRcVm35+HYUge4lKiy5bEvDS9bALJqlW9sHBUF+gebrmh > 0CgvD0sQSUE4PLAuHFUJG8/fezReXGB2MSVAbu8NXHdlJ6vPr5ERlg7A0JFR9Knx > s8PoI/1hd73mwGld9/Xo3xByDbJ7Uejjt3HpNZf9eOq3XPp02dpKsOQEB2QxxPHI > TcBH8IBZY78BJHq9UD4g3fD904oIvs38BzvX/WAMO9W0k1ZLfF1zyR0+QXQweQAR > AQABiQJEBBgBAgAPAhsCBQJcRWq9BQkU+H0OASnAXSAEGQECAAYFAloCwr8ACgkQ > gEIvCiHZTet1zwf/TUmPpwnBgoA6AXILI5R/NvZit30mbExa6byBOK9vEbGS8pSu > L/GN5tzTmyJoGbLNc24h8w6FwcoxE0xJSUJKp7nO95NWD/kO5n8alJZN9ph8I2yt > Cl3dhzZKw8+j+WBwTrKLdDP5lfarI0gz6+N1UtFH4U+tUCq56DQqu46xyTS5ASeM > iO/8Ykej9LiObZv9QYwnKkhM8y+Dw9dkPfIsqt47uE4j4czpJ4qv8236oV/luR44 > 8cCud5G7ZGxBj6DSnitZM2lbq5yTlIZ3EEvu/I9dE/vsPaWQmGeo6S03FJ8+S6Xn > eP8mgYWl9YGJTjDvUg3FU9fXfHzCuFtZ/1YZvAkQ0LVfNZLADO2zEggAi3myJcVA > yiftlZSkTrId9LNeQtXCw7tkJcuaGIC/FWJQhVofcp2CuEAm26w9xRN39Tp7pi2r > fta/xykj0iYNjmqgi7MWK6pZOY/LCTEOMfYiWX4LCJ89f51y2TTmWwgfWXxFVe8y > lyRMC1N2CXEd5xsEKA1ZI5vF3ikjVkMBAtLGiSxcyBi8YbcDFG4/fTBNpeEvXZ6n > CusDDYCArwFiQi4mRtDbZXBZIBVE+jwYlzw0bz3EeqkPFMJ/pvuWeQ5R9LSuVYhh > aVieqoLXmK6uwQLoJOFx67KX+BoEPpkVa/FmDhfpguQrKz5/Eq1Lhy8P28EAhLSG > Ar1XuxedRos/p
amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Moritz! Moritz Mühlenhoff: Friedhelm Waitzmann wrote: For the oldstable distribution (buster), these problems have been fixed in version 91.8.0esr-1~deb10u1. Where can I get this from for buster and architecture i386? <http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz> does not have it. The Firefox ESR91 series triggers an internal compiler error with the GCC version included in Debian 10, so there's no build available currently. Thank you for defining this. There's one for Debian 11 (where GCC builds it correctly), In the near future I will migrate to Debian 11. but I'd instead suggest to switch to amd64 instead. You mean, that it is possible to run amd64 on my old hardware 1# vendor_id : GenuineIntel cpu family : 6 model : 22 model name : Intel(R) Celeron(R) CPU 440 @ 2.00GHz stepping: 1 microcode : 0x43 cpu MHz : 1229.629 cache size : 512 KB and 2# vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 2.00GHz stepping: 4 cpu MHz : 1993.656 cache size : 512 KB ? And if it is indeed possible, how can I switch from i386 to amd64? Can this be done with the apt tools? Then during the migrating some packages will be from amd64 already while others will be still i386. How does that go right? I suggest, that further discussing should take place in debian-amd64@lists.debian.org. Kind regards, Friedhelm My OpenPGP‐Key: - -BEGIN PGP PUBLIC KEY BLOCK- mQENBFoCvhgBCADnymmMgAzxsUqP9GPSK+QJATL4w/C8KS7ghUdu7TT4mdEfMfgI BteRnqWJvLzlBFlQRBEXQphxfgtAdTAZDdAlcyXkcA19Sb0Z09/oQgPe4vp99Cnp kq2GPOxSk6YQrfs4FF6p4lsQUz0TKONSztZGo4VSyT1G+LpsSxm7Q1YUzpO4j5fy XfPMB/TdhpJbKlE4yVldwVdt4+Gc8oTeohVkZZtVx9bplmaVLaj35HrRTupj75IS tooF5dTVLQVhQYKqDCd2DKiZiUuKt6K9ZtrpmjnWaWRayKmJdJ14R8/Q7VfSyXOx fLb4DNDz4FNUPOvHdXYjhsTz1U6v1kaddMXdABEBAAG0E0ZyaWVkaGVsbSBXYWl0 em1hbm6JAWAEEwEKAEoCGwECHgECF4ALCw0JCgwICwcEAwIIFQoJCAsDAgEFFgMC AQACGQEFCQuP3SgWIQRGyPH+W3hgUPhyflPQtV81ksAM7QUCYbLp7wAKCRDQtV81 ksAM7cr5B/wO1khGTl3dAh46DY2jxe3jTfPvicbQgZQVwOhhP2FPKIFC8dYVCEHk oYQapW47YXufw/Qw71GILfMtZemiUJpHwa/thCPtP3clE53ZqsEdArHDX2ZYm3Ol qDTxMuilQCDfGuatg6MVQ8SlUbhcGIGyr4O4cPeDe0kmUOQhp8wKTXkmhq3Yml5+ 2XRu69TZUNsQh3TPi50hR+RB0YjI+KTBKYSanAYM44Bj6mti6+06UkRVMaFxLVzS BAEyTf/SBaKkJq4cKe+gCzcc/Gg8jrxKVcQRPdUxOlvWUiYT5FYRaFuklgDW4B+g 23FdO6RkE0Z+g/oLeAYSqj/JMfjv77bFtBlmYWNoMjIwNDA4LmZ3bnNwQHhveHku bmV0iQFdBBMBCgBHFiEERsjx/lt4YFD4cn5T0LVfNZLADO0FAmJQFg8CGwEFCQuP 3SgLCw0JCgwICwcEAwIIFQoJCAsDAgEFFgMCAQACHgECF4AACgkQ0LVfNZLADO2V ygf9HQWjolhnGRNWG5845lh2uTrm/5q19+hKwnQHx7HApZia09kXp7QpxTCmSmnq skWto08U/iT1sPqFTOojOZAM6e4zr7kz/VJksJx8lswUkTRyGXqGEQoQ7bZvd6XR Yu0ZKfNNZhvjfPzzwyp+85lWWIaNA0cQyIa6BRzlNhgCbyLhksy4GDkzoBPxhNOp mboohSVOnLjrUbQpfKCDJtAaNps95+4gv2t8JPtyFcZW9qKWFRIdJJvamc3lp4Il JwzXRElB1htSHQb4SA2VN9M6ALdnfZXXT+H8UKKek+joE8Xm15FX83E5pmrE/8lp imVg0s0BAUd0DxVj6zj4SI9yhrkBDQRaAsK/AQgAyBEE1hjgZ6F33GPSkfxsFqsN L5lQrRTQtx5GKPt5UnIKK00TAevGoI8VDftuP6Fpp9kFJ+HSAiW3M+8S70H3UnbW 8AFofSd28AUvnnhP4ATwRcVm35+HYUge4lKiy5bEvDS9bALJqlW9sHBUF+gebrmh 0CgvD0sQSUE4PLAuHFUJG8/fezReXGB2MSVAbu8NXHdlJ6vPr5ERlg7A0JFR9Knx s8PoI/1hd73mwGld9/Xo3xByDbJ7Uejjt3HpNZf9eOq3XPp02dpKsOQEB2QxxPHI TcBH8IBZY78BJHq9UD4g3fD904oIvs38BzvX/WAMO9W0k1ZLfF1zyR0+QXQweQAR AQABiQJEBBgBAgAPAhsCBQJcRWq9BQkU+H0OASnAXSAEGQECAAYFAloCwr8ACgkQ gEIvCiHZTet1zwf/TUmPpwnBgoA6AXILI5R/NvZit30mbExa6byBOK9vEbGS8pSu L/GN5tzTmyJoGbLNc24h8w6FwcoxE0xJSUJKp7nO95NWD/kO5n8alJZN9ph8I2yt Cl3dhzZKw8+j+WBwTrKLdDP5lfarI0gz6+N1UtFH4U+tUCq56DQqu46xyTS5ASeM iO/8Ykej9LiObZv9QYwnKkhM8y+Dw9dkPfIsqt47uE4j4czpJ4qv8236oV/luR44 8cCud5G7ZGxBj6DSnitZM2lbq5yTlIZ3EEvu/I9dE/vsPaWQmGeo6S03FJ8+S6Xn eP8mgYWl9YGJTjDvUg3FU9fXfHzCuFtZ/1YZvAkQ0LVfNZLADO2zEggAi3myJcVA yiftlZSkTrId9LNeQtXCw7tkJcuaGIC/FWJQhVofcp2CuEAm26w9xRN39Tp7pi2r fta/xykj0iYNjmqgi7MWK6pZOY/LCTEOMfYiWX4LCJ89f51y2TTmWwgfWXxFVe8y lyRMC1N2CXEd5xsEKA1ZI5vF3ikjVkMBAtLGiSxcyBi8YbcDFG4/fTBNpeEvXZ6n CusDDYCArwFiQi4mRtDbZXBZIBVE+jwYlzw0bz3EeqkPFMJ/pvuWeQ5R9LSuVYhh aVieqoLXmK6uwQLoJOFx67KX+BoEPpkVa/FmDhfpguQrKz5/Eq1Lhy8P28EAhLSG Ar1XuxedRos/pLkBDQRaAsFpAQgAm4sZiVbFI6YpR3yDFpe7qOkkWmlk+7MT8cAa j5Ltm+mXqf7ZHDNeX9mzMNBZeoUBCztp0n/N0Iu5T7MmEJV/rrJa0N8ezjY9kDTX xUmLRmXTM/AM7Jg6dsIOf/lrd2TAagUkf/nYS9Sxx7/MvWESis3uYw8aqpuXjS0t FgaG3umvTfvgI2SamuZTkdt9KmoqKCFcf5qjNk7PeY0REVYUp0/mfyPDo7s33yOm P0x9wy6zeZ4OKAsSETvARj8WafUT7vikVuZEtfiLolT741y2VtvyBICooLsVZ6Pf MMle4newVhbZeJAjUTdxoE4T+B1vMICsbNw2/zsYtM/9KKvWpwARAQABiQElBBgB AgAPAhsMBQJcRWqNBQkU+H5mAAoJENC1XzWSwAztix8IAN+/SZI+fr6AkLuC0X+0 FxpsSD3n89XQja+nTrVTODu2c1BDi0bXOMwcOyRqnnZ1F/tKieVQsfpvZoumF7Wi fs9O3Mlt9Tw1b+g7tfnTj3a9GP6AiYzt/Zde2YGhbZ+65AOwka8DegWm+R6JuLds y6oERH1BzGytG/c6pKY17XiMnXTdjwvN+YuSJ89eqA90KzoIOVCx9kWVagxzWh6u WioiuAStwrUmZ+KOFhQbmXtEO+fUHf+G9J5DtlKFLHjz4Qy88z0jdGvE0Yf3r46q d8mzOSlOX9N2LWTR+bFuN9DYeoQmDyibEM5W9dNH4Fn8F8w
Please give back mbuffer on amd64
Hi,
Something seems to have gone wrong two weeks ago when I uploaded
a new upstream version of mbuffer -
https://buildd.debian.org/status/package.php?p=mbuffer&suite=sid
shows it as having been in the "Building" state on amd64 for 14 days.
Could somebody please take a look and retry the build?
gb mbuffer_20190725+ds1-1 . amd64
Thanks in advance, and keep up the great work!
G'luck,
Peter
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
Re: systemd on amd64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 22/8/19 6:21 pm, Steffen Grunewald wrote: > On Thu, 2019-08-22 at 13:49:22 +1000, Andrew McGlashan wrote: >> >> Any help would be appreciated. > > Check "Devuan >> Beowulf", >> currently under development. Or even "Devuan ASCII" -- stable. > > AFAIR Jack had asked for Buster... ASCII is Stretch. Fair enough Kind Regards AndrewM -BEGIN PGP SIGNATURE- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXV5gggAKCRCoFmvLt+/i +1fqAQC2kUTlZ/qJ4jpult33tEHpTlWenjf2I4eU82n2ym5sZQEA2v7k5WH3ZXj0 EECtbZFJNGwndXjZ1PbbG++PunfRAAY= =yul2 -END PGP SIGNATURE-
Re: systemd on amd64
On Thu, 2019-08-22 at 13:49:22 +1000, Andrew McGlashan wrote: > > >> >> Any help would be appreciated. > > Check "Devuan Beowulf", > currently under development. > Or even "Devuan ASCII" -- stable. AFAIR Jack had asked for Buster... ASCII is Stretch. - S
Re: systemd on amd64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 22/8/19 1:46 am, Steffen Grunewald wrote: > On Wed, 2019-08-21 at 12:08:07 -0300, Jack Warkentin wrote: >> Hi everybody > >> >> I would like to install Buster on my amd64 machine *without* systemd. Is >> this possible? If so, how? I have read the entire installation manual and >> could not find anything about how to do this. Also. I could find nothing >> about it in the debian-amd64 archives. >> >> I have been using debian since 2002, but at age 81 I am too old to learn a >> new way of doing basic maintenance on my machine. >> >> Any help would be appreciated. > > Check "Devuan Beowulf", currently under development. Or even "Devuan ASCII" -- stable. Kind Regards AndrewM -BEGIN PGP SIGNATURE- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXV4QtwAKCRCoFmvLt+/i +z6hAQCoIwMlnmIr4ifosBVXt2GYJM6vB1+/dNLvo/SQzfqIcAD+IWE1DYWUpfAB l1Jt2JJ8RsZloVYlKja3bbS25wbCK/Q= =ZZQ+ -END PGP SIGNATURE-
Re: systemd on amd64
On Wed, 2019-08-21 at 12:08:07 -0300, Jack Warkentin wrote: > Hi everybody > > I would like to install Buster on my amd64 machine *without* systemd. Is > this possible? If so, how? I have read the entire installation manual and > could not find anything about how to do this. Also. I could find nothing > about it in the debian-amd64 archives. > > I have been using debian since 2002, but at age 81 I am too old to learn a > new way of doing basic maintenance on my machine. > > Any help would be appreciated. Check "Devuan Beowulf", currently under development. - S
Re: systemd on amd64
On 8/21/19 5:08 PM, Jack Warkentin wrote: Hi everybody I would like to install Buster on my amd64 machine *without* systemd. Is this possible? If so, how? I have read the entire installation manual and could not find anything about how to do this. Also. I could find nothing about it in the debian-amd64 archives. I have been using debian since 2002, but at age 81 I am too old to learn a new way of doing basic maintenance on my machine. You might want https://devuan.org/ -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France; (mobile phone: cf my web page / voir ma page web...)
systemd on amd64
Hi everybody I would like to install Buster on my amd64 machine *without* systemd. Is this possible? If so, how? I have read the entire installation manual and could not find anything about how to do this. Also. I could find nothing about it in the debian-amd64 archives. I have been using debian since 2002, but at age 81 I am too old to learn a new way of doing basic maintenance on my machine. Any help would be appreciated. Jack Warkentin, phone 902-404-0457, email jw...@bellaliant.net 39 Inverness Avenue, Halifax, Nova Scotia, Canada, B3P 1X6
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
Could you PLEASE stop posting to debian-ports@? You are sending these mails to
every Debian Ports architecture mailing list.
I already asked for the third time now.
Thank You,
Adrian
> On May 26, 2019, at 5:34 AM, wrote:
>
> Sorry if this is off-topic, but I can't help asking if that "15381 March
> 1977" was on purpose or just from some wonky email client: 15380 days after
> March 1st 1977 happens to be April 10th 2019, so...
>
> --
> Pengcheng Xu
> https://jsteward.moe/
>
>
>> -Original Message-
>> From: Aurelien Jarno
>> Sent: Saturday, May 25, 2019 4:56 PM
>> To: debian-h...@lists.debian.org; debian-...@lists.debian.org; debian-
>> de...@lists.debian.org; debian-po...@lists.debian.org; ftpmaster@ports-
>> master.debian.org
>> Subject: Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
>>
>> Hi,
>>
>>> On 2019-04-24 12:34, Joerg Jaspert wrote:
>>> On 15381 March 1977, Aurelien Jarno wrote:
> ^^^ HERE
>>>
>>>>>> It would be nice to have a bit more than 2 weeks to do all of that.
>>>>> Ok. How much? Is 6 or 8 weeks better? I don't think, given how
>>>>> long this is on the table already, it doesn't make much difference if its
>>>>> 2
>> or 8.
>>>>> Just something thats clear defined and not some random, non-clear
>>>>> "sometime in the future" point.
>>>> The hurd-i386 architecture has been moved to to debian-ports yesterday.
>>>> I hope it shows the willingness to do that. Please give us at least
>>>> 4 more weeks to do the remaining kfreebsd-*. That will provide some
>>>> margin to account for the non-infinite free time to work on that
>>>> (especially in the freeze period) and possibly to get more disk
>>>> space for the debian-ports machine.
>>>
>>> Thats ok, end of May is a nice point to take.
>>>
>>> Thanks for the work and the timeframe for the rest!
>>
>> kfreebsd-amd64 and kfreebsd-i386 have now been moved to debian-ports.
>> As
>> hurd-i386 has been moved earlier, it means that all the 3 architectures have
>> now been moved.
>>
>> Aurelien
>>
>> --
>> Aurelien Jarno GPG: 4096R/1DDD8C9B
>> aurel...@aurel32.net http://www.aurel32.net
RE: Hurd-i386 and kfreebsd-{i386,amd64} removal
Sorry if this is off-topic, but I can't help asking if that "15381 March 1977"
was on purpose or just from some wonky email client: 15380 days after March 1st
1977 happens to be April 10th 2019, so...
--
Pengcheng Xu
https://jsteward.moe/
> -Original Message-
> From: Aurelien Jarno
> Sent: Saturday, May 25, 2019 4:56 PM
> To: debian-h...@lists.debian.org; debian-...@lists.debian.org; debian-
> de...@lists.debian.org; debian-po...@lists.debian.org; ftpmaster@ports-
> master.debian.org
> Subject: Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
>
> Hi,
>
> On 2019-04-24 12:34, Joerg Jaspert wrote:
> > On 15381 March 1977, Aurelien Jarno wrote:
^^^ HERE
> >
> > > > > It would be nice to have a bit more than 2 weeks to do all of that.
> > > > Ok. How much? Is 6 or 8 weeks better? I don't think, given how
> > > > long this is on the table already, it doesn't make much difference if
> > > > its 2
> or 8.
> > > > Just something thats clear defined and not some random, non-clear
> > > > "sometime in the future" point.
> > > The hurd-i386 architecture has been moved to to debian-ports yesterday.
> > > I hope it shows the willingness to do that. Please give us at least
> > > 4 more weeks to do the remaining kfreebsd-*. That will provide some
> > > margin to account for the non-infinite free time to work on that
> > > (especially in the freeze period) and possibly to get more disk
> > > space for the debian-ports machine.
> >
> > Thats ok, end of May is a nice point to take.
> >
> > Thanks for the work and the timeframe for the rest!
>
> kfreebsd-amd64 and kfreebsd-i386 have now been moved to debian-ports.
> As
> hurd-i386 has been moved earlier, it means that all the 3 architectures have
> now been moved.
>
> Aurelien
>
> --
> Aurelien Jarno GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net
openpgp-digital-signature.asc
Description: PGP signature
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
On 15413 March 1977, Aurelien Jarno wrote: Thats ok, end of May is a nice point to take. Thanks for the work and the timeframe for the rest! kfreebsd-amd64 and kfreebsd-i386 have now been moved to debian-ports. As hurd-i386 has been moved earlier, it means that all the 3 architectures have now been moved. Thank you! -- bye, Joerg
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
On 2019-05-25 13:00, Manuel A. Fernandez Montecelo wrote: > Hi, > > Em sáb, 25 de mai de 2019 às 10:57, Aurelien Jarno > escreveu: > > > > kfreebsd-amd64 and kfreebsd-i386 have now been moved to debian-ports. As > > hurd-i386 has been moved earlier, it means that all the 3 architectures > > have now been moved. > > Nice :-) > > Not sure who's the admin (I couldn't find the admin address in the > main pages), but they're not registered in the graphs (while > powerpcpse, recently removed, still is). > > https://buildd.debian.org/stats/graph-ports-week-big.png There are still available on the on the main graph: https://buildd.debian.org/stats/graph-week-big.png I'll move hurd and kbsd-* plots from the main one to the ports one, but unless we do not keep the history, it's not a trivial task as it requires migrating the data from one text database to the other database. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
Hi, Em sáb, 25 de mai de 2019 às 10:57, Aurelien Jarno escreveu: > > kfreebsd-amd64 and kfreebsd-i386 have now been moved to debian-ports. As > hurd-i386 has been moved earlier, it means that all the 3 architectures > have now been moved. Nice :-) Not sure who's the admin (I couldn't find the admin address in the main pages), but they're not registered in the graphs (while powerpcpse, recently removed, still is). https://buildd.debian.org/stats/graph-ports-week-big.png -- Manuel A. Fernandez Montecelo
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
Hi, On 2019-04-24 12:34, Joerg Jaspert wrote: > On 15381 March 1977, Aurelien Jarno wrote: > > > > > It would be nice to have a bit more than 2 weeks to do all of that. > > > Ok. How much? Is 6 or 8 weeks better? I don't think, given how long this > > > is on the table already, it doesn't make much difference if its 2 or 8. > > > Just something thats clear defined and not some random, non-clear > > > "sometime in the future" point. > > The hurd-i386 architecture has been moved to to debian-ports yesterday. > > I hope it shows the willingness to do that. Please give us at least 4 > > more weeks to do the remaining kfreebsd-*. That will provide some margin > > to account for the non-infinite free time to work on that (especially in > > the freeze period) and possibly to get more disk space for the > > debian-ports machine. > > Thats ok, end of May is a nice point to take. > > Thanks for the work and the timeframe for the rest! kfreebsd-amd64 and kfreebsd-i386 have now been moved to debian-ports. As hurd-i386 has been moved earlier, it means that all the 3 architectures have now been moved. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
On 15381 March 1977, Aurelien Jarno wrote: > It would be nice to have a bit more than 2 weeks to do all of that. Ok. How much? Is 6 or 8 weeks better? I don't think, given how long this is on the table already, it doesn't make much difference if its 2 or 8. Just something thats clear defined and not some random, non-clear "sometime in the future" point. The hurd-i386 architecture has been moved to to debian-ports yesterday. I hope it shows the willingness to do that. Please give us at least 4 more weeks to do the remaining kfreebsd-*. That will provide some margin to account for the non-infinite free time to work on that (especially in the freeze period) and possibly to get more disk space for the debian-ports machine. Thats ok, end of May is a nice point to take. Thanks for the work and the timeframe for the rest! -- bye, Joerg
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
On 2019-04-13 17:01, Joerg Jaspert wrote: > On 15371 March 1977, Aurelien Jarno wrote: > > > > How is the move to debian-ports supposed to happen? I won't have the > > > time to do anything about it within the 2 weeks. > > > The process to inject all packages to debian-ports is to get all the > > deb, udeb and buildinfo files from the archives (main and debug) and > > associate them with the .changes files that are hosted on coccia. We'll > > also need to fetch all the associated GPG keys used to sign the changes > > files. Then we can inject that in the debian-ports archive. > > > It would be nice to have a bit more than 2 weeks to do all of that. > > Ok. How much? Is 6 or 8 weeks better? I don't think, given how long this > is on the table already, it doesn't make much difference if its 2 or 8. > Just something thats clear defined and not some random, non-clear > "sometime in the future" point. The hurd-i386 architecture has been moved to to debian-ports yesterday. I hope it shows the willingness to do that. Please give us at least 4 more weeks to do the remaining kfreebsd-*. That will provide some margin to account for the non-infinite free time to work on that (especially in the freeze period) and possibly to get more disk space for the debian-ports machine. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
On 13.04.19 17:01, Joerg Jaspert wrote: > On 15371 March 1977, Aurelien Jarno wrote: > >>> How is the move to debian-ports supposed to happen? I won't have the >>> time to do anything about it within the 2 weeks. > >> The process to inject all packages to debian-ports is to get all the >> deb, udeb and buildinfo files from the archives (main and debug) and >> associate them with the .changes files that are hosted on coccia. We'll >> also need to fetch all the associated GPG keys used to sign the changes >> files. Then we can inject that in the debian-ports archive. > >> It would be nice to have a bit more than 2 weeks to do all of that. > > Ok. How much? Is 6 or 8 weeks better? I don't think, given how long this > is on the table already, it doesn't make much difference if its 2 or 8. > Just something thats clear defined and not some random, non-clear > "sometime in the future" point. well, please go back in history to see the same short notice for the hppa removal, and then do the exercise how long it took to integrate that architecture on debian-ports. >
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
On 15371 March 1977, Aurelien Jarno wrote: How is the move to debian-ports supposed to happen? I won't have the time to do anything about it within the 2 weeks. The process to inject all packages to debian-ports is to get all the deb, udeb and buildinfo files from the archives (main and debug) and associate them with the .changes files that are hosted on coccia. We'll also need to fetch all the associated GPG keys used to sign the changes files. Then we can inject that in the debian-ports archive. It would be nice to have a bit more than 2 weeks to do all of that. Ok. How much? Is 6 or 8 weeks better? I don't think, given how long this is on the table already, it doesn't make much difference if its 2 or 8. Just something thats clear defined and not some random, non-clear "sometime in the future" point. -- bye, Joerg
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
On 4/13/2019 12:49 PM, Aurelien Jarno wrote: > The process to inject all packages to debian-ports is to get all the > deb, udeb and buildinfo files from the archives (main and debug) and > associate them with the .changes files that are hosted on coccia. We'll > also need to fetch all the associated GPG keys used to sign the changes > files. Then we can inject that in the debian-ports archive. I'm curious how the GPG bit works given that there is no guarantee that the signature can be validated at any other point in time than ingestion on ftp-master - especially considering the rotation/expiry of subkeys and buildd keys. In this case the files already come from a trusted source and should be ingested as-is, I guess? (Not that I particularly like the fact that it's only a point in time validation.) Kind regards Philipp Kern
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
On 2019-04-12 23:01, Samuel Thibault wrote: > Hello, > > Joerg Jaspert, le ven. 12 avril 2019 22:48:42 +0200, a ecrit: > > back in August 2018 we discussed architecture inclusion into > > unstable/experimental. > > > > Today we had our regular FTPMaster meeting and discussed hurd and both > > kfreebsd architecture and decided to remove them from unstable and > > experimental 2 weeks from now. > > Just before the Buster release? That's far from the easiest timing. > > I was hoping to do a non-official relase of Debian Hurd along Buster as > usual, but a change of archive, which means uploading packages, fixing > scripts, etc. will take a lot of time, which I simply just will not have > within the coming two-three months (I am already struggling to find time > to do what I engaged to). Basically, it means no non-official release of > Debian Hurd along Buster. Or at best I could just make that non-official > release now, with all the still pending RC bugs. > > How is the move to debian-ports supposed to happen? I won't have the > time to do anything about it within the 2 weeks. The process to inject all packages to debian-ports is to get all the deb, udeb and buildinfo files from the archives (main and debug) and associate them with the .changes files that are hosted on coccia. We'll also need to fetch all the associated GPG keys used to sign the changes files. Then we can inject that in the debian-ports archive. It would be nice to have a bit more than 2 weeks to do all of that. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#892428: pocl: FTBFS on x32: tries to build kernel/host/ for amd64
Source: pocl Version: 1.0-2 Severity: normal User: debian-...@lists.debian.org Usertags: x32 Builds of pocl for x32 (admittedly not a release architecture) have been failing, as detailed at [1]: cd "/<>/obj-x86_64-linux-gnux32/lib/kernel/host" && /usr/bin/clang-4.0 --target=x86_64-pc-linux-gnu -D_CL_DISABLE_HALF -march=x86-64 -emit-llvm -ffp-contract=off -xc -D__CBUILD__ -fno-stack-protector -fno-PIC -DDORENAME -DVEC128 -I "/<>/lib/kernel/sleef/arch" -I "/<>/lib/kernel/sleef/libm" -I "/<>/lib/kernel/sleef/include" -O1 -o "/<>/obj-x86_64-linux-gnux32/lib/kernel/host/x86-64/v128_sleefsimddp.c.bc" -c "/<>/lib/kernel/sleef/libm/sleefsimddp.c" In file included from /<>/lib/kernel/sleef/libm/sleefsimddp.c:8: In file included from /usr/lib/llvm-4.0/bin/../lib/clang/4.0.1/include/stdint.h:61: /usr/include/stdint.h:26:10: fatal error: 'bits/libc-header-start.h' file not found Could you please take a look? (Note the explicit inappropriate -march=x86-64.) Thanks! [1] https://buildd.debian.org/status/fetch.php?pkg=pocl&arch=x32&ver=1.1%7Erc2-1&stamp=1520368921&raw=0 -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Debian 9.3 - libicu-dev amd64 hash mismatch
Dear Friends, Sorry for the crossposting (Debian amd64/OSv) I"m trying to update the list of packages required for OSv to run on Debian 9.3 and during my tests, I had the following issue: root@debian:/home/netto/osv# apt-get -y --fix-missing install ant autoconf build-essential gawk gdb genromfs gnutls-bin libboost-all-dev libedit-dev libmaven-shade-plugin-java libncurses5-dev libssl-dev libtool maven openssl p11-kit python-dpkt python-requests qemu-system-x86 qemu-utils tcpdump wget lib32stdc++-6-dev openjdk-8-jdk Reading package lists... Done Building dependency tree Reading state information... Done ... Get:1 http://ftp.us.debian.org/debian stretch/main amd64 libicu-dev amd64 57.1-6+deb9u1 [16.5 MB] Err:1 http://ftp.us.debian.org/debian stretch/main amd64 libicu-dev amd64 57.1-6+deb9u1 Hash Sum mismatch Hashes of expected file: - SHA256:d32b7755a4ada83da57aa72dc272078565e75d7249f2740216b189ad7a7d93ff - MD5Sum:30a6551c42e1b66122b00ed57a2d6d9d [weak] - Filesize:16482724 [weak] Hashes of received file: - SHA256:398ee58b3c11af07d1bb62965df0ae0262b20ff70ef2d93542fb3e38221c8a1e - MD5Sum:f627866bab6df63906e34ebb2e30a963 [weak] - Filesize:1129071 [weak] Last modification reported: Sun, 26 Nov 2017 17:36:08 + Fetched 2,647 B in 2min 38s (16 B/s) Unable to correct missing packages. E: Failed to fetch http://ftp.us.debian.org/debian/pool/main/i/icu/libicu-dev_57.1-6+deb9u1_amd64.deb Hash Sum mismatch Hashes of expected file: - SHA256:d32b7755a4ada83da57aa72dc272078565e75d7249f2740216b189ad7a7d93ff - MD5Sum:30a6551c42e1b66122b00ed57a2d6d9d [weak] - Filesize:16482724 [weak] Hashes of received file: - SHA256:398ee58b3c11af07d1bb62965df0ae0262b20ff70ef2d93542fb3e38221c8a1e - MD5Sum:f627866bab6df63906e34ebb2e30a963 [weak] - Filesize:1129071 [weak] Last modification reported: Sun, 26 Nov 2017 17:36:08 + E: Aborting install. Is there any suggestion on how to fix this? I have tried to change the mirror Previously, I was using debian br mirror and I have tried others but it seems there is a constant mismatch in the package hash Kind Regards, Geraldo Netto Sapere Aude => Non dvcor, dvco http://exdev.sf.net/
Re: Can an iMac 24" with Core2 Duo run Debian AMD64?
I have successfully used debian-mac-8.7.1-amd64-netinst.iso to install a 64-bit OS on a Mac mini 2,1, which also has a 64-bit capable Core 2 Duo and a 32bit EFI. Perhaps a current debian-mac-x.x.x-amd64-netinst.iso from http://cdimage.debian.org/cdimage/release/current/amd64/iso-cd/ will also work on an iMac with similar issues. If I remember correctly it installed GRUB, but I later switched to rEFInd. The wiki page for the Intel Mac mini might be of interest: https://wiki.debian.org/MacMiniIntel#Macmini_2.2C1 On Mon, Nov 6, 2017 at 4:52 PM, Robert Goley wrote: > Yes it can but you have to install differently. That series of mac has > some different 32bit/64 bit EFI type issues. It is best to use a regular > non EFI installer to install Linux on it. I had a macbook with the same > type of issue. The error you pasted is exactly the same one I encountered > when installers started incorporating the EFI installers. I no longer have > that hardware so haven't done an install in some time so I can't tell you > where/ how to get an installer without EFI enabled. Worst case, you could > do a minimal install of an older version and then dist-upgrade to the > latest version. You could also do a chroot install from a bootable > livecd. You should be able to find an installer with EFI disabled though. > > On Mon, Nov 6, 2017 at 10:40 AM, Steven Grunza > wrote: > >> I tried booting Debian 9.2.0 live netinstall and live. >> >> Both started up and gave a black screen with white writing and then a >> screen similar to: >> >>1. >> >>2. >> Select CD-ROM Boot Type :_ >> >> >> Nothing I did on the attached USB keyboard had any affect, nor did >> anything I did with the mouse. >> >> >> >> I received the machine from someone that upgraded to a newer machine. >> The hard drive was mostly wiped clean and Apple no longer supports the >> over-the-network install. >> >> My hope was to replace an iMac G5 (running Xubuntu) with this machine >> since the G5 is so incredibly slow (radeon driver issues most likely). >> >> Any suggestions on how to get the machine running x86_64 would be welcome >> - I'm hoping to be able to build Android and Android apps on the machine so >> it needs to be 64-bit. >> >> Steven G. >> > > > > -- > >
Re: Can an iMac 24" with Core2 Duo run Debian AMD64?
Yes it can but you have to install differently. That series of mac has some different 32bit/64 bit EFI type issues. It is best to use a regular non EFI installer to install Linux on it. I had a macbook with the same type of issue. The error you pasted is exactly the same one I encountered when installers started incorporating the EFI installers. I no longer have that hardware so haven't done an install in some time so I can't tell you where/ how to get an installer without EFI enabled. Worst case, you could do a minimal install of an older version and then dist-upgrade to the latest version. You could also do a chroot install from a bootable livecd. You should be able to find an installer with EFI disabled though. On Mon, Nov 6, 2017 at 10:40 AM, Steven Grunza wrote: > I tried booting Debian 9.2.0 live netinstall and live. > > Both started up and gave a black screen with white writing and then a > screen similar to: > >1. > >2. > Select CD-ROM Boot Type :_ > > > Nothing I did on the attached USB keyboard had any affect, nor did > anything I did with the mouse. > > > > I received the machine from someone that upgraded to a newer machine. The > hard drive was mostly wiped clean and Apple no longer supports the > over-the-network install. > > My hope was to replace an iMac G5 (running Xubuntu) with this machine > since the G5 is so incredibly slow (radeon driver issues most likely). > > Any suggestions on how to get the machine running x86_64 would be welcome > - I'm hoping to be able to build Android and Android apps on the machine so > it needs to be 64-bit. > > Steven G. > --
Can an iMac 24" with Core2 Duo run Debian AMD64?
I tried booting Debian 9.2.0 live netinstall and live. Both started up and gave a black screen with white writing and then a screen similar to: 1. 2. Select CD-ROM Boot Type :_ Nothing I did on the attached USB keyboard had any affect, nor did anything I did with the mouse. I received the machine from someone that upgraded to a newer machine. The hard drive was mostly wiped clean and Apple no longer supports the over-the-network install. My hope was to replace an iMac G5 (running Xubuntu) with this machine since the G5 is so incredibly slow (radeon driver issues most likely). Any suggestions on how to get the machine running x86_64 would be welcome - I'm hoping to be able to build Android and Android apps on the machine so it needs to be 64-bit. Steven G.
Re: debian9 amd64 failure to connect to lvmetad, falling back to device scanning
NEW:I have finally obtained a red-labeled line on booting, telling "Failed to load console system Reboot Logging" This implies that it is not merely a problem of console ownership. A rapid web survey failed to provide indications as to having the console loaded during booting on Debian amd64 stretch. hope someone knows that On Sun, May 21, 2017 at 7:22 PM, Francesco Pietra wrote: > I should add that, once the Xserver is launched by the aid of the other > computer on LAN, the server works autonomously from its keyboard and > terminals. I could run at an impressively high speed a most recent special > form of molecular dynamics on the six cores, six threads, and the two > GTX680 combined, with a recent cuda driver (375.39, offered by stretch). > This is a very strict test. I could use the server this way for my > scientific work but it would be unaesthetic at the best. > > The need of setting the Xwrapper to anybody confirms that the user has no > command of the console, but I was unable to go on this way toward avoiding > the external assistance. > > fp > > On Sun, May 21, 2017 at 11:32 AM, Francesco Pietra > wrote: > >> Back to your suspicion about the GTX680, I was really surprised that the >> Xserver could be raised from the other computer (vaio) on the LAN, only as >> a superuser. >> >> I had to change "allowed_users=console" (which is default on all my linux >> boxes) to "allowed_users=anybody" in /etc/X11/Xwrapper.config. >> >> This way the "X" or "startx" commands do their job perfectly, however >> only from the vaio console. In the "defective" system, rebooting from the >> console brings again to warnings about failure to connect to lvmetad and >> EDAC sbridge, followed the login prompt, which disappears immediately, and >> then "disk scanning" and no way to get the login prompt prompt via >> Ctrl+AlT+F2 (or F1 or F3). Like for a dead console. >> >> At this point, all that appears to be a silly problem but I could not >> find a solution. Having to reinstall amd64 would be a defeat. >> >> fp >> >> >> On Fri, May 19, 2017 at 4:12 PM, Francesco Pietra >> wrote: >> >>> Your server is booting, but not providing a login >>>> >>> >>> I forgot to say that the request of username/password does indeed appear >>> during booting but transiently, followed by that interminable access to >>> disk. I was unable to stop (with Ctrl-S) at the login request. >>> >>> Can you log in on >>>> a VT console (press Ctrl+Alt+F2 to see if you get a login prompt)? >>>> >>> >>> No, nothing happens with on Ctrl+Alt+F2 from the GPU server keyboard. >>> >>> from the VAIO, what does "grep -E 'WW|EE' >>>> /var/log/Xorg.0.log" show (on the server, perhaps as root)? >>>> >>> >>> francesco@.:~$ grep -E 'WW|EE' /var/log/Xorg.0.log >>> (WW) warning, (EE) error, (NI) not implemented, (??) unknown. >>> [56.025] (WW) The directory "/usr/share/fonts/X11/cyrillic" does >>> not exist. >>> [56.070] (WW) Hotplugging is on, devices using drivers 'kbd', >>> 'mouse' or 'vmmouse' will be disabled. >>> [56.070] (WW) Disabling Keyboard0 >>> [56.070] (WW) Disabling Mouse0 >>> francesco@.:~$ su >>> Password: >>> root@.:/home/francesco# grep -E 'WW|EE' /var/log/Xorg.0.log >>> (WW) warning, (EE) error, (NI) not implemented, (??) unknown. >>> [56.025] (WW) The directory "/usr/share/fonts/X11/cyrillic" does >>> not exist. >>> [56.070] (WW) Hotplugging is on, devices using drivers 'kbd', >>> 'mouse' or 'vmmouse' will be disabled. >>> [56.070] (WW) Disabling Keyboard0 >>> [56.070] (WW) Disabling Mouse0 >>> root@...:/home/francesco# >>> >>> Those two GPUs had worked without problems on this server with wheezy, >>> and after that on upgrading to jessie. >>> >>> thanks a lot for your kind help >>> >>> francesco pietra >>> >>> >>> >>> On Fri, May 19, 2017 at 11:32 AM, Darac Marjal >> > wrote: >>> >>>> On Fri, May 19, 2017 at 11:12:25AM +0200, Francesco Pietra wrote: >>>> >>>>> "It is not required for normal usage" >>>>> >>>>> The fact is that the X79-based computer does not offer a login >>&
Re: debian9 amd64 failure to connect to lvmetad, falling back to device scanning
I should add that, once the Xserver is launched by the aid of the other computer on LAN, the server works autonomously from its keyboard and terminals. I could run at an impressively high speed a most recent special form of molecular dynamics on the six cores, six threads, and the two GTX680 combined, with a recent cuda driver (375.39, offered by stretch). This is a very strict test. I could use the server this way for my scientific work but it would be unaesthetic at the best. The need of setting the Xwrapper to anybody confirms that the user has no command of the console, but I was unable to go on this way toward avoiding the external assistance. fp On Sun, May 21, 2017 at 11:32 AM, Francesco Pietra wrote: > Back to your suspicion about the GTX680, I was really surprised that the > Xserver could be raised from the other computer (vaio) on the LAN, only as > a superuser. > > I had to change "allowed_users=console" (which is default on all my linux > boxes) to "allowed_users=anybody" in /etc/X11/Xwrapper.config. > > This way the "X" or "startx" commands do their job perfectly, however only > from the vaio console. In the "defective" system, rebooting from the > console brings again to warnings about failure to connect to lvmetad and > EDAC sbridge, followed the login prompt, which disappears immediately, and > then "disk scanning" and no way to get the login prompt prompt via > Ctrl+AlT+F2 (or F1 or F3). Like for a dead console. > > At this point, all that appears to be a silly problem but I could not find > a solution. Having to reinstall amd64 would be a defeat. > > fp > > > On Fri, May 19, 2017 at 4:12 PM, Francesco Pietra > wrote: > >> Your server is booting, but not providing a login >>> >> >> I forgot to say that the request of username/password does indeed appear >> during booting but transiently, followed by that interminable access to >> disk. I was unable to stop (with Ctrl-S) at the login request. >> >> Can you log in on >>> a VT console (press Ctrl+Alt+F2 to see if you get a login prompt)? >>> >> >> No, nothing happens with on Ctrl+Alt+F2 from the GPU server keyboard. >> >> from the VAIO, what does "grep -E 'WW|EE' >>> /var/log/Xorg.0.log" show (on the server, perhaps as root)? >>> >> >> francesco@.:~$ grep -E 'WW|EE' /var/log/Xorg.0.log >> (WW) warning, (EE) error, (NI) not implemented, (??) unknown. >> [56.025] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not >> exist. >> [56.070] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' >> or 'vmmouse' will be disabled. >> [56.070] (WW) Disabling Keyboard0 >> [56.070] (WW) Disabling Mouse0 >> francesco@.:~$ su >> Password: >> root@.:/home/francesco# grep -E 'WW|EE' /var/log/Xorg.0.log >> (WW) warning, (EE) error, (NI) not implemented, (??) unknown. >> [56.025] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not >> exist. >> [56.070] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' >> or 'vmmouse' will be disabled. >> [56.070] (WW) Disabling Keyboard0 >> [56.070] (WW) Disabling Mouse0 >> root@...:/home/francesco# >> >> Those two GPUs had worked without problems on this server with wheezy, >> and after that on upgrading to jessie. >> >> thanks a lot for your kind help >> >> francesco pietra >> >> >> >> On Fri, May 19, 2017 at 11:32 AM, Darac Marjal >> wrote: >> >>> On Fri, May 19, 2017 at 11:12:25AM +0200, Francesco Pietra wrote: >>> >>>> "It is not required for normal usage" >>>> >>>> The fact is that the X79-based computer does not offer a login >>>> possibility, it goes to disk scanning (kernel et al) for hours (at >>>> least 4hr). >>>> >>>> Access to file was only possible from a LAN-connected other computer >>>> (laptop VAIO) or booting from Super Grub2 disk. >>>> >>>> Whether all issues arise from inability to connect to lvmetad, I >>>> cannot say. I am no system analyzer. I merely need the X79-GPU-based >>>> machine for applications (molecular dynamics with recent CUDA). >>>> fp >>>> >>> >>> Personally, I doubt that your GPU (Graphics Processing Unit) is related >>> to how the disks are access, but perhaps you've got a very special >>&g
Re: debian9 amd64 failure to connect to lvmetad, falling back to device scanning
Back to your suspicion about the GTX680, I was really surprised that the Xserver could be raised from the other computer (vaio) on the LAN, only as a superuser. I had to change "allowed_users=console" (which is default on all my linux boxes) to "allowed_users=anybody" in /etc/X11/Xwrapper.config. This way the "X" or "startx" commands do their job perfectly, however only from the vaio console. In the "defective" system, rebooting from the console brings again to warnings about failure to connect to lvmetad and EDAC sbridge, followed the login prompt, which disappears immediately, and then "disk scanning" and no way to get the login prompt prompt via Ctrl+AlT+F2 (or F1 or F3). Like for a dead console. At this point, all that appears to be a silly problem but I could not find a solution. Having to reinstall amd64 would be a defeat. fp On Fri, May 19, 2017 at 4:12 PM, Francesco Pietra wrote: > Your server is booting, but not providing a login >> > > I forgot to say that the request of username/password does indeed appear > during booting but transiently, followed by that interminable access to > disk. I was unable to stop (with Ctrl-S) at the login request. > > Can you log in on >> a VT console (press Ctrl+Alt+F2 to see if you get a login prompt)? >> > > No, nothing happens with on Ctrl+Alt+F2 from the GPU server keyboard. > > from the VAIO, what does "grep -E 'WW|EE' >> /var/log/Xorg.0.log" show (on the server, perhaps as root)? >> > > francesco@.:~$ grep -E 'WW|EE' /var/log/Xorg.0.log > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > [56.025] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not > exist. > [56.070] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' > or 'vmmouse' will be disabled. > [56.070] (WW) Disabling Keyboard0 > [56.070] (WW) Disabling Mouse0 > francesco@.:~$ su > Password: > root@.:/home/francesco# grep -E 'WW|EE' /var/log/Xorg.0.log > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > [56.025] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not > exist. > [56.070] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' > or 'vmmouse' will be disabled. > [56.070] (WW) Disabling Keyboard0 > [56.070] (WW) Disabling Mouse0 > root@...:/home/francesco# > > Those two GPUs had worked without problems on this server with wheezy, and > after that on upgrading to jessie. > > thanks a lot for your kind help > > francesco pietra > > > > On Fri, May 19, 2017 at 11:32 AM, Darac Marjal > wrote: > >> On Fri, May 19, 2017 at 11:12:25AM +0200, Francesco Pietra wrote: >> >>> "It is not required for normal usage" >>> >>> The fact is that the X79-based computer does not offer a login >>> possibility, it goes to disk scanning (kernel et al) for hours (at >>> least 4hr). >>> >>> Access to file was only possible from a LAN-connected other computer >>> (laptop VAIO) or booting from Super Grub2 disk. >>> >>> Whether all issues arise from inability to connect to lvmetad, I >>> cannot say. I am no system analyzer. I merely need the X79-GPU-based >>> machine for applications (molecular dynamics with recent CUDA). >>> fp >>> >> >> Personally, I doubt that your GPU (Graphics Processing Unit) is related >> to how the disks are access, but perhaps you've got a very special >> system. >> >> Also, I'm not sure what issue you're... Oh, I see what's happening! >> >> Your server is booting, but not providing a login. You ARE able to log >> into the server using another computer on the network. This means that >> the server HAS booted from the disk(s). LVM is *not* your problem (if it >> was, the system would probably not be able to load >> /etc/network/interfaces in order to bring up the network, nor the SSH >> daemon, nor the user's home directory ...) >> >> The issue you're having is more likely with that GPU. Can you log in on >> a VT console (press Ctrl+Alt+F2 to see if you get a login prompt)? When >> you log in from the VAIO, what does "grep -E 'WW|EE' >> /var/log/Xorg.0.log" show (on the server, perhaps as root)? >> >> On Fri, May 19, 2017 at 10:24 AM, Darac Marjal >>> <[1]mailingl...@darac.org.uk> wrote: >>> >>> On Fri, May 19, 2017 at 10:17:44AM +0200, Francesco Pietra wrote: >
Re: debian9 amd64 failure to connect to lvmetad, falling back to device scanning
> > Your server is booting, but not providing a login > I forgot to say that the request of username/password does indeed appear during booting but transiently, followed by that interminable access to disk. I was unable to stop (with Ctrl-S) at the login request. Can you log in on > a VT console (press Ctrl+Alt+F2 to see if you get a login prompt)? > No, nothing happens with on Ctrl+Alt+F2 from the GPU server keyboard. from the VAIO, what does "grep -E 'WW|EE' > /var/log/Xorg.0.log" show (on the server, perhaps as root)? > francesco@.:~$ grep -E 'WW|EE' /var/log/Xorg.0.log (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [56.025] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [56.070] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. [56.070] (WW) Disabling Keyboard0 [56.070] (WW) Disabling Mouse0 francesco@.:~$ su Password: root@.:/home/francesco# grep -E 'WW|EE' /var/log/Xorg.0.log (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [56.025] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [56.070] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. [56.070] (WW) Disabling Keyboard0 [56.070] (WW) Disabling Mouse0 root@...:/home/francesco# Those two GPUs had worked without problems on this server with wheezy, and after that on upgrading to jessie. thanks a lot for your kind help francesco pietra On Fri, May 19, 2017 at 11:32 AM, Darac Marjal wrote: > On Fri, May 19, 2017 at 11:12:25AM +0200, Francesco Pietra wrote: > >> "It is not required for normal usage" >> >> The fact is that the X79-based computer does not offer a login >> possibility, it goes to disk scanning (kernel et al) for hours (at >> least 4hr). >> >> Access to file was only possible from a LAN-connected other computer >> (laptop VAIO) or booting from Super Grub2 disk. >> >> Whether all issues arise from inability to connect to lvmetad, I >> cannot say. I am no system analyzer. I merely need the X79-GPU-based >> machine for applications (molecular dynamics with recent CUDA). >> fp >> > > Personally, I doubt that your GPU (Graphics Processing Unit) is related > to how the disks are access, but perhaps you've got a very special > system. > > Also, I'm not sure what issue you're... Oh, I see what's happening! > > Your server is booting, but not providing a login. You ARE able to log > into the server using another computer on the network. This means that > the server HAS booted from the disk(s). LVM is *not* your problem (if it > was, the system would probably not be able to load > /etc/network/interfaces in order to bring up the network, nor the SSH > daemon, nor the user's home directory ...) > > The issue you're having is more likely with that GPU. Can you log in on > a VT console (press Ctrl+Alt+F2 to see if you get a login prompt)? When > you log in from the VAIO, what does "grep -E 'WW|EE' > /var/log/Xorg.0.log" show (on the server, perhaps as root)? > > On Fri, May 19, 2017 at 10:24 AM, Darac Marjal >> <[1]mailingl...@darac.org.uk> wrote: >> >> On Fri, May 19, 2017 at 10:17:44AM +0200, Francesco Pietra wrote: >> >> Hello: >> On a vintage VAIO I have no problems with amd64 stretch. With a >> raid1-based on the X79 chip, upgrading from jessie to stretch >> (I need >> a higher CUDA version than available on jessie for latest >> experimental NAMD molecular dynamics) went on regularly. >> However, the >> command >> >> # systemctl set-default multi-user.target >> >> (which worked fine on said VAIO to boot at the $ linux prompt) >> led to >> failure to connect to lvmetad, falling back to device scanning, >> whereby an endless disk scanning begun. >> >> I tried: >> >> 1) Super grub2 disk: OK it led to clean boot but I found no way >> to >> fix the problem. >> >> 2) Accessing the X79 computer from said VAIO (both are on a >> LAN) >> equally allowed to manage everything but I was unable to fix >> the >> problem. >> >> 3) From said VAIO: >> # systemctl enable lvm2-lvmetad.service >> >> OK, but it was lost on needed reboot. >> >> I never
Re: debian9 amd64 failure to connect to lvmetad, falling back to device scanning
On Fri, May 19, 2017 at 11:12:25AM +0200, Francesco Pietra wrote: "It is not required for normal usage" The fact is that the X79-based computer does not offer a login possibility, it goes to disk scanning (kernel et al) for hours (at least 4hr). Access to file was only possible from a LAN-connected other computer (laptop VAIO) or booting from Super Grub2 disk. Whether all issues arise from inability to connect to lvmetad, I cannot say. I am no system analyzer. I merely need the X79-GPU-based machine for applications (molecular dynamics with recent CUDA). fp Personally, I doubt that your GPU (Graphics Processing Unit) is related to how the disks are access, but perhaps you've got a very special system. Also, I'm not sure what issue you're... Oh, I see what's happening! Your server is booting, but not providing a login. You ARE able to log into the server using another computer on the network. This means that the server HAS booted from the disk(s). LVM is *not* your problem (if it was, the system would probably not be able to load /etc/network/interfaces in order to bring up the network, nor the SSH daemon, nor the user's home directory ...) The issue you're having is more likely with that GPU. Can you log in on a VT console (press Ctrl+Alt+F2 to see if you get a login prompt)? When you log in from the VAIO, what does "grep -E 'WW|EE' /var/log/Xorg.0.log" show (on the server, perhaps as root)? On Fri, May 19, 2017 at 10:24 AM, Darac Marjal <[1]mailingl...@darac.org.uk> wrote: On Fri, May 19, 2017 at 10:17:44AM +0200, Francesco Pietra wrote: Hello: On a vintage VAIO I have no problems with amd64 stretch. With a raid1-based on the X79 chip, upgrading from jessie to stretch (I need a higher CUDA version than available on jessie for latest experimental NAMD molecular dynamics) went on regularly. However, the command # systemctl set-default multi-user.target (which worked fine on said VAIO to boot at the $ linux prompt) led to failure to connect to lvmetad, falling back to device scanning, whereby an endless disk scanning begun. I tried: 1) Super grub2 disk: OK it led to clean boot but I found no way to fix the problem. 2) Accessing the X79 computer from said VAIO (both are on a LAN) equally allowed to manage everything but I was unable to fix the problem. 3) From said VAIO: # systemctl enable lvm2-lvmetad.service OK, but it was lost on needed reboot. I never had to reinstall a debian amd64 but this time I am lost. Thanks for any kind suggestion Have you enabled the daemon in lvm.conf? Look for "use_lvmetad". However, I think this should not be a problem. lvmetad is the LVM Metadata Daemon, which is primarily a caching daemon. If you have a lot of disks, or change your logical volumes frequently, the lvmetad can speed up the varioud LVM commands. It is not required for normal usage and ~99% of people can ignore the "failure to connect" message. francesco pietra -- For more information, please reread. References Visible links 1. mailto:mailingl...@darac.org.uk -- For more information, please reread. signature.asc Description: PGP signature
Re: debian9 amd64 failure to connect to lvmetad, falling back to device scanning
> > "It is not required for normal usage" > The fact is that the X79-based computer does not offer a login possibility, it goes to disk scanning (kernel et al) for hours (at least 4hr). Access to file was only possible from a LAN-connected other computer (laptop VAIO) or booting from Super Grub2 disk. Whether all issues arise from inability to connect to lvmetad, I cannot say. I am no system analyzer. I merely need the X79-GPU-based machine for applications (molecular dynamics with recent CUDA). fp On Fri, May 19, 2017 at 10:24 AM, Darac Marjal wrote: > On Fri, May 19, 2017 at 10:17:44AM +0200, Francesco Pietra wrote: > >> Hello: >> On a vintage VAIO I have no problems with amd64 stretch. With a >> raid1-based on the X79 chip, upgrading from jessie to stretch (I need >> a higher CUDA version than available on jessie for latest >> experimental NAMD molecular dynamics) went on regularly. However, the >> command >> >> # systemctl set-default multi-user.target >> >> (which worked fine on said VAIO to boot at the $ linux prompt) led to >> failure to connect to lvmetad, falling back to device scanning, >> whereby an endless disk scanning begun. >> >> I tried: >> >> 1) Super grub2 disk: OK it led to clean boot but I found no way to >> fix the problem. >> >> 2) Accessing the X79 computer from said VAIO (both are on a LAN) >> equally allowed to manage everything but I was unable to fix the >> problem. >> >> 3) From said VAIO: >># systemctl enable lvm2-lvmetad.service >> >> OK, but it was lost on needed reboot. >> >> I never had to reinstall a debian amd64 but this time I am lost. >> >> Thanks for any kind suggestion >> > > Have you enabled the daemon in lvm.conf? Look for "use_lvmetad". > > However, I think this should not be a problem. lvmetad is the LVM > Metadata Daemon, which is primarily a caching daemon. If you have a lot > of disks, or change your logical volumes frequently, the lvmetad can > speed up the varioud LVM commands. It is not required for normal usage > and ~99% of people can ignore the "failure to connect" message. > > >> francesco pietra >> >> > > -- > For more information, please reread. >
Re: debian9 amd64 failure to connect to lvmetad, falling back to device scanning
I forgot to mention that ---changing in /etc/lvm from "use_lvmetad=1" to "use_lvmetad=0" or commenting out in /etc/defaut/grub ---# GRUB_CMDLINE_LINUX_DEFAULT="quiet" did not solve the problem fp On Fri, May 19, 2017 at 10:21 AM, Francesco Pietra wrote: > I understand that udev is in focus, however I don't know how to marriage > lvmetad and udev > > francesco pietra > > On Fri, May 19, 2017 at 10:17 AM, Francesco Pietra > wrote: > >> Hello: >> On a vintage VAIO I have no problems with amd64 stretch. With a >> raid1-based on the X79 chip, upgrading from jessie to stretch (I need a >> higher CUDA version than available on jessie for latest experimental NAMD >> molecular dynamics) went on regularly. However, the command >> >> # systemctl set-default multi-user.target >> >> (which worked fine on said VAIO to boot at the $ linux prompt) led to >> failure to connect to lvmetad, falling back to device scanning, whereby an >> endless disk scanning begun. >> >> I tried: >> >> 1) Super grub2 disk: OK it led to clean boot but I found no way to fix >> the problem. >> >> 2) Accessing the X79 computer from said VAIO (both are on a LAN) equally >> allowed to manage everything but I was unable to fix the problem. >> >> 3) From said VAIO: >> # systemctl enable lvm2-lvmetad.service >> >> OK, but it was lost on needed reboot. >> >> I never had to reinstall a debian amd64 but this time I am lost. >> >> Thanks for any kind suggestion >> >> francesco pietra >> >> >> >> >> >
Re: debian9 amd64 failure to connect to lvmetad, falling back to device scanning
On Fri, May 19, 2017 at 10:17:44AM +0200, Francesco Pietra wrote: Hello: On a vintage VAIO I have no problems with amd64 stretch. With a raid1-based on the X79 chip, upgrading from jessie to stretch (I need a higher CUDA version than available on jessie for latest experimental NAMD molecular dynamics) went on regularly. However, the command # systemctl set-default multi-user.target (which worked fine on said VAIO to boot at the $ linux prompt) led to failure to connect to lvmetad, falling back to device scanning, whereby an endless disk scanning begun. I tried: 1) Super grub2 disk: OK it led to clean boot but I found no way to fix the problem. 2) Accessing the X79 computer from said VAIO (both are on a LAN) equally allowed to manage everything but I was unable to fix the problem. 3) From said VAIO: # systemctl enable lvm2-lvmetad.service OK, but it was lost on needed reboot. I never had to reinstall a debian amd64 but this time I am lost. Thanks for any kind suggestion Have you enabled the daemon in lvm.conf? Look for "use_lvmetad". However, I think this should not be a problem. lvmetad is the LVM Metadata Daemon, which is primarily a caching daemon. If you have a lot of disks, or change your logical volumes frequently, the lvmetad can speed up the varioud LVM commands. It is not required for normal usage and ~99% of people can ignore the "failure to connect" message. francesco pietra -- For more information, please reread. signature.asc Description: PGP signature
Re: debian9 amd64 failure to connect to lvmetad, falling back to device scanning
I understand that udev is in focus, however I don't know how to marriage lvmetad and udev francesco pietra On Fri, May 19, 2017 at 10:17 AM, Francesco Pietra wrote: > Hello: > On a vintage VAIO I have no problems with amd64 stretch. With a > raid1-based on the X79 chip, upgrading from jessie to stretch (I need a > higher CUDA version than available on jessie for latest experimental NAMD > molecular dynamics) went on regularly. However, the command > > # systemctl set-default multi-user.target > > (which worked fine on said VAIO to boot at the $ linux prompt) led to > failure to connect to lvmetad, falling back to device scanning, whereby an > endless disk scanning begun. > > I tried: > > 1) Super grub2 disk: OK it led to clean boot but I found no way to fix the > problem. > > 2) Accessing the X79 computer from said VAIO (both are on a LAN) equally > allowed to manage everything but I was unable to fix the problem. > > 3) From said VAIO: > # systemctl enable lvm2-lvmetad.service > > OK, but it was lost on needed reboot. > > I never had to reinstall a debian amd64 but this time I am lost. > > Thanks for any kind suggestion > > francesco pietra > > > > >
debian9 amd64 failure to connect to lvmetad, falling back to device scanning
Hello: On a vintage VAIO I have no problems with amd64 stretch. With a raid1-based on the X79 chip, upgrading from jessie to stretch (I need a higher CUDA version than available on jessie for latest experimental NAMD molecular dynamics) went on regularly. However, the command # systemctl set-default multi-user.target (which worked fine on said VAIO to boot at the $ linux prompt) led to failure to connect to lvmetad, falling back to device scanning, whereby an endless disk scanning begun. I tried: 1) Super grub2 disk: OK it led to clean boot but I found no way to fix the problem. 2) Accessing the X79 computer from said VAIO (both are on a LAN) equally allowed to manage everything but I was unable to fix the problem. 3) From said VAIO: # systemctl enable lvm2-lvmetad.service OK, but it was lost on needed reboot. I never had to reinstall a debian amd64 but this time I am lost. Thanks for any kind suggestion francesco pietra
Re: Fwd: Probmes in running scipy with amd64
On Sun, Apr 30, 2017 at 06:59:56AM -0400, Francesco Pietra wrote: > All python bugs solved by installing Anaconda2. The drug-hunting software > is running in Debian9 (stretch) on Anaconda2 python. Or another way of looking at it: All scipy bugs worked around by giving it exactly the version of everything that it assumes. scipy is not very robust when it comes to dealing with variations in python library versions. My impression is that the scientific software in general does not spend time on making things portable, as long as it works in the one environment they work in. Anything more would be time wasted that could have been spent on something else. -- Len Sorensen
Fwd: Probmes in running scipy with amd64
All python bugs solved by installing Anaconda2. The drug-hunting software is running in Debian9 (stretch) on Anaconda2 python. francesco pietra -- Forwarded message -- From: Francesco Pietra Date: Sun, Apr 30, 2017 at 3:00 AM Subject: Probmes in running scipy with amd64 To: amd64 Debian Since a few days I am trying to get scipy support to a drug-hunting code. I first used a clean jessie (scipy 14), installing > apt-get install python-numpy python-scipy > > whereby, on running the drug hunting code, I got the scipy error: File "/usr/lib/python2.7/dist-packages/scipy/optimize/optimize.py", line 17 > from *future* import division, print_function, absolute_import > SyntaxError: future feature print_function is not defined > Then I installed other packages (huge installation), as indicated on the web for getting a working scipy: > apt-get install python-numpy python-scipy python-matplotlib ipython > ipython-notebook python-pandas python-sympy python-nose > > > (for stretch ipython-notebook was not available, while it was for jessie) > > dropping into the same error as above. I assumed that the available python lacked that function. Therefore, I went to stretch (scipy 18), now getting the error: File "/usr/lib/python2.7/dist-packages/scipy/optimize/optimize.py", line 769 > with warnings.catch_warnings(): > ^ > SyntaxError: invalid syntax > On these events, I was advised to abandon python as available in debian and installing anaconda python. Such advice seems to imply (although it was not said) that python, or pieces of python, in debian are buggy. Before following that advice (anaconda python, from its web presentation, seems more a shortcut for those not having root privilege, which is not my case), I am asking about experience in using scipy with debian, and whether there is any trick, or configuration, to be followed in its installation. Thanks a lot for sharing experience francesco pietra
Probmes in running scipy with amd64
Since a few days I am trying to get scipy support to a drug-hunting code. I first used a clean jessie (scipy 14), installing > apt-get install python-numpy python-scipy > > whereby, on running the drug hunting code, I got the scipy error: File "/usr/lib/python2.7/dist-packages/scipy/optimize/optimize.py", line 17 > from *future* import division, print_function, absolute_import > SyntaxError: future feature print_function is not defined > Then I installed other packages (huge installation), as indicated on the web for getting a working scipy: > apt-get install python-numpy python-scipy python-matplotlib ipython > ipython-notebook python-pandas python-sympy python-nose > > > (for stretch ipython-notebook was not available, while it was for jessie) > > dropping into the same error as above. I assumed that the available python lacked that function. Therefore, I went to stretch (scipy 18), now getting the error: File "/usr/lib/python2.7/dist-packages/scipy/optimize/optimize.py", line 769 > with warnings.catch_warnings(): > ^ > SyntaxError: invalid syntax > On these events, I was advised to abandon python as available in debian and installing anaconda python. Such advice seems to imply (although it was not said) that python, or pieces of python, in debian are buggy. Before following that advice (anaconda python, from its web presentation, seems more a shortcut for those not having root privilege, which is not my case), I am asking about experience in using scipy with debian, and whether there is any trick, or configuration, to be followed in its installation. Thanks a lot for sharing experience francesco pietra
Re: Rename amd64 to klinux-amd64
On Wed, May 11, 2016 at 05:04:06AM -0700, Amir H. Firouzian wrote: > Hello alls, > Due to fact that other kernels are become populate like BSD, and Debian is > universal OS, So is it better to rename all Ports and mention the kernel > use that inside like kfreebsd-amd64 or khurd-i386? > > https://www.debian.org/ports/ i386 was't renamed when it stopped even supporting i386 and moved to i486 and later i586. Too many things already know the port name and depend on it. I think historical precedence says that Debian is linux unless it says otherwise in the port name. linux is implied. -- Len Sorensen
Rename amd64 to klinux-amd64
Hello alls, Due to fact that other kernels are become populate like BSD, and Debian is universal OS, So is it better to rename all Ports and mention the kernel use that inside like kfreebsd-amd64 or khurd-i386? https://www.debian.org/ports/ Regards, Amir
Re: debian-amd64 list obsolete now ?
I think there is no need to be traffic intense to be useful... On Thu, Jan 29, 2015, 13:54 Michael wrote: > > I wonder about the future of this list. There isn't so much point in > having amd64 as something exclusively anymore. It's low traffic too. > > Hendrik pointed me to JIT compilers who seem to differ between 32 and 64 > bit. Well, i don't know ... > > I really don't want to down the list, i rather wonder if it could be > revamped somehow. > > I guess renaming a list is the same as shutting down and transfer the > members to a new one. > > > -- > To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: https://lists.debian.org/20150129205407.055179ba@ > mirrors.kernel.org > >
debian-amd64 list obsolete now ?
I wonder about the future of this list. There isn't so much point in having amd64 as something exclusively anymore. It's low traffic too. Hendrik pointed me to JIT compilers who seem to differ between 32 and 64 bit. Well, i don't know ... I really don't want to down the list, i rather wonder if it could be revamped somehow. I guess renaming a list is the same as shutting down and transfer the members to a new one. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150129205407.05517...@mirrors.kernel.org
Re: How many *physical CPU* can Debian-7.7.0-amd64 support?
On Mon, Dec 08, 2014 at 04:25:48PM +, Shio Gai Quek wrote: > Dear All > Sorry for cross-posting my previous mail. > I have one question remaining unanswered: > How many physical CPU can Debian-7.7.0-amd64 support? (FYI, Win 7 > Ultimate supports 2) > (I know Debian-7.7.0-amd64 supports up to 512 logical CPU (i.e. cores) ) As far as I know linux does not care if they are in 1 chip or 2 or 50. It just uses the cores that exist. Windows has odd rules to prevent running a desktop OS on a 4 socket server board for no good reason. Those are artificial limitations. Linux doesn't bother with artificial limits. Microsoft just wants to charge you more money if you run on higher end server hardware because they can. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141208170153.gu24...@csclub.uwaterloo.ca
How many *physical CPU* can Debian-7.7.0-amd64 support?
Dear All Sorry for cross-posting my previous mail. I have one question remaining unanswered: How many physical CPU can Debian-7.7.0-amd64 support? (FYI, Win 7 Ultimate supports 2) (I know Debian-7.7.0-amd64 supports up to 512 logical CPU (i.e. cores) ) Hope to hear from you soon. Regards Quek
Re: Urgent! Questions/Confirmations concerning *Debian 7.7.0 amd64* before I install it.
On Mon, Dec 08, 2014 at 10:23:04AM +, Darac Marjal wrote: > I believe Debian limits this to 8 with a default kernel. However, you > can recompile the kernel to raise the limit to 4096 (or 8192 with a > newer kernel). Well the config in the amd64 3.2 kernel says: CONFIG_NR_CPUS=512 So that's a lot more than 8. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141208152816.gt24...@csclub.uwaterloo.ca
Re: Urgent! Questions/Confirmations concerning *Debian 7.7.0 amd64* before I install it.
On 12/08/2014 12:23 PM, Darac Marjal wrote: > On Mon, Dec 08, 2014 at 07:26:41AM +, Shio Gai Quek wrote: >> Dear All >> >> My name is Quek from Malaysia. I am now downloading Debian 7.7.0 >> amd64. >> >> Right now my workstation uses w** 7 ultimate 64bit, with >> one(1) CPU (Core i7-4770K), and 32GB of RAM. >> >> I need your help! Before I decide to install it for my upcoming >> "compute-server" and possibly even my current workstation, I need >> to confirm with ALL the following: >> ------ >> >> 1. According to: https://www.debian.org/ports/amd64/ >> It appears to me that Debian 7.7.0 amd64 supports up to 64TB of >> RAM, which is much more than even the 192GB limit for w**. >> Kindly confirm. > > This appears to be the case. At the moment, amd64 processors only > have 48-bit address busses. 2^46 is ~256TiB. However, due to the > memory architecture, 64TiB is the limit of physical RAM supported > by linux (you can add to that a further ~64TiB of swap, as the > kernel can address 128TiB of virtual memory). > >> >> 2. According to: >> https://www.gnu.org/philosophy/ubuntu-spyware.html It appears to >> me that some GNU OS has this annoying problem, how about Debian >> 7.7.0 amd64? > > Ubuntu (or rather, Canonical) are a commercial entity. It is in > their interests to make money from their users. Debian is a loose > organisation committed to the "Social Contract" and the DFSG > (https://www.debian.org/social_contract) which, among other things, > states "Our priorities are our users and free software". > >> >> 3. According to: https://www.gnu.org/distros/common-distros.html >> >> It appears to me than some of the features in the >> firmware/repository are not free. Therefore, during installation >> of Debian 7.7.0 amd64, a. "the installer in some cases recommends >> these nonfree firmware files for the peripherals on the >> machine." Will I be given the choice not to install those >> nonfree features? > > That's true. There is a screen in the installer where you are asked > if you'd like to include non-free software. Note, however, that > Debian is sometimes viewed as "not free enough" in some quarters; > you can install free software which requires non-free services to > operate, you can install free software which depends on non-free > software (for example, there are "downloader" packages whose sole > purpose is to install non-free software such as Adobe Flash). You > are, of course, free to *not* install these and, in many cases, > functional alternatives are available. > >> b. If I do so, i. Will it affect the performance of the OS? > > It depends on the hardware. Some graphics cards will not fully > accelerate without proprietary firmware. Some network cards, too, > have issues when running without firmware. > >> >> ii. Will the maximum supporting RAM remains 64TB? > > Yes. > >> >> iii. Will I still benefit from ALL advantages amd64 offers, as >> stated in "A complete 64bit userland" of site >> https://www.debian.org/ports/amd64/? > > Yes. All these points are features of the CPU which won't need > non-free firmware to work. > >> >> 4. According to >> http://cdimage.debian.org/debian-cd/7.7.0/amd64/iso-dvd/ , There >> are 5 isos (which I am downloading) "Debian-7.7.0-amd64-DVD-1.iso >> 2014-10-18 15:39 3.7G " "Debian-7.7.0-amd64-DVD-2.iso >> 2014-10-18 15:39 4.4G " "Debian-7.7.0-amd64-DVD-3.iso >> 2014-10-18 15:39 4.4G " "Debian-update-7.7.0-amd64-DVD-1.iso >> 2014-10-19 02:16 4.2G " "Debian-update-7.7.0-amd64-DVD-2.iso >> 2014-10-19 02:19 1.6G " Which of them is/are mandatory for >> installation of Debian 7.7.0 amd64? (Note: Please do NOT direct >> me to the net-installer! I need a robust DVD file than enables me >> to install it offline! Moreover, this compute-server may not be >> connected to the internet) > > DVD-1 will be enough to install a desktop system. The packages on > the DVDs are sorted by popularity, so DVD-1 should give you all you > need in most cases, DVD-2 may well be more useful to you for > installing your compute-server tasks. If in doubt, though, take a > look at the list files > (http://cdimage.debian.org/debian-cd/7.7.0/amd64/list-dvd/) for > contents of each
Re: Urgent! Questions/Confirmations concerning *Debian 7.7.0 amd64* before I install it.
On Mon, Dec 08, 2014 at 07:26:41AM +, Shio Gai Quek wrote: >Dear All > >My name is Quek from Malaysia. I am now downloading Debian 7.7.0 amd64. > >Right now my workstation uses w** 7 ultimate 64bit, with one(1) CPU >(Core i7-4770K), and 32GB of RAM. > >I need your help! >Before I decide to install it for my upcoming "compute-server" and >possibly even my current workstation, >I need to confirm with ALL the following: > > -- > 1. According to: https://www.debian.org/ports/amd64/ > It appears to me that Debian 7.7.0 amd64 supports up to 64TB of RAM, >which is much more than even the 192GB limit for > w**. Kindly confirm. This appears to be the case. At the moment, amd64 processors only have 48-bit address busses. 2^46 is ~256TiB. However, due to the memory architecture, 64TiB is the limit of physical RAM supported by linux (you can add to that a further ~64TiB of swap, as the kernel can address 128TiB of virtual memory). > >2. According to: https://www.gnu.org/philosophy/ubuntu-spyware.html > It appears to me that some GNU OS has this annoying problem, how about >Debian 7.7.0 amd64? Ubuntu (or rather, Canonical) are a commercial entity. It is in their interests to make money from their users. Debian is a loose organisation committed to the "Social Contract" and the DFSG (https://www.debian.org/social_contract) which, among other things, states "Our priorities are our users and free software". > >3. According to: https://www.gnu.org/distros/common-distros.html > > It appears to me than some of the features in the firmware/repository >are not free. Therefore, during installation of Debian 7.7.0 amd64, > a. "the installer in some cases recommends these nonfree firmware >files for the peripherals on the machine." > Will I be given the choice not to install those nonfree >features? That's true. There is a screen in the installer where you are asked if you'd like to include non-free software. Note, however, that Debian is sometimes viewed as "not free enough" in some quarters; you can install free software which requires non-free services to operate, you can install free software which depends on non-free software (for example, there are "downloader" packages whose sole purpose is to install non-free software such as Adobe Flash). You are, of course, free to *not* install these and, in many cases, functional alternatives are available. > b. If I do so, i. Will it affect the performance of the OS? It depends on the hardware. Some graphics cards will not fully accelerate without proprietary firmware. Some network cards, too, have issues when running without firmware. > > ii. Will the maximum supporting RAM remains >64TB? Yes. > > iii. Will I still benefit from ALL advantages >amd64 offers, as stated in "A complete 64bit userland" of > site https://www.debian.org/ports/amd64/? Yes. All these points are features of the CPU which won't need non-free firmware to work. > >4. According to http://cdimage.debian.org/debian-cd/7.7.0/amd64/iso-dvd/ , > There are 5 isos (which I am downloading) > "Debian-7.7.0-amd64-DVD-1.iso 2014-10-18 15:39 3.7G " > "Debian-7.7.0-amd64-DVD-2.iso 2014-10-18 15:39 4.4G " > "Debian-7.7.0-amd64-DVD-3.iso 2014-10-18 15:39 4.4G " > "Debian-update-7.7.0-amd64-DVD-1.iso 2014-10-19 02:16 4.2G " > "Debian-update-7.7.0-amd64-DVD-2.iso 2014-10-19 02:19 1.6G " > Which of them is/are mandatory for installation of Debian 7.7.0 >amd64? > (Note: Please do NOT direct me to the net-installer! I need a robust >DVD file than enables me to install it offline! Moreover, > this compute-server may not be connected to the internet) DVD-1 will be enough to install a desktop system. The packages on the DVDs are sorted by popularity, so DVD-1 should give you all you need in most cases, DVD-2 may well be more useful to you for installing your compute-server tasks. If in doubt, though, take a look at the list files (http://cdimage.debian.org/debian-cd/7.7.0/amd64/list-dvd/) for contents of each disc. The update DVDs should not be needed, as they are for updating from Debian 7.6 to Debian 7.7. > >5. Some Serv
Urgent! Questions/Confirmations concerning *Debian 7.7.0 amd64* before I install it.
Dear All My name is Quek from Malaysia. I am now downloading Debian 7.7.0 amd64. Right now my workstation uses w** 7 ultimate 64bit, with one(1) CPU (Core i7-4770K), and 32GB of RAM. I need your help! Before I decide to install it for my upcoming "compute-server" and possibly even my current workstation, I need to confirm with ALL the following: -- 1. According to: https://www.debian.org/ports/amd64/ It appears to me that Debian 7.7.0 amd64 supports up to 64TB of RAM, which is much more than even the 192GB limit for w**. Kindly confirm. 2. According to: https://www.gnu.org/philosophy/ubuntu-spyware.html It appears to me that some GNU OS has this annoying problem, how about Debian 7.7.0 amd64? 3. According to: https://www.gnu.org/distros/common-distros.html It appears to me than some of the features in the firmware/repository are not free. Therefore, during installation of Debian 7.7.0 amd64, a. "the installer in some cases recommends these nonfree firmware files for the peripherals on the machine." Will I be given the choice not to install those nonfree features? b. If I do so, i. Will it affect the performance of the OS? ii. Will the maximum supporting RAM remains 64TB? iii. Will I still benefit from ALL advantages amd64 offers, as stated in "A complete 64bit userland" of site https://www.debian.org/ports/amd64/? 4. According to http://cdimage.debian.org/debian-cd/7.7.0/amd64/iso-dvd/ , There are 5 isos (which I am downloading) "Debian-7.7.0-amd64-DVD-1.iso 2014-10-18 15:39 3.7G " "Debian-7.7.0-amd64-DVD-2.iso 2014-10-18 15:39 4.4G " "Debian-7.7.0-amd64-DVD-3.iso 2014-10-18 15:39 4.4G " "Debian-update-7.7.0-amd64-DVD-1.iso 2014-10-19 02:16 4.2G " "Debian-update-7.7.0-amd64-DVD-2.iso 2014-10-19 02:19 1.6G " Which of them is/are mandatory for installation of Debian 7.7.0 amd64? (Note: Please do NOT direct me to the net-installer! I need a robust DVD file than enables me to install it offline! Moreover, this compute-server may not be connected to the internet) 5. Some Server OS (such as w** server standard), supports only few (e.g. less than 4) CPUs. Some others (such as w****** server datacenter), supports "infinite" CPUs. So how about Debian 7.7.0 amd64? -- Hope to hear from you soon. Regards Quek
Re: Fwd: Fwd: module nvidia not found / amd64 jessie
Thanks. It seems that, although suspected, I missed to investigate whether there is a broken relevant package. It would be useful to users of testing knowing how to do that. thanks again francesco pietra On Fri, Nov 14, 2014 at 9:37 AM, Steffen Grunewald < steffen.grunew...@aei.mpg.de> wrote: > On Fri, Nov 14, 2014 at 07:35:43AM +, Francesco Pietra wrote: > > # nvidia-smi -L > > bash: nvidia-smi: command not found > > > > # nvidia-smi > > bash: nvidia-smi: command not found > > > https://packages.debian.org/search?suite=all&searchon=names&keywords=nvidia-smi > > Jessie still has a broken package -3, the issue is supposed to > be fixed in -4 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766343 > > but that didn't migrate due to the freeze... > Something that should be resolved soon (the bug is tagged "important") > > - S >
Re: Fwd: Fwd: module nvidia not found / amd64 jessie
On Fri, Nov 14, 2014 at 07:35:43AM +, Francesco Pietra wrote: > # nvidia-smi -L > bash: nvidia-smi: command not found > > # nvidia-smi > bash: nvidia-smi: command not found https://packages.debian.org/search?suite=all&searchon=names&keywords=nvidia-smi Jessie still has a broken package -3, the issue is supposed to be fixed in -4 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766343 but that didn't migrate due to the freeze... Something that should be resolved soon (the bug is tagged "important") - S -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141114083751.gn30...@casco.aei.mpg.de
Fwd: Fwd: module nvidia not found / amd64 jessie
# nvidia-smi -L bash: nvidia-smi: command not found # nvidia-smi bash: nvidia-smi: command not found -- Forwarded message -- From: Francesco Pietra Date: Fri, Nov 14, 2014 at 7:33 AM Subject: Re: Fwd: module nvidia not found / amd64 jessie To: Lennart Sorensen Cc: amd64 Debian lsmod |grep nvidia nvidia 10503579 44 drm 249955 4 nvidia i2c_core 46012 3 drm,i2c_i801,nvidia However, the command to activate the GPUs does not work because bash does not recognize "nvidia-smi". At this point I wonder whether this is a problem of the terminal rather than of nvidia. francesco On Thu, Nov 13, 2014 at 10:27 PM, Lennart Sorensen < lsore...@csclub.uwaterloo.ca> wrote: > On Thu, Nov 13, 2014 at 04:33:26PM +, Francesco Pietra wrote: > > Sorry, I forgot: > > > > $ dpkg -s linux-headers-$(uname -r) > > Package: linux-headers-3.16.0-4-amd64 > > Status: install ok installed > > Priority: optional > > Section: kernel > > Installed-Size: 2235 > > Maintainer: Debian Kernel Team > > Architecture: amd64 > > Source: linux > > Version: 3.16.7-2 > > Depends: linux-headers-3.16.0-4-common (= 3.16.7-2), linux-kbuild-3.16, > > linux-compiler-gcc-4.8-x86 > > Description: Header files for Linux 3.16.0-4-amd64 > > This package provides the architecture-specific kernel header files for > > Linux kernel 3.16.0-4-amd64, generally used for building out-of-tree > > kernel modules. These files are going to be installed into > > /usr/src/linux-headers-3.16.0-4-amd64, and can be used for building > > modules that load into the kernel provided by the > > linux-image-3.16.0-4-amd64 package. > > Homepage: https://www.kernel.org/ > > > > > > I can add that the X-server and web browser are ok > > It seems you have the module. Is it loaded? > > lsmod | grep nvidia > > -- > Len Sorensen >
Re: Fwd: module nvidia not found / amd64 jessie
lsmod |grep nvidia nvidia 10503579 44 drm 249955 4 nvidia i2c_core 46012 3 drm,i2c_i801,nvidia However, the command to activate the GPUs does not work because bash does not recognize "nvidia-smi". At this point I wonder whether this is a problem of the terminal rather than of nvidia. francesco On Thu, Nov 13, 2014 at 10:27 PM, Lennart Sorensen < lsore...@csclub.uwaterloo.ca> wrote: > On Thu, Nov 13, 2014 at 04:33:26PM +, Francesco Pietra wrote: > > Sorry, I forgot: > > > > $ dpkg -s linux-headers-$(uname -r) > > Package: linux-headers-3.16.0-4-amd64 > > Status: install ok installed > > Priority: optional > > Section: kernel > > Installed-Size: 2235 > > Maintainer: Debian Kernel Team > > Architecture: amd64 > > Source: linux > > Version: 3.16.7-2 > > Depends: linux-headers-3.16.0-4-common (= 3.16.7-2), linux-kbuild-3.16, > > linux-compiler-gcc-4.8-x86 > > Description: Header files for Linux 3.16.0-4-amd64 > > This package provides the architecture-specific kernel header files for > > Linux kernel 3.16.0-4-amd64, generally used for building out-of-tree > > kernel modules. These files are going to be installed into > > /usr/src/linux-headers-3.16.0-4-amd64, and can be used for building > > modules that load into the kernel provided by the > > linux-image-3.16.0-4-amd64 package. > > Homepage: https://www.kernel.org/ > > > > > > I can add that the X-server and web browser are ok > > It seems you have the module. Is it loaded? > > lsmod | grep nvidia > > -- > Len Sorensen >
Re: Fwd: module nvidia not found / amd64 jessie
> Nice, but dkms is much less work and appears to have worked. Yes, you are right. Should have told, I use m-a just for checking, if I have installed all necessary packages. DKMS will after it work automatically for me building the modules. Hans -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/10350764.cymspXMgBC@protheus2
Re: Fwd: module nvidia not found / amd64 jessie
On Thu, Nov 13, 2014 at 04:33:26PM +, Francesco Pietra wrote: > Sorry, I forgot: > > $ dpkg -s linux-headers-$(uname -r) > Package: linux-headers-3.16.0-4-amd64 > Status: install ok installed > Priority: optional > Section: kernel > Installed-Size: 2235 > Maintainer: Debian Kernel Team > Architecture: amd64 > Source: linux > Version: 3.16.7-2 > Depends: linux-headers-3.16.0-4-common (= 3.16.7-2), linux-kbuild-3.16, > linux-compiler-gcc-4.8-x86 > Description: Header files for Linux 3.16.0-4-amd64 > This package provides the architecture-specific kernel header files for > Linux kernel 3.16.0-4-amd64, generally used for building out-of-tree > kernel modules. These files are going to be installed into > /usr/src/linux-headers-3.16.0-4-amd64, and can be used for building > modules that load into the kernel provided by the > linux-image-3.16.0-4-amd64 package. > Homepage: https://www.kernel.org/ > > > I can add that the X-server and web browser are ok It seems you have the module. Is it loaded? lsmod | grep nvidia -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141113222738.go24...@csclub.uwaterloo.ca
Re: Fwd: module nvidia not found / amd64 jessie
On Thu, Nov 13, 2014 at 06:10:24PM +0100, Hans wrote: > Hi franceso, > > I am checking the necessary packagaes by module-assistant. It is the easiest > way. > > Try it out. Install package "module-assistant" , start with m-a, and then go > through the 4 steps (update, prepare etc.) Nice tool, and is helping much. Nice, but dkms is much less work and appears to have worked. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141113222701.gn24...@csclub.uwaterloo.ca
Re: Fwd: module nvidia not found / amd64 jessie
Hi Hans: >From years I no more use what you suggest, I rather use the automatic system of Debian. It has always worked fine at any update/upgrade/restart, even at pciexpress 3.0, like in my system. Perhaps the testing (jessie) update/upgrade has introduced a temporary bug. If so, other users will claim problems. If not, I do not understand what happened. I do not have another machine with this config. francesco On Thu, Nov 13, 2014 at 6:10 PM, Hans wrote: > Hi franceso, > > I am checking the necessary packagaes by module-assistant. It is the > easiest > way. > > Try it out. Install package "module-assistant" , start with m-a, and then > go > through the 4 steps (update, prepare etc.) Nice tool, and is helping much. > > Good luck > > Hans > > > > > # uname -r > > 3.16.0-4-amd64 > > > > > > is that incorrect? > > > > thanks > > > > francesco > > > -- > To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: https://lists.debian.org/19668697.DcGUzMrqmE@protheus2 > >
Re: Fwd: module nvidia not found / amd64 jessie
Hi franceso, I am checking the necessary packagaes by module-assistant. It is the easiest way. Try it out. Install package "module-assistant" , start with m-a, and then go through the 4 steps (update, prepare etc.) Nice tool, and is helping much. Good luck Hans > > # uname -r > 3.16.0-4-amd64 > > > is that incorrect? > > thanks > > francesco -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/19668697.DcGUzMrqmE@protheus2
Fwd: module nvidia not found / amd64 jessie
Sorry, I forgot: $ dpkg -s linux-headers-$(uname -r) Package: linux-headers-3.16.0-4-amd64 Status: install ok installed Priority: optional Section: kernel Installed-Size: 2235 Maintainer: Debian Kernel Team Architecture: amd64 Source: linux Version: 3.16.7-2 Depends: linux-headers-3.16.0-4-common (= 3.16.7-2), linux-kbuild-3.16, linux-compiler-gcc-4.8-x86 Description: Header files for Linux 3.16.0-4-amd64 This package provides the architecture-specific kernel header files for Linux kernel 3.16.0-4-amd64, generally used for building out-of-tree kernel modules. These files are going to be installed into /usr/src/linux-headers-3.16.0-4-amd64, and can be used for building modules that load into the kernel provided by the linux-image-3.16.0-4-amd64 package. Homepage: https://www.kernel.org/ I can add that the X-server and web browser are ok francesco -- Forwarded message -- From: Francesco Pietra Date: Thu, Nov 13, 2014 at 4:11 PM Subject: Re: module nvidia not found / amd64 jessie To: Lennart Sorensen Cc: amd64 Debian modinfo nvidia-current perhaps? # modinfo nvidia-current filename: /lib/modules/3.16.0-4-amd64/updates/dkms/nvidia-current.ko alias: char-major-195-* version:340.46 supported: external license:NVIDIA alias: pci:v10DEd0E00sv*sd*bc04sc80i00* alias: pci:v10DEd0AA3sv*sd*bc0Bsc40i00* alias: pci:v10DEd*sv*sd*bc03sc02i00* alias: pci:v10DEd*sv*sd*bc03sc00i00* depends:drm,i2c-core vermagic: 3.16.0-4-amd64 SMP mod_unload modversions parm: NVreg_Mobile:int parm: NVreg_ResmanDebugLevel:int parm: NVreg_RmLogonRC:int parm: NVreg_ModifyDeviceFiles:int parm: NVreg_DeviceFileUID:int parm: NVreg_DeviceFileGID:int parm: NVreg_DeviceFileMode:int parm: NVreg_RemapLimit:int parm: NVreg_UpdateMemoryTypes:int parm: NVreg_InitializeSystemMemoryAllocations:int parm: NVreg_UsePageAttributeTable:int parm: NVreg_MapRegistersEarly:int parm: NVreg_RegisterForACPIEvents:int parm: NVreg_CheckPCIConfigSpace:int parm: NVreg_EnablePCIeGen3:int parm: NVreg_EnableMSI:int parm: NVreg_MemoryPoolSize:int parm: NVreg_RegistryDwords:charp parm: NVreg_RmMsg:charp parm: NVreg_AssignGpus:charp # uname -r 3.16.0-4-amd64 is that incorrect? thanks francesco On Thu, Nov 13, 2014 at 3:56 PM, Lennart Sorensen < lsore...@csclub.uwaterloo.ca> wrote: > On Thu, Nov 13, 2014 at 03:27:26PM +, Francesco Pietra wrote: > > Hello: > > > > Following update/upgrade with amd64 jessie, the 2 GTX 680 are seen by the > > graphical package VMD, however, "nvidia -smi" does not respond. The GTX > are > > used in the absence of X-server, for number crunching. > > > > I rerun upgrading at no help. > > > > # modinfo nvidia > > ERROR: module nvidia not found > > modinfo nvidia-current perhaps? > > Do you have linux-headers-`uname -r` installed (as in matching your > current kernel)? If not, you won't have a module built. > > -- > Len Sorensen > > > # dpkg -l | grep nvidia > > root@gig64:/home/francesco# dpkg -l | grep nvidia > > ii glx-alternative-nvidia 0.5.1 > > amd64allows the selection of NVIDIA as GLX provider > > ii libegl1-nvidia:amd64 340.46-3 > > amd64NVIDIA binary EGL libraries > > ii libgl1-nvidia-glx:amd64 340.46-3 > > amd64NVIDIA binary OpenGL libraries > > ii libnvidia-compiler:amd64 340.46-3 > > amd64NVIDIA runtime compiler library > > ii libnvidia-eglcore:amd64 340.46-3 > > amd64NVIDIA binary EGL core libraries > > ii libnvidia-ml1:amd64 340.46-3 > > amd64NVIDIA Management Library (NVML) runtime library > > ii nvidia-alternative340.46-3 > > amd64allows the selection of NVIDIA as GLX provider > > ii nvidia-cuda-dev 6.0.37-4 > > amd64NVIDIA CUDA development files > > ii nvidia-cuda-doc 6.0.37-4 > > all NVIDIA CUDA and OpenCL documentation > > ii nvidia-cuda-gdb 6.0.37-4 > > amd64NVIDIA CUDA Debugger (GDB) > > ii nvidia-cuda-toolkit 6.0.37-4 > > amd64NVIDIA CUDA development toolkit > > ii nvidia-detect 340.46-3 > > amd64NVIDIA GPU detection utility > > ii nvidia-driver 340.46-3 > > amd64NVIDIA metapackage > > ii nvidia-installer-cleanup
Re: module nvidia not found / amd64 jessie
> > modinfo nvidia-current perhaps? # modinfo nvidia-current filename: /lib/modules/3.16.0-4-amd64/updates/dkms/nvidia-current.ko alias: char-major-195-* version:340.46 supported: external license:NVIDIA alias: pci:v10DEd0E00sv*sd*bc04sc80i00* alias: pci:v10DEd0AA3sv*sd*bc0Bsc40i00* alias: pci:v10DEd*sv*sd*bc03sc02i00* alias: pci:v10DEd*sv*sd*bc03sc00i00* depends:drm,i2c-core vermagic: 3.16.0-4-amd64 SMP mod_unload modversions parm: NVreg_Mobile:int parm: NVreg_ResmanDebugLevel:int parm: NVreg_RmLogonRC:int parm: NVreg_ModifyDeviceFiles:int parm: NVreg_DeviceFileUID:int parm: NVreg_DeviceFileGID:int parm: NVreg_DeviceFileMode:int parm: NVreg_RemapLimit:int parm: NVreg_UpdateMemoryTypes:int parm: NVreg_InitializeSystemMemoryAllocations:int parm: NVreg_UsePageAttributeTable:int parm: NVreg_MapRegistersEarly:int parm: NVreg_RegisterForACPIEvents:int parm: NVreg_CheckPCIConfigSpace:int parm: NVreg_EnablePCIeGen3:int parm: NVreg_EnableMSI:int parm: NVreg_MemoryPoolSize:int parm: NVreg_RegistryDwords:charp parm: NVreg_RmMsg:charp parm: NVreg_AssignGpus:charp # uname -r 3.16.0-4-amd64 is that incorrect? thanks francesco On Thu, Nov 13, 2014 at 3:56 PM, Lennart Sorensen < lsore...@csclub.uwaterloo.ca> wrote: > On Thu, Nov 13, 2014 at 03:27:26PM +, Francesco Pietra wrote: > > Hello: > > > > Following update/upgrade with amd64 jessie, the 2 GTX 680 are seen by the > > graphical package VMD, however, "nvidia -smi" does not respond. The GTX > are > > used in the absence of X-server, for number crunching. > > > > I rerun upgrading at no help. > > > > # modinfo nvidia > > ERROR: module nvidia not found > > modinfo nvidia-current perhaps? > > Do you have linux-headers-`uname -r` installed (as in matching your > current kernel)? If not, you won't have a module built. > > -- > Len Sorensen > > > # dpkg -l | grep nvidia > > root@gig64:/home/francesco# dpkg -l | grep nvidia > > ii glx-alternative-nvidia 0.5.1 > > amd64allows the selection of NVIDIA as GLX provider > > ii libegl1-nvidia:amd64 340.46-3 > > amd64NVIDIA binary EGL libraries > > ii libgl1-nvidia-glx:amd64 340.46-3 > > amd64NVIDIA binary OpenGL libraries > > ii libnvidia-compiler:amd64 340.46-3 > > amd64NVIDIA runtime compiler library > > ii libnvidia-eglcore:amd64 340.46-3 > > amd64NVIDIA binary EGL core libraries > > ii libnvidia-ml1:amd64 340.46-3 > > amd64NVIDIA Management Library (NVML) runtime library > > ii nvidia-alternative340.46-3 > > amd64allows the selection of NVIDIA as GLX provider > > ii nvidia-cuda-dev 6.0.37-4 > > amd64NVIDIA CUDA development files > > ii nvidia-cuda-doc 6.0.37-4 > > all NVIDIA CUDA and OpenCL documentation > > ii nvidia-cuda-gdb 6.0.37-4 > > amd64NVIDIA CUDA Debugger (GDB) > > ii nvidia-cuda-toolkit 6.0.37-4 > > amd64NVIDIA CUDA development toolkit > > ii nvidia-detect 340.46-3 > > amd64NVIDIA GPU detection utility > > ii nvidia-driver 340.46-3 > > amd64NVIDIA metapackage > > ii nvidia-installer-cleanup 20131102+2 > > amd64cleanup after driver installation with the nvidia-installer > > ii nvidia-kernel-common 20131102+2 > > amd64NVIDIA binary kernel module support files > > ii nvidia-kernel-dkms340.46-3 > > amd64NVIDIA binary kernel module DKMS source > > ii nvidia-libopencl1:amd64 340.46-3 > > amd64 NVIDIA OpenCL ICD Loader library > > ii nvidia-modprobe 340.46-1 > > amd64utility to load NVIDIA kernel modules and create device > nodes > > ii nvidia-opencl-common 340.46-3 > > amd64NVIDIA OpenCL driver > > ii nvidia-opencl-dev:amd64 6.0.37-4 > > amd64NVIDIA OpenCL development files > > ii nvidia-opencl-icd:amd64 340.46-3 > > amd64NVIDIA OpenCL installable client driver (ICD) > > ii nvidia-profiler 6.0.37-4 > > amd6
Re: module nvidia not found / amd64 jessie
On Thu, Nov 13, 2014 at 03:27:26PM +, Francesco Pietra wrote: > Hello: > > Following update/upgrade with amd64 jessie, the 2 GTX 680 are seen by the > graphical package VMD, however, "nvidia -smi" does not respond. The GTX are > used in the absence of X-server, for number crunching. > > I rerun upgrading at no help. > > # modinfo nvidia > ERROR: module nvidia not found modinfo nvidia-current perhaps? Do you have linux-headers-`uname -r` installed (as in matching your current kernel)? If not, you won't have a module built. -- Len Sorensen > # dpkg -l | grep nvidia > root@gig64:/home/francesco# dpkg -l | grep nvidia > ii glx-alternative-nvidia0.5.1 > amd64allows the selection of NVIDIA as GLX provider > ii libegl1-nvidia:amd64 340.46-3 > amd64NVIDIA binary EGL libraries > ii libgl1-nvidia-glx:amd64 340.46-3 > amd64NVIDIA binary OpenGL libraries > ii libnvidia-compiler:amd64 340.46-3 > amd64NVIDIA runtime compiler library > ii libnvidia-eglcore:amd64 340.46-3 > amd64NVIDIA binary EGL core libraries > ii libnvidia-ml1:amd64 340.46-3 > amd64NVIDIA Management Library (NVML) runtime library > ii nvidia-alternative340.46-3 > amd64allows the selection of NVIDIA as GLX provider > ii nvidia-cuda-dev 6.0.37-4 > amd64NVIDIA CUDA development files > ii nvidia-cuda-doc 6.0.37-4 > all NVIDIA CUDA and OpenCL documentation > ii nvidia-cuda-gdb 6.0.37-4 > amd64NVIDIA CUDA Debugger (GDB) > ii nvidia-cuda-toolkit 6.0.37-4 > amd64NVIDIA CUDA development toolkit > ii nvidia-detect 340.46-3 > amd64NVIDIA GPU detection utility > ii nvidia-driver 340.46-3 > amd64NVIDIA metapackage > ii nvidia-installer-cleanup 20131102+2 > amd64cleanup after driver installation with the nvidia-installer > ii nvidia-kernel-common 20131102+2 > amd64NVIDIA binary kernel module support files > ii nvidia-kernel-dkms 340.46-3 > amd64NVIDIA binary kernel module DKMS source > ii nvidia-libopencl1:amd64 340.46-3 > amd64NVIDIA OpenCL ICD Loader library > ii nvidia-modprobe 340.46-1 > amd64utility to load NVIDIA kernel modules and create device nodes > ii nvidia-opencl-common 340.46-3 > amd64NVIDIA OpenCL driver > ii nvidia-opencl-dev:amd64 6.0.37-4 > amd64NVIDIA OpenCL development files > ii nvidia-opencl-icd:amd64 340.46-3 > amd64NVIDIA OpenCL installable client driver (ICD) > ii nvidia-profiler 6.0.37-4 > amd64NVIDIA Profiler for CUDA and OpenCL > ii nvidia-settings 340.46-2 > amd64tool for configuring the NVIDIA graphics driver > ii nvidia-smi340.46-3 > amd64NVIDIA System Management Interface > ii nvidia-support20131102+2 > amd64NVIDIA binary graphics driver support files > ii nvidia-vdpau-driver:amd64 340.46-3 > amd64Video Decode and Presentation API for Unix - NVIDIA driver > ii nvidia-visual-profiler6.0.37-4 > amd64NVIDIA Visual Profiler for CUDA and OpenCL > ii nvidia-xconfig340.46-1 > amd64X configuration tool for non-free NVIDIA drivers > ii xserver-xorg-video-nvidia 340.46-3 > amd64NVIDIA binary Xorg driver > root@gig64:/home/francesco# > > I can't remember which nvidia driver was operating before these problems. > > # uname -a > 3.16-3-amd64 #1 SMP Debian 3.16.5-1 x86 64 > > cpu family : 6 > model : 62 > model name : Intel(R) Core(TM) i7-4930K CPU @ 3.40GHz > stepping : 4 > microcode : 0x416 > cpu MHz : 1237.546 > cache size : 12288 KB > > > Thanks for advice > > francesco pietra -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141113155628.gm24...@csclub.uwaterloo.ca
Fwd: module nvidia not found / amd64 jessie
As all packages seem to be installed, I wonder whether attention should be paid to the message by the graphical VMD, while detecting the two GTX 680: CUDA error: invalid device symbol, CUDAClearDevice.cu line 62 fp -- Forwarded message -- From: Francesco Pietra Date: Thu, Nov 13, 2014 at 4:27 PM Subject: module nvidia not found / amd64 jessie To: amd64 Debian Hello: Following update/upgrade with amd64 jessie, the 2 GTX 680 are seen by the graphical package VMD, however, "nvidia -smi" does not respond. The GTX are used in the absence of X-server, for number crunching. I rerun upgrading at no help. # modinfo nvidia ERROR: module nvidia not found # dpkg -l | grep nvidia root@gig64:/home/francesco# dpkg -l | grep nvidia ii glx-alternative-nvidia0.5.1 amd64allows the selection of NVIDIA as GLX provider ii libegl1-nvidia:amd64 340.46-3 amd64NVIDIA binary EGL libraries ii libgl1-nvidia-glx:amd64 340.46-3 amd64NVIDIA binary OpenGL libraries ii libnvidia-compiler:amd64 340.46-3 amd64NVIDIA runtime compiler library ii libnvidia-eglcore:amd64 340.46-3 amd64NVIDIA binary EGL core libraries ii libnvidia-ml1:amd64 340.46-3 amd64NVIDIA Management Library (NVML) runtime library ii nvidia-alternative340.46-3 amd64allows the selection of NVIDIA as GLX provider ii nvidia-cuda-dev 6.0.37-4 amd64NVIDIA CUDA development files ii nvidia-cuda-doc 6.0.37-4 all NVIDIA CUDA and OpenCL documentation ii nvidia-cuda-gdb 6.0.37-4 amd64NVIDIA CUDA Debugger (GDB) ii nvidia-cuda-toolkit 6.0.37-4 amd64NVIDIA CUDA development toolkit ii nvidia-detect 340.46-3 amd64NVIDIA GPU detection utility ii nvidia-driver 340.46-3 amd64NVIDIA metapackage ii nvidia-installer-cleanup 20131102+2 amd64cleanup after driver installation with the nvidia-installer ii nvidia-kernel-common 20131102+2 amd64NVIDIA binary kernel module support files ii nvidia-kernel-dkms340.46-3 amd64NVIDIA binary kernel module DKMS source ii nvidia-libopencl1:amd64 340.46-3 amd64NVIDIA OpenCL ICD Loader library ii nvidia-modprobe 340.46-1 amd64utility to load NVIDIA kernel modules and create device nodes ii nvidia-opencl-common 340.46-3 amd64NVIDIA OpenCL driver ii nvidia-opencl-dev:amd64 6.0.37-4 amd64NVIDIA OpenCL development files ii nvidia-opencl-icd:amd64 340.46-3 amd64NVIDIA OpenCL installable client driver (ICD) ii nvidia-profiler 6.0.37-4 amd64NVIDIA Profiler for CUDA and OpenCL ii nvidia-settings 340.46-2 amd64tool for configuring the NVIDIA graphics driver ii nvidia-smi340.46-3 amd64NVIDIA System Management Interface ii nvidia-support20131102+2 amd64NVIDIA binary graphics driver support files ii nvidia-vdpau-driver:amd64 340.46-3 amd64Video Decode and Presentation API for Unix - NVIDIA driver ii nvidia-visual-profiler6.0.37-4 amd64NVIDIA Visual Profiler for CUDA and OpenCL ii nvidia-xconfig340.46-1 amd64X configuration tool for non-free NVIDIA drivers ii xserver-xorg-video-nvidia 340.46-3 amd64NVIDIA binary Xorg driver root@gig64:/home/francesco# I can't remember which nvidia driver was operating before these problems. # uname -a 3.16-3-amd64 #1 SMP Debian 3.16.5-1 x86 64 cpu family : 6 model : 62 model name : Intel(R) Core(TM) i7-4930K CPU @ 3.40GHz stepping : 4 microcode : 0x416 cpu MHz : 1237.546 cache size : 12288 KB Thanks for advice francesco pietra
module nvidia not found / amd64 jessie
Hello: Following update/upgrade with amd64 jessie, the 2 GTX 680 are seen by the graphical package VMD, however, "nvidia -smi" does not respond. The GTX are used in the absence of X-server, for number crunching. I rerun upgrading at no help. # modinfo nvidia ERROR: module nvidia not found # dpkg -l | grep nvidia root@gig64:/home/francesco# dpkg -l | grep nvidia ii glx-alternative-nvidia0.5.1 amd64allows the selection of NVIDIA as GLX provider ii libegl1-nvidia:amd64 340.46-3 amd64NVIDIA binary EGL libraries ii libgl1-nvidia-glx:amd64 340.46-3 amd64NVIDIA binary OpenGL libraries ii libnvidia-compiler:amd64 340.46-3 amd64NVIDIA runtime compiler library ii libnvidia-eglcore:amd64 340.46-3 amd64NVIDIA binary EGL core libraries ii libnvidia-ml1:amd64 340.46-3 amd64NVIDIA Management Library (NVML) runtime library ii nvidia-alternative340.46-3 amd64allows the selection of NVIDIA as GLX provider ii nvidia-cuda-dev 6.0.37-4 amd64NVIDIA CUDA development files ii nvidia-cuda-doc 6.0.37-4 all NVIDIA CUDA and OpenCL documentation ii nvidia-cuda-gdb 6.0.37-4 amd64NVIDIA CUDA Debugger (GDB) ii nvidia-cuda-toolkit 6.0.37-4 amd64NVIDIA CUDA development toolkit ii nvidia-detect 340.46-3 amd64NVIDIA GPU detection utility ii nvidia-driver 340.46-3 amd64NVIDIA metapackage ii nvidia-installer-cleanup 20131102+2 amd64cleanup after driver installation with the nvidia-installer ii nvidia-kernel-common 20131102+2 amd64NVIDIA binary kernel module support files ii nvidia-kernel-dkms340.46-3 amd64NVIDIA binary kernel module DKMS source ii nvidia-libopencl1:amd64 340.46-3 amd64NVIDIA OpenCL ICD Loader library ii nvidia-modprobe 340.46-1 amd64utility to load NVIDIA kernel modules and create device nodes ii nvidia-opencl-common 340.46-3 amd64NVIDIA OpenCL driver ii nvidia-opencl-dev:amd64 6.0.37-4 amd64NVIDIA OpenCL development files ii nvidia-opencl-icd:amd64 340.46-3 amd64NVIDIA OpenCL installable client driver (ICD) ii nvidia-profiler 6.0.37-4 amd64NVIDIA Profiler for CUDA and OpenCL ii nvidia-settings 340.46-2 amd64tool for configuring the NVIDIA graphics driver ii nvidia-smi340.46-3 amd64NVIDIA System Management Interface ii nvidia-support20131102+2 amd64NVIDIA binary graphics driver support files ii nvidia-vdpau-driver:amd64 340.46-3 amd64Video Decode and Presentation API for Unix - NVIDIA driver ii nvidia-visual-profiler6.0.37-4 amd64NVIDIA Visual Profiler for CUDA and OpenCL ii nvidia-xconfig340.46-1 amd64X configuration tool for non-free NVIDIA drivers ii xserver-xorg-video-nvidia 340.46-3 amd64NVIDIA binary Xorg driver root@gig64:/home/francesco# I can't remember which nvidia driver was operating before these problems. # uname -a 3.16-3-amd64 #1 SMP Debian 3.16.5-1 x86 64 cpu family : 6 model : 62 model name : Intel(R) Core(TM) i7-4930K CPU @ 3.40GHz stepping : 4 microcode : 0x416 cpu MHz : 1237.546 cache size : 12288 KB Thanks for advice francesco pietra
Re: new software if moving to amd64?
On 5 October 2014 16:21, Lennart Sorensen wrote: > I see no reason for it to fuse given multiarch works now. I expect > people to have amd64/x32 multiarch systems though since the majority > of programs don't need a 64bit memory space so you would gain smaller > binaries and less cache usage due to the smaller pointers. The kernel > would obviously be 64bit. For those few programs that have a use for > 64bit memory space, yo would use amd64 packages. > > Essentially I think it makes sense to run 64bit kernel, with x32 as the > default and amd64 for select applications, and perhaps i386 for the few > things that can't be bothered to upgrade away from old 32bit. > I would observe that AIX took a similar path to this; the typical application that doesn't need a large memory space operates in 32 bit mode, but specific apps would be compiled with 64 bit options. The set of applications that need to be "64 bit capable" tends to grow, alas. It gets quite annoying if cat/awk/sed/tail/sort/tar "blow up" upon receiving large inputs, particularly if you've got plenty of RAM to cope with the data. Things may work out fine given APIs that can cope with large files (there was an API designed for that, of course!), but I'll bet there will be surprising cases. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
Re: new software if moving to amd64?
Lennart, Thanks for the comment. Actually, until you mentioned it, i wasn't even aware of x32, but its existence answers a lot of questions i had since long :) -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141006012759.43715...@mirrors.kernel.org
Re: new software if moving to amd64?
On Sun, Oct 05, 2014 at 10:12:18PM +0200, Michael wrote: > Lennart, > > What do you think, chances does X32 have ? Will this be, like, fused, into > AMD64 compilers some day ? I see no reason for it to fuse given multiarch works now. I expect people to have amd64/x32 multiarch systems though since the majority of programs don't need a 64bit memory space so you would gain smaller binaries and less cache usage due to the smaller pointers. The kernel would obviously be 64bit. For those few programs that have a use for 64bit memory space, yo would use amd64 packages. Essentially I think it makes sense to run 64bit kernel, with x32 as the default and amd64 for select applications, and perhaps i386 for the few things that can't be bothered to upgrade away from old 32bit. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141005202149.gt4...@csclub.uwaterloo.ca
Re: new software if moving to amd64?
Lennart, What do you think, chances does X32 have ? Will this be, like, fused, into AMD64 compilers some day ? -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141005221218.5ba34...@mirrors.kernel.org
Re: new software if moving to amd64?
On 10/05/2014 10:12 AM, Lennart Sorensen wrote: Interesting. So that would be another flavour of package again? (not 'i386' not 'amd64', but something else?) The flavour is x32. It is not done yet though. https://wiki.debian.org/X32Port Kewl. I'll keep an eye on that. Better stay with i386 for now tho, I don't have the bones for any converting. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54319a31.5010...@eastlink.ca
Re: new software if moving to amd64?
On Sun, Oct 05, 2014 at 07:59:17AM -0700, Ray Andrews wrote: > On 10/04/2014 07:03 PM, Lennart Sorensen wrote: > > Lennart, > >The best option will actually end up being x32 (which is 32bit > >programs using the 64bit cpu so you get all the new registers and > >SSE floating point, but without the pointer overhead). Not sure > >how far along x32 is at this point. > Interesting. So that would be another flavour of package again? > (not 'i386' not 'amd64', but something else?) The flavour is x32. It is not done yet though. https://wiki.debian.org/X32Port -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141005171221.gs4...@csclub.uwaterloo.ca
Re: new software if moving to amd64?
On 10/04/2014 07:03 PM, Lennart Sorensen wrote: Lennart, The best option will actually end up being x32 (which is 32bit programs using the 64bit cpu so you get all the new registers and SSE floating point, but without the pointer overhead). Not sure how far along x32 is at this point. Interesting. So that would be another flavour of package again? (not 'i386' not 'amd64', but something else?) -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54315cc5.2020...@eastlink.ca
Re: new software if moving to amd64?
On Fri, Oct 03, 2014 at 02:45:59PM -0700, Ray Andrews wrote: > Ok thanks, that's a good start right there. Looking at various > blogs and such, it seems no two people can agree if the conversion > to '64 is beneficial or even wise. I have only 2 GB of RAM on this > machine, so that's no motive. I hear talk of various problems on > the one hand, vs. claims of better performance on the other. Can I > sorta slide from '32 to '64 by degrees? I mean, so that whenever I > do an upgrade it will convert what's convertible while leaving the > rest of the system '32? Or should I start afresh? Or should I just > leave this older machine alone? 64bit has twice the registers than 32bit in the case of x86, so some programs gain some performance that way. Also 64bit always uses SSE for floating point, while 32bit by default uses x87 floating point which is a lot slower. Now 64bit does have some overhead due to the pointers being twice as big, which means more cache use and memory bandwidth, although probably not that much in general. The best option will actually end up being x32 (which is 32bit programs using the 64bit cpu so you get all the new registers and SSE floating point, but without the pointer overhead). Not sure how far along x32 is at this point. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141005020355.gq4...@csclub.uwaterloo.ca
Re: new software if moving to amd64?
On 10/04/2014 02:45 AM, Michael wrote: Micha, Thanks very much for that, it was exactly the sort of grandfatherly advice that I was looking for. It would be nice if there was a Debian doc saying just what you said (not so much 'how' but 'why' to convert to amd64). It does seem that, with 2GB of RAM, there is little reason for me to jump in right now. I think I'll spend my time over the winter digging into zsh. Still, one might wish for some handy-dandy 'converter' script so that, if one was migrating an existing system to a more powerful machine, it could be done withl a minimum of agony. Our friendly competitor have a not so bad overview for beginners on these pages http://windows.microsoft.com/en-us/windows7/taking-the-mystery-out-of-64-bit-windows Superbly written. Ray -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/542ffbf4.1030...@eastlink.ca
Re: new software if moving to amd64?
Ray, Well. Having done a lot of (kindly) support for older machines, i'd say leave the arch as is. While on the other hand it's fun to upgrade to a decent GNU/Linux version (a friend once said Linux is the greatest online adventure ever) so if you are bored, give it a shot :) but that does not imply to change the architecture. The problem is just the 'fiddling' which consumes your time for nothing. Plus, multiarch (mixed i366 and amd64 packages) in reality is not that easily done as said. In my case, when i tried to set up google earth 32 bit (in a native 64bit env), it finally ends up to move most (or all?) of the installation to 32 bit. Well, it still works, but at least looks ugly in the package manager :) and i'm sure the respective package dependencies could be resolved differently, but i won't blame the maintainers. It's just a lot of work, on all ends, to make it real, and the tiny word 'work' resembles the huge problem, paid or not. There is one feature of Windows 7 that struck me though i did not really dive into it ... when a software does not launch or work properly, the Windows OS tries to identify and solve the problem, for example by switching to 'Windows XP mode' where 32 bit apps run in an emulation environment. Maybe they chose the safe bet, i can't tell, especially since Windows always makes a big fuzz over solutions to problems that should not exist in the first place. http://windows.microsoft.com/en-us/windows7/understanding-hardware-and-software-for-64-bit-windows Our friendly competitor have a not so bad overview for beginners on these pages http://windows.microsoft.com/en-us/windows7/taking-the-mystery-out-of-64-bit-windows There are very few GNU/Linux apps which in the past were available only in 32 bit packages, proprietary things like google-earth and maybe skype, meaning you'd need the debian multiarch feature. Meanwhile those issues could or should be solved, but still, there's no guarantee since those the props usually do not have significant GNU/Linux support on their end. Yet i'm running googleearth right now and the debian maintainer even tries to upgrade to ge7. https://plus.google.com/+AdnanHodzic/posts/g2JyQ93ej51 As for the gain of 64 vs 32 bit, one should ask how urgent are high performance tasks on the respective computer. This is not totally trivial even if you're only doing some office and internet, because most people at least want smooth movies and a graphical desktop. Besides the CPU, also the GPU is involved. I imagine that typical GPU tasks involve massive parallel computing and other stuff that possibly could profit from 64bit. Please don't nail me down on this, i really don't know much about, but i wonder if the 32/64 bit question is just the same for GPUs. Maybe someone can enlighten me. ps. It seems there is http://www.nvidia.com/object/feature_64-bit.html micha -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141004114520.5348b...@mirrors.kernel.org
Re: new software if moving to amd64?
On 10/03/2014 11:20 AM, Lennart Sorensen wrote: On Fri, Oct 03, 2014 at 08:38:51AM -0700, Ray Andrews wrote: I just upgraded to the 'amd64' kernel. I've always been a 32 bit lad up till now. The kernel runs fine, but I'm wondering if there is anything else to do, specifically if my software needs to be somehow changed from 32 bit to 64 bit. There seems to be no special repository for 64 bit. Or am I all good? So this is 'crossgrading' I see. Seems like a bit of a nightmare. I followed one set of instructions and it totally screwed things up. Fully backed up, tho. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/542f5a23.5010...@eastlink.ca
Re: new software if moving to amd64?
On 10/03/2014 11:20 AM, Lennart Sorensen wrote: On Fri, Oct 03, 2014 at 08:38:51AM -0700, Ray Andrews wrote: Gentlemen, Are you sure that is always true? Sure I may be, but not everyone on the list is likely to be. Mere, vulgar flattery ;-) I just upgraded to the 'amd64' kernel. I've always been a 32 bit lad up till now. The kernel runs fine, but I'm wondering if there is anything else to do, specifically if my software needs to be somehow changed from 32 bit to 64 bit. There seems to be no special repository for 64 bit. Or am I all good? Well you can run a 64 bit kernel with 32 bit user space. You can even create chroots with debootstrap that are amd64 architecture inside and that works too. Of course with multiarch in wheezy and above you can even install packages from both i386 and amd64 at the same time (using apt-get install packagename:architecture), after telling dpkg once to add the other architecture. dpkg has a concept of the default architecture of an installation which was whatever it was installed as initially, although you can change it. The sources.list doesn't change in general, it simply starts downloading all the enabled architectures that you told dpkg to use (using dpkg --add-architecture). Ok thanks, that's a good start right there. Looking at various blogs and such, it seems no two people can agree if the conversion to '64 is beneficial or even wise. I have only 2 GB of RAM on this machine, so that's no motive. I hear talk of various problems on the one hand, vs. claims of better performance on the other. Can I sorta slide from '32 to '64 by degrees? I mean, so that whenever I do an upgrade it will convert what's convertible while leaving the rest of the system '32? Or should I start afresh? Or should I just leave this older machine alone? -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/542f1917.1030...@eastlink.ca
Re: new software if moving to amd64?
On Fri, Oct 03, 2014 at 08:38:51AM -0700, Ray Andrews wrote: > Gentlemen, Are you sure that is always true? Sure I may be, but not everyone on the list is likely to be. > I just upgraded to the 'amd64' kernel. I've always been a 32 bit > lad up till now. The kernel runs fine, but I'm wondering if there is > anything else to do, specifically if my software needs to be > somehow changed from 32 bit to 64 bit. There seems to be no special > repository for 64 bit. Or am I all good? Well you can run a 64 bit kernel with 32 bit user space. You can even create chroots with debootstrap that are amd64 architecture inside and that works too. Of course with multiarch in wheezy and above you can even install packages from both i386 and amd64 at the same time (using apt-get install packagename:architecture), after telling dpkg once to add the other architecture. dpkg has a concept of the default architecture of an installation which was whatever it was installed as initially, although you can change it. The sources.list doesn't change in general, it simply starts downloading all the enabled architectures that you told dpkg to use (using dpkg --add-architecture). -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141003182048.gp4...@csclub.uwaterloo.ca
new software if moving to amd64?
Gentlemen, I just upgraded to the 'amd64' kernel. I've always been a 32 bit lad up till now. The kernel runs fine, but I'm wondering if there is anything else to do, specifically if my software needs to be somehow changed from 32 bit to 64 bit. There seems to be no special repository for 64 bit. Or am I all good? Thanks -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/542ec30b.7060...@eastlink.ca
Fwd: nvidia cuda driver for PCIe 3.0 with amd64
To set my question more specifically, does upgrading from amd64 wheezy to amd64 jessie bring a nvidia driver capable of PCIexpress 3.0 with ivy bridge? If so, is update/upgrade enough or a suitable kernel should also be installed? By using distupgrade I had unpleasant experience in the past, of a huge variety of applications installed, when my interest is totally out of graphic interfaces, which can not be used for MD with GPUs. Thank so much. It is a pity to run MD with GPUs at the rate allowed by PCIe 2.0, when the hardware should allow PCIe 3.0 (eight vs five) Cheers francesco pietra -- Forwarded message -- From: "Francesco Pietra" Date: Nov 10, 2013 7:42 AM Subject: nvidia cuda driver for PCIe 3.0 with amd64 To: "amd64 Debian" Cc: Hello In motherboard Gigabyte X79-UD3 I have replaced sandy i7-3930 with ivy i7-4930K (and increased RAM speed to 1866MHz) in view of activating PCIe 3.0 between RAM and the two GTX-680 cards, both on 16 lanes. As expected at current cuda driver 304.88 with amd64 wheezy, there was no speed increase in executing parallelized molecular dynamics (NAMD2.9 code, compiled at cuda 4, and running without the X-server). Both GPUs are working correctly, each one sharing the parts of the protein assigned to them by the code, both GPUs engaging the same amount of memory. As far as I know, nvidia PCIe 3.0 worked with 295.33 drivers under linux, but then nvidia disabled it from 295.xx to (at least) 310.xx. What could I do now to get PDCIe 3.0? (a) Upgrading to testing, if it is true that nvidia cuda drivers there (331.xx I believe) enable PCIe 3.0. This would not be the best for me in view of stability. (b) Backporting testing nvidia drivers to wheezy. Is that possible? Thanks for advice francesco pietra PS: in carrying out the above benchmark, which is provided by NAMD itself, I selected both a light job (small protein) and a very heavy job (large protein in much water). Only in the latter case, the new ivy configuration afforded advantage, albeit as marginal as 0.12 s/step instead of 0.14 s/step. The higher RAM speed gave no advantage. Clearly, there is a bottleneck between the GPUs and RAM with both the sandy and the ivy hardware at driver 304.xx.
nvidia cuda driver for PCIe 3.0 with amd64
Hello In motherboard Gigabyte X79-UD3 I have replaced sandy i7-3930 with ivy i7-4930K (and increased RAM speed to 1866MHz) in view of activating PCIe 3.0 between RAM and the two GTX-680 cards, both on 16 lanes. As expected at current cuda driver 304.88 with amd64 wheezy, there was no speed increase in executing parallelized molecular dynamics (NAMD2.9 code, compiled at cuda 4, and running without the X-server). Both GPUs are working correctly, each one sharing the parts of the protein assigned to them by the code, both GPUs engaging the same amount of memory. As far as I know, nvidia PCIe 3.0 worked with 295.33 drivers under linux, but then nvidia disabled it from 295.xx to (at least) 310.xx. What could I do now to get PDCIe 3.0? (a) Upgrading to testing, if it is true that nvidia cuda drivers there (331.xx I believe) enable PCIe 3.0. This would not be the best for me in view of stability. (b) Backporting testing nvidia drivers to wheezy. Is that possible? Thanks for advice francesco pietra PS: in carrying out the above benchmark, which is provided by NAMD itself, I selected both a light job (small protein) and a very heavy job (large protein in much water). Only in the latter case, the new ivy configuration afforded advantage, albeit as marginal as 0.12 s/step instead of 0.14 s/step. The higher RAM speed gave no advantage. Clearly, there is a bottleneck between the GPUs and RAM with both the sandy and the ivy hardware at driver 304.xx.
Re: RedHat or Debian amd64
> Well Ubuntu is based on Debian, so there is at least a good chance a > package for ubuntu will work on Debian. > Not on wheezy, because of glibc versions, perhaps on testing. I could install amd64 testing on the desktop (not on servers), which could also solve the problem of grub on both disks of raid0. Does the new installer ask for that option, install grub on both disks? That was not the case some time ago and getting grub on both disks was something that defeated me. I made it know to the maintainers at the center that I was used to stable software for scientific use, and to originals, not derivatives. But these are my personal views, clearly not much shared. Thanks francesco pietra francesco@tya64:~/tmp$ ls RCM_linux2_64bit_Ubuntu_12.04 francesco@tya64:~/tmp$ ./RCM_linux2_64bit_Ubuntu_12.04 Error loading Python lib '/tmp/_MEIzFrUEs/libpython2.7.so.1.0': /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /tmp/_MEIzFrUEs/libpython2.7.so.1.0) Segmentation fault francesco@tya64:~/tmp$ libc.so.6 --version bash: libc.so.6: command not found francesco@tya64:~/tmp$ locate libc.so.6 /lib/x86_64-linux-gnu/libc.so.6 francesco@tya64:~/tmp$ /lib/x86_64-linux-gnu/libc.so.6 GNU C Library (Debian EGLIBC 2.13-38) stable release version 2.13, by Roland McGrath et al. Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.4.7. Compiled on a Linux 3.2.35 system on 2012-12-30. Available extensions: crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B libc ABIs: UNIQUE IFUNC For bug reporting instructions, please see: <http://www.debian.org/Bugs/>. francesco@tya64:~/tmp$ On Mon, Sep 30, 2013 at 4:24 PM, Lennart Sorensen < lsore...@csclub.uwaterloo.ca> wrote: > On Sun, Sep 29, 2013 at 06:45:40PM +0200, Francesco Pietra wrote: > > > > > > Really the only difference between distributions is their packaging > > > system, their support infrastructure, their release schedule/policy, > and > > > how up to date the software is and what software they offer packages > for. > > > > > > Thanks. > > Now my project at the Italian supercomputer center is going to > production. > > I had no problems with RedHat as far as number crunching is concerned. > Now, > > however, I need to access their Remote Visualization service to deal - > also > > on the X server - with large files. To this end, I need to download > > software compatible with Debian amd64. The variety of graphic and > > non-graphic tools that I use is very large. Their 64 bit Linux list > > (lacking any GNU Linux for either 64 or 32 bit) > > > > RCM_darwin > > RCM ubuntu 12.04 > > RCM RHL 5.6 > > RCM openSUSE 11.4 and 12.2 > > > > I would appreciate advice as to which RCM will likely work for me. I > heard > > about ubuntu but, to avoid being flooded by messages, i put it in the > spam. > > The advice I can even from the center is very limited as they don't know > > what I have. > > Well Ubuntu is based on Debian, so there is at least a good chance a > package for ubuntu will work on Debian. > > -- > Len Sorensen >
Re: RedHat or Debian amd64
On Sun, Sep 29, 2013 at 06:45:40PM +0200, Francesco Pietra wrote: > > > > Really the only difference between distributions is their packaging > > system, their support infrastructure, their release schedule/policy, and > > how up to date the software is and what software they offer packages for. > > > Thanks. > Now my project at the Italian supercomputer center is going to production. > I had no problems with RedHat as far as number crunching is concerned. Now, > however, I need to access their Remote Visualization service to deal - also > on the X server - with large files. To this end, I need to download > software compatible with Debian amd64. The variety of graphic and > non-graphic tools that I use is very large. Their 64 bit Linux list > (lacking any GNU Linux for either 64 or 32 bit) > > RCM_darwin > RCM ubuntu 12.04 > RCM RHL 5.6 > RCM openSUSE 11.4 and 12.2 > > I would appreciate advice as to which RCM will likely work for me. I heard > about ubuntu but, to avoid being flooded by messages, i put it in the spam. > The advice I can even from the center is very limited as they don't know > what I have. Well Ubuntu is based on Debian, so there is at least a good chance a package for ubuntu will work on Debian. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130930142433.gx13...@csclub.uwaterloo.ca
Re: RedHat or Debian amd64
> > Really the only difference between distributions is their packaging > system, their support infrastructure, their release schedule/policy, and > how up to date the software is and what software they offer packages for. Thanks. Now my project at the Italian supercomputer center is going to production. I had no problems with RedHat as far as number crunching is concerned. Now, however, I need to access their Remote Visualization service to deal - also on the X server - with large files. To this end, I need to download software compatible with Debian amd64. The variety of graphic and non-graphic tools that I use is very large. Their 64 bit Linux list (lacking any GNU Linux for either 64 or 32 bit) RCM_darwin RCM ubuntu 12.04 RCM RHL 5.6 RCM openSUSE 11.4 and 12.2 I would appreciate advice as to which RCM will likely work for me. I heard about ubuntu but, to avoid being flooded by messages, i put it in the spam. The advice I can even from the center is very limited as they don't know what I have. Thanks francesco pietra On Wed, Jun 26, 2013 at 6:23 PM, Lennart Sorensen < lsore...@csclub.uwaterloo.ca> wrote: > On Wed, Jun 26, 2013 at 06:11:31PM +0200, Francesco Pietra wrote: > > Hi Lennart: > > I forgot that what is found on supercomputers might result also from what > > you say. > > > > I found it problematic to compile a code for molecular dynamics (MD) > > inclusive of an elaborate plugin. Better, I succeeded when only the > > simplest part of the plugin was implemented, getting a valid MD > executable. > > In contrast, implementing the whole plugin resulted in a MD executable > that > > fails to recognize the GTX-680cards of my machine. Calls to the forum for > > both the MD code and the plugin had ho answer. Those of the MD code do > not > > like the plugin (as they have the simplest part of it already hard coded > > their own way), while those of the plugin do not know that MD code, they > > use another one. > > > > Then, I heard that at the supercomputer center of my country (where I > > should run the project, but I need to go there with a system that "runs") > > even GPU machines run that full plugin. Before asking them how they > > succeeded, I was wondering about the different Linux OSs. I am now > curious > > about their answer, if any. > > Really the only difference between distributions is their packaging > system, their support infastructure, their release schedule/policy, and > how up to date the software is and what software they offer packages for. > > -- > Len Sorensen >
Re: RedHat or Debian amd64
RedHat are focusing their product on suiting the needs and idiosyncrasies of companies that 'think' in the 'old iron' mentality. RedHat have moved from being disruptive in the small end of town (start ups, small ISP's etc) to chasing large fortune 500 companies. They have unashamedly shaped their product to suit the market they are pursuing and smaller firms have been left behind. They are disrupting upwards in to banks and other large firms with slow (painful... though that's subjective) processes for getting things done. Often they see an OS as a 'CD' to insert before inserting another vendors software CD. Implementing version numbers scare them enormously and 'backporting' patches then adding yet another minor version number soothes their fears greatly. I am not making any sort of statement as to if this is good or bad, rational or irrational, smart or stupid. Please understand this email as being devoid of any emotion or taking any side - merely an observation. Though its a fascinating example of the "north west" movement a company tends to make - as described in Clayton Christensen's classic 'The Innovators Dilemma' (see http://www.amazon.com/gp/product/0062060244?ie=UTF8&camp=213733&creative=393185&creativeASIN=0062060244&linkCode=shr&tag=frag0f-20&qid=1372293137&sr=8-1&keywords=innovators+dilemma) Dean On 2013-06-27 00:33, Francesco Pietra wrote: Hello: I noticed that in my country supercomputer center all machines, both CPU (FERMI) and GPU (AURORA, PLX) run on RedHat Linux. As a long time user of Debian GNU Linux amd64, I am curious whether such machines elsewhere also run, or could run, on Debian am64. If not, why? A problem of kernel? Thanks francesco pietra -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/b32aeea7267075478f360f0524ff7...@fragfest.com.au
Re: RedHat or Debian amd64
On Wed, Jun 26, 2013 at 06:11:31PM +0200, Francesco Pietra wrote: > Hi Lennart: > I forgot that what is found on supercomputers might result also from what > you say. > > I found it problematic to compile a code for molecular dynamics (MD) > inclusive of an elaborate plugin. Better, I succeeded when only the > simplest part of the plugin was implemented, getting a valid MD executable. > In contrast, implementing the whole plugin resulted in a MD executable that > fails to recognize the GTX-680cards of my machine. Calls to the forum for > both the MD code and the plugin had ho answer. Those of the MD code do not > like the plugin (as they have the simplest part of it already hard coded > their own way), while those of the plugin do not know that MD code, they > use another one. > > Then, I heard that at the supercomputer center of my country (where I > should run the project, but I need to go there with a system that "runs") > even GPU machines run that full plugin. Before asking them how they > succeeded, I was wondering about the different Linux OSs. I am now curious > about their answer, if any. Really the only difference between distributions is their packaging system, their support infastructure, their release schedule/policy, and how up to date the software is and what software they offer packages for. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130626162308.gt11...@csclub.uwaterloo.ca
Re: RedHat or Debian amd64
Hi Lennart: I forgot that what is found on supercomputers might result also from what you say. I found it problematic to compile a code for molecular dynamics (MD) inclusive of an elaborate plugin. Better, I succeeded when only the simplest part of the plugin was implemented, getting a valid MD executable. In contrast, implementing the whole plugin resulted in a MD executable that fails to recognize the GTX-680cards of my machine. Calls to the forum for both the MD code and the plugin had ho answer. Those of the MD code do not like the plugin (as they have the simplest part of it already hard coded their own way), while those of the plugin do not know that MD code, they use another one. Then, I heard that at the supercomputer center of my country (where I should run the project, but I need to go there with a system that "runs") even GPU machines run that full plugin. Before asking them how they succeeded, I was wondering about the different Linux OSs. I am now curious about their answer, if any. thanks and all the best francesco pietra On Wed, Jun 26, 2013 at 4:40 PM, Lennart Sorensen < lsore...@csclub.uwaterloo.ca> wrote: > On Wed, Jun 26, 2013 at 04:33:20PM +0200, Francesco Pietra wrote: > > Hello: > > I noticed that in my country supercomputer center all machines, both CPU > > (FERMI) and GPU (AURORA, PLX) run on RedHat Linux. As a long time user of > > Debian GNU Linux amd64, I am curious whether such machines elsewhere also > > run, or could run, on Debian am64. If not, why? A problem of kernel? > > Some people want someone to blame if there are problems, or to demand > support from if they need something solved right away. Redhat will sell > you support contracts and will solve problems. But you pay for it. > > If you like doing it yourself or to solve things by cooporating with > the community instead, then Debian works great. > > I certainly have the impression that locations that have their own IT > people that understand the system and want to be in control of their > own situation tend to run Debian (or a Debian derived system), while > those that just want things solved and don't care to have the expertise > themselves tend to run Redhat enterprise linux instead. After all if > you have the people and a large installation, the support contract with > redhat could pay for a lot of competent IT staff. > > -- > Len Sorensen >
Re: RedHat or Debian amd64
On 06/26/2013 10:40 AM, Lennart Sorensen wrote: On Wed, Jun 26, 2013 at 04:33:20PM +0200, Francesco Pietra wrote: Hello: I noticed that in my country supercomputer center all machines, both CPU (FERMI) and GPU (AURORA, PLX) run on RedHat Linux. As a long time user of Debian GNU Linux amd64, I am curious whether such machines elsewhere also run, or could run, on Debian am64. If not, why? A problem of kernel? Some people want someone to blame if there are problems, or to demand support from if they need something solved right away. Redhat will sell you support contracts and will solve problems. But you pay for it. If you like doing it yourself or to solve things by cooporating with the community instead, then Debian works great. I certainly have the impression that locations that have their own IT people that understand the system and want to be in control of their own situation tend to run Debian (or a Debian derived system), while those that just want things solved and don't care to have the expertise themselves tend to run Redhat enterprise linux instead. After all if you have the people and a large installation, the support contract with redhat could pay for a lot of competent IT staff. Frankly it's like dredging up the Microsoft versus open source debate, Microsoft /Redhat answer the questions atr the end user/client beckon call where as Debian or other open source /crowd sourced projects take the mailing list and fourm based support approach. IMHO i think the truly community driven alternative software in general is a very educational and democratic way to distribute, manage and maintain superior Information Systems/ Information technology products. All of this bbeing said I under stand however that in the modern corporate is/it infomation these decisions are made based upon the venders ability to solve problems asap thus maintaining a maximum up time , quasi low cost and maximum cost total cost of owner ship For me the migration to Debian/OSS was easy i wanted to get the amximum life span for my equipment dollar and trust me after putting darn near half a grand on my current lap top machine and 8gb of ram (crucial/micron technologies). I settled on Debian and opensource software for good. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51cb0679.4010...@gmail.com
Re: RedHat or Debian amd64
On Wed, Jun 26, 2013 at 04:33:20PM +0200, Francesco Pietra wrote: > Hello: > I noticed that in my country supercomputer center all machines, both CPU > (FERMI) and GPU (AURORA, PLX) run on RedHat Linux. As a long time user of > Debian GNU Linux amd64, I am curious whether such machines elsewhere also > run, or could run, on Debian am64. If not, why? A problem of kernel? Some people want someone to blame if there are problems, or to demand support from if they need something solved right away. Redhat will sell you support contracts and will solve problems. But you pay for it. If you like doing it yourself or to solve things by cooporating with the community instead, then Debian works great. I certainly have the impression that locations that have their own IT people that understand the system and want to be in control of their own situation tend to run Debian (or a Debian derived system), while those that just want things solved and don't care to have the expertise themselves tend to run Redhat enterprise linux instead. After all if you have the people and a large installation, the support contract with redhat could pay for a lot of competent IT staff. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130626144049.gs11...@csclub.uwaterloo.ca
RedHat or Debian amd64
Hello: I noticed that in my country supercomputer center all machines, both CPU (FERMI) and GPU (AURORA, PLX) run on RedHat Linux. As a long time user of Debian GNU Linux amd64, I am curious whether such machines elsewhere also run, or could run, on Debian am64. If not, why? A problem of kernel? Thanks francesco pietra
Re: HP DV7 amd64 Turin x2 RM-70
blacklist the radeon driver and see how you go (remember to rebuild initrd), then install the newest ati driver Dean On 08/01/2013, at 6:25 PM, sub...@gmail.com wrote: > Hi Tiandao, > I've not seen the spec, but i guess your laptop has an ati as vga card. I > know of many problems caused by framebuffer and ati cards not working well > together. > > Try booting with the right vga option. Grub's man page is a good reference > point for this. > > Hth. > > Cheers, > Dario > Sent from my BlackBerry® smartphone > From: Tiandao Li > Date: Tue, 8 Jan 2013 00:22:48 -0600 > To: > Subject: HP DV7 amd64 Turin x2 RM-70 > > HI, > > My laptop, HP Pavilion DV7, is an AMD Turion 64 x2 dual core mobile RM-70, > with 4G RAM and 250 G HD. I installed Ubuntu or Lubuntu from 6 till 12.10. > Since the recent Ubuntu/Lubuntu constantly crash, I want to change to Debian. > I installed 32-bit Debian 6.0.6 without any problem on Dell desktop using net > installation. However, AMD 64bit can't boot using amd64 netinst.iso, the > install menu never show up, only black screen. I google and can't find any > meaningful info, hopefully the experts here can help me. > > Best, > > Tiandao > > AMD64 Turion x2 RM-70 > > http://products.amd.com/pages/NotebookCPUDetail.aspx?id=438&f1=&f2=&f3=&f4=&f5=&f6=&f7=&f8=&f9=
