Re: mount more than one luks partition at boot
On Sat, May 16, 2009 00:37, travis wrote: > I regularly use LVM over encryption (via cryptsetup) as per the > alternate installer. > > However, I have found that the boot process will only attempt to open > up the primary encrypted devices; if you have encrypted another drive using > the same technique, you have to mount it manually (and this causes the > mount -a to fail for that drive's /etc/fstab entry). > > I used to be rather strong regarding the boot process and how it > works, but ever since things went to initrd, I've lost touch. > > Can anyone tell me how to get an additional cryptsetup-encrypted > volume to be decrypted during the boot process, along with the primary one > which holds / and so on? Check /etc/crypttab. There's probably an entry for your root filesystem, and you should add your other(s) there, too. *edit*: resent to mailinglist, sorry. Cheers, Daniel -- http://daniel.hahler.de/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Report on Successful E17 installation from latest pkg-e debian repository
Hi all, I would like to make some requests for specific packages to be updated from the debian repositories to allow for the installation of the pkg-e team's e17 on the upcoming karmic release. E17 can be successfully installed beside gnome/kde in ubuntu if the following packages are retrieved from the debian repositories (testing and experimental): -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Report on Successful E17 installation from latest pkg-e debian repository
Hi all, I would like to make some requests for specific packages to be updated from the debian repositories to allow for the installation of the pkg-e team's e17 on the upcoming karmic release. E17 can be successfully installed beside gnome/kde in ubuntu if the following packages are retrieved from the debian repositories (testing and experimental): libeet 1.2.0 (experimental) libgcrypt11 1.4.4 libgnutls26 2.6.6 libgpg-error0 1.6 libtasn1-3 1.8 If any of these could be included in the karmic release, it would be trivial to add e17 support to Ubuntu. Let me know if i can do anything to help, I have some packaging experience. Isaac Gordezky -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Report on Successful E17 installation from latest pkg-e debian repository
On Sun, May 17, 2009 at 07:21:26PM -0400, eye zak wrote : > Hi all, Hello, > I would like to make some requests for specific packages to be updated > from the debian repositories to allow for the installation of the > pkg-e team's e17 on the upcoming karmic release. E17 can be > successfully installed beside gnome/kde in ubuntu if the following > packages are retrieved from the debian repositories (testing and > experimental): > If any of these could be included in the karmic release, it would be > trivial to add e17 support to Ubuntu. Let me know if i can do > anything to help, I have some packaging experience. With my e17-related stuff Debian maintainer hat, I disagree here. Although it is becoming more and more usable/stable, I don't think it is suitable for upload to a stable release for the moment. Library interfaces change often, making it hard to backport bugfixes or provide minor updates to these components. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Report on Successful E17 installation from latest pkg-e debian repository
On Monday 18 May 2009 11:28:07 am Albin Tonnerre wrote: > On Sun, May 17, 2009 at 07:21:26PM -0400, eye zak wrote : > > Hi all, > > Hello, > > > I would like to make some requests for specific packages to be updated > > from the debian repositories to allow for the installation of the > > pkg-e team's e17 on the upcoming karmic release. E17 can be > > successfully installed beside gnome/kde in ubuntu if the following > > packages are retrieved from the debian repositories (testing and > > experimental): > > > If any of these could be included in the karmic release, it would be > > trivial to add e17 support to Ubuntu. Let me know if i can do > > anything to help, I have some packaging experience. > > With my e17-related stuff Debian maintainer hat, I disagree here. > > Although it is becoming more and more usable/stable, I don't think it is > suitable for upload to a stable release for the moment. Library interfaces > change often, making it hard to backport bugfixes or provide minor updates to > these components. I didn't think he was asking that e17 be added to Ubuntu's repos, just that Ubuntu have the dependencies so that their repo could be added as a third party repo. That doesn't sound like too bad of a deal, since the user would still have to go out of their way to find the rest of e17. And it didn't seem too unstable when I compiled it on Debian Etch 2 years ago. -- Mackenzie Morgan http://ubuntulinuxtipstricks.blogspot.com apt-get moo signature.asc Description: This is a digitally signed message part. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Report on Successful E17 installation from latest pkg-e debian repository
On 05/17/2009 07:21 PM, eye zak wrote: > Hi all, > > I would like to make some requests for specific packages to be updated > from the debian repositories to allow for the installation of the > pkg-e team's e17 on the upcoming karmic release. E17 can be > successfully installed beside gnome/kde in ubuntu if the following > packages are retrieved from the debian repositories (testing and > experimental): > > libeet 1.2.0 (experimental) > libgcrypt11 1.4.4 > libgnutls26 2.6.6 > libgpg-error0 1.6 > libtasn1-3 1.8 > > If any of these could be included in the karmic release, it would be > trivial to add e17 support to Ubuntu. Let me know if i can do > anything to help, I have some packaging experience. > > Isaac Gordezky > From what i see in Karmic we have a couple of them already: libtasn1-3: Installed: 1.8-1 libgnutls26: Installed: 2.6.6-1 For libeet we have libeet1 libeet1: 1.1.0+svn35608-0ubuntu1 libeet-bin: 1.1.0+svn35608-0ubuntu1 but still behind in versions and the rest are also lower versions -- Sincerely Yours, John Vivirito https://launchpad.net/~gnomefreak https://wiki.ubuntu.com/JohnVivirito Linux User# 414246 "How can i get lost, if i have no where to go" -- Metallica from Unforgiven III signature.asc Description: OpenPGP digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
L2TP dialer included as default
Hello guys, For a long time cable users were suffering for the lack of a L2TP dialer in the default ubuntu setup. What it means is that users installed the OS, but had no means of connecting to the internet. It affects only users who have no router and are connected via cables (not DSL), but it's still a large amount of users. Please consider including this tool in the default ubuntu install. http://run.tournament.org.il/cables-connection-in-israel-for-linux/ This specific tool is only useful for users in Israel, as it does not yet support manually entering the L2TP host address(only choosing from a list of Israeli providers), but it will soon. If that's not possible, at least add it to the repositories, so it'll be available for install. If this isn't the right place to discuss this, please let me know where I can bring this up. Thank you, Josh -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: L2TP dialer included as default
2009/5/18 Joshua Saunders : > Hello guys, > > For a long time cable users were suffering for the lack of a L2TP dialer > in the default ubuntu setup. > What it means is that users installed the OS, but had no means of > connecting to the internet. > It affects only users who have no router and are connected via cables > (not DSL), but it's still a large amount of users. > > Please consider including this tool in the default ubuntu install. > http://run.tournament.org.il/cables-connection-in-israel-for-linux/ > > This specific tool is only useful for users in Israel, as it does not > yet support manually entering the L2TP host address(only choosing from a > list of Israeli providers), but it will soon. > > If that's not possible, at least add it to the repositories, so it'll be > available for install. > > If this isn't the right place to discuss this, please let me know where > I can bring this up. > > Thank you, > Josh > I should mention here that of the 40-50 Kubuntu installs that I have done for people, about 10 of them went right back to their old operating system due to lack of an L2TP dialer in the default Ubuntu install. No L2TP dialer == No Internet == No *buntu -- Dotan Cohen http://what-is-what.com http://gibberish.co.il -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
[rfc] improving 32bit user performance/experience...
A number of benchmarks show a significant performance loss on 32bit ubuntu over 64bit [1], on the same hardware. This is partially due to restrictions on the instruction set and partially due to worse instruction scheduling (others reasons include register width and count, for moving data and calling convention). Just how much user experience do we trade away for i386/i486 legacy compatibility these days? If (eg) 1.0% of 32bit Ubuntu users have i586-only processors, how about setting the default compile flags to -march=i586 and -mtune=pentium3 in principle? This seems like good value to tweak end-user performance/experience a bit, am I missing something, or should we just not care? (does any of this apply to x86-64, eg -mtune=core2 or k8?) --- [1] http://www.phoronix.com/scan.php?page=article&item=ubuntu_osx_64bit&num=8 -- Daniel J Blueman -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: [rfc] improving 32bit user performance/experience...
On Mon, May 18, 2009 at 7:24 PM, Daniel J Blueman wrote: > A number of benchmarks show a significant performance loss on 32bit > ubuntu over 64bit [1], on the same hardware. This is partially due to > restrictions on the instruction set and partially due to worse > instruction scheduling (others reasons include register width and > count, for moving data and calling convention). > No Shinola, sherlock. 64 bit is faster for many reasons, such as built-in position independent (i.e. relative to base) instructions and a wider register set (16 GPRs instead of 8). Most code is position independent code in libraries and takes roughly a 1% hit for the privilege; having not nearly as many registers implies a bigger hit. > Just how much user experience do we trade away for i386/i486 legacy > compatibility these days? > > If (eg) 1.0% of 32bit Ubuntu users have i586-only processors, how > about setting the default compile flags to -march=i586 and > -mtune=pentium3 in principle? > > This seems like good value to tweak end-user performance/experience a > bit, am I missing something, or should we just not care? > The bigger concern here is why are we bothering with systems like i586 that will probably have around 64MB of RAM, when you need 192MB just to install? Anything under half a gig is going to give a horrible user experience. Ubuntu targets a lot of non-desktop platforms. You and I on GNOME or KDE will burn 512M a few minutes after boot, once Xchat and Firefox are running (and don't kid yourself, Evolution eats its gigs and gigs of RAM-- it's nowhere near as memory-friendly as Thunderbird, I haven't figured out why, but it hates huge multi-gigabyte mailboxes). That's fine for us, and we can go for -march-i686 easy enough; but Ubuntu for Netbooks, embedded stuff, and the like will probably fall back to a reduced instruction set. One branch even targets older platforms specifically. Even if we split up Ubuntu in i486 and i686, i686 gets its most major gains from the CMOV instruction family-- a conditional MOV instruction that acts as a branch-and-mov in one (compare, then either conditional branch and mov or use cmov). See discussion here: http://ondioline.org/mail/cmov-a-bad-idea-on-out-of-order-cpus Its most major gain is a wash. Also there's no guarantee any CPU supports CMOV (it's an option), and thus to guarantee 100% compatibility we'd have to add a kernel level illegal instruction handler that handles the CMOV instruction family rather than throwing a SIGILL at the process (yes this is doable), which is very slow. Mind you I'm not against abandoning anything below i686 on desktops eventually, but some embedded systems will need i586 and the like. Cost-benefit analysis here. > (does any of this apply to x86-64, eg -mtune=core2 or k8?) Yes but this becomes a mess. Leave it as is. gcc is good at tuning to general-purpose in an instruction set. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
