Re: [gentoo-amd64] boot Gentoo from USB key
Branko Badrljica wrote: Jason wrote: initrd is exactly how you do it. In the case of booting off of USB, there are too many variables (drive detection order, different hardware, etc) to handle on the kernel command line. An initrd gives you the flexibility to solve these problems. You could use initrd/initramfs, but seems like a lot of complications for little gain... I wouldn't call a portable, writable, boot from anywhere Linux OS on a thumbdrive a trivial gain. ;-) But ythe pivot root. What happens if you execute something that was dynamically linked from intramfs and it decides to load and link another module with dlopen() from new root ? If you have that module and it belongs to the same version, then probably everything is fine. Otherwise it might not be. 1.) a good initrd will use only statically linked executables. 2.) you shouldn't start any servers or background processes from initrd. 3.) initrd's are tied to kernels. Every distro's initrd generator is re-run upon upgrading the kernel. The modules versions won't be out of sync then. Gentoo has genkernel for this purpose. Also, opened files and extra nodes in /dev during intiramfs phase tend to cause a headache or two... If your initrd follows the 3 suggestions, above, there won't be any processes running to hold a file or device open. Unless you had something else in mind? Jason. -- gentoo-amd64@lists.gentoo.org mailing list
Re: [gentoo-amd64] boot Gentoo from USB key
Branko Badrljica wrote: Jason wrote: You may want to look at specifying root by it's UUID. This will prevent issues like the USB drive being /dev/sdg on one machine, /dev/sdb on another, and on reboot it all changing because the drives were detected in a different order. I have tried that and booting by UUID never worked for me except once in past on some particular kernel. I can put an UUID in /etc/fstab, but not as kernel boot parameter. I did some googling about that and found soemthing about that UUID as kernel parameter was a hack which was thrown out and that they don't intend to support it in the future. It's aong the lines of "if you don't like anything about booting procedure, boot from initramfs, do what you have to do and then do pivot_root "... Exactly. The kernel command line should be simple. Complicated or unusual tasks, like booting from USB, should be handled by initrd. In the past, instead of 'rootdelay=', I add a wait to the init script, eg: while [ ! -e /dev/disk/by-uuid/1234-abcd-45gf-0659 ] do sleep 0.1 done And how do you do that when you are trying to get to root partition after kernel initialisation ? At that moment you can't run a script, since you don't have an access to any partition. initrd is exactly how you do it. In the case of booting off of USB, there are too many variables (drive detection order, different hardware, etc) to handle on the kernel command line. An initrd gives you the flexibility to solve these problems. You could use initrd/initramfs, but seems like a lot of complications for little gain... I wouldn't call a portable, writable, boot from anywhere Linux OS on a thumbdrive a trivial gain. ;-) Jason. -- gentoo-amd64@lists.gentoo.org mailing list
Re: [gentoo-amd64] boot Gentoo from USB key
Raffaele BELARDI wrote:
...
The kernel starts to load, but panics because it is unable to find the
root partition. When it stops it shows the available partitions, these
include all the hard disk partitions but no USB key partition. In fact,
if I omit the 'root' parameter from the grub shell the boot works fine
but it uses the hard disk root partition instead of the USB one.
You may want to look at specifying root by it's UUID. This will prevent
issues like the USB drive being /dev/sdg on one machine, /dev/sdb on
another, and on reboot it all changing because the drives were detected
in a different order.
From the log on the screen the USB controller seems correctly detected,
so I don't understand why it is not finding the root. While writing this
one idea comes to my mind, maybe it is failing because I attach the key
to a SDC/MMC/USB card reader? This evening I'll try to plug it into a
different USB slot.
In the past, instead of 'rootdelay=', I add a wait to the init script, eg:
while [ ! -e /dev/disk/by-uuid/1234-abcd-45gf-0659 ]
do
sleep 0.1
done
hth,
Jason.
--
gentoo-amd64@lists.gentoo.org mailing list
Re: [gentoo-amd64] Networking bridging
Chris Brennan wrote:
> I am trying to set up a Bridge for Qemu to use. I followed the guide
> at
> http://gentoo-wiki.com/HOWTO:_Qemu#Using_TUN.2FTAP_interface_as_a_normal_user
> but when ever the bridge starts, I loose connectivity outside of my
> box :/ ... am I missing something
>
>
> I've includes the output of my /etc/conf.d/net file
...
> ##
> # LAN
> ##
> config_eth0=( "192.168.1.2 netmask 255.255.255.0 brd 192.168.1.255" )
> routes_eth0=( "default via 192.168.1.1" )
>
> ##
> # Bridge
> ##
> bridge_br0="eth0"
> config_br0=( "192.168.1.20 netmask 255.255.255.0 brd 192.168.1.255" )
> #dhcpcd_br0="-t 10"
> RC_NEED_br0="net.eth0"
> brctl_br0=( "setfd 0" "sethello 0" "stp off" )
> config_tap0=( "10.0.2.1 netmask 255.255.255.0" )
>
Here's my /etc/conf.d/net for bridging.
# Begin ##
# dynamically add devs to br0 as they are created
bridge_add_tap0="br0"
bridge_add_tap1="br0"
bridge_add_tap2="br0"
# put devs in promiscuous mode, br0 has config
config_eth0=( "0.0.0.0 promisc" )
config_tap0=( "0.0.0.0 promisc" )
config_tap1=( "0.0.0.0 promisc" )
config_tap2=( "0.0.0.0 promisc" )
config_br0=( "192.168.1.2 netmask 255.255.255.0" )
routes_br0=( "default via 192.168.1.1" )
bridge_br0="eth0"
# cascading deps tap* irrelevant w/o br0 and eth0
depend_tap0() {
need net.br0
}
depend_tap1() {
need net.br0
}
depend_tap2() {
need net.br0
}
depend_br0() {
need net.eth0
}
# enable proxyarping
postup() {
if [[ ${IFACE} == "tap0" ]] ; then
echo " * Enabling Proxy ARP on ${IFACE}..."
echo 1 >/proc/sys/net/ipv4/conf/tap0/proxy_arp
fi
if [[ ${IFACE} == "tap1" ]] ; then
echo " * Enabling Proxy ARP on ${IFACE}..."
echo 1 >/proc/sys/net/ipv4/conf/tap1/proxy_arp
fi
}
# remove from bridge
postdown() {
if [[ ${IFACE} == "tap0" ]] ; then
echo " * Removing ${IFACE} from bridge br0..."
brctl delif br0 tap0
echo " * Disabling Proxy ARP on ${IFACE}..."
echo 0 >/proc/sys/net/ipv4/conf/tap0/proxy_arp
fi
if [[ ${IFACE} == "tap1" ]] ; then
echo " * Removing ${IFACE} from bridge br0..."
brctl delif br0 tap1
echo " * Disabling Proxy ARP on ${IFACE}..."
echo 0 >/proc/sys/net/ipv4/conf/tap1/proxy_arp
fi
}
# End
The key difference is that the underlying "real" devices in the bridge
need to be 0.0.0.0 and in promiscuous mode. The bridge has the ip
address.
If you _need_ two separate subnets, you may want to use a tun and
iptables or ip_forward/route. One idea you might try is what I
suggested, but with br0 = subnetA, br0:1 = subnetB... Not sure it would
work, but worth a try.
Assuming your tap device is the end of an incoming VPN, the proxy arping
is only necessary if you want the VPN client (the above script is for
the VPN server) to be able to hit the internet through the server's gateway.
Yeah, looking at the preup/postdown functions just now made me realize I
wrote them a _long_ time ago. rewrite at your leisure... ;-)
hth,
Jason.
--
gentoo-amd64@lists.gentoo.org mailing list
Re: [gentoo-amd64] Re: xf86-video-i810 (now intel) upgrade path?
Duncan wrote: > Jason <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], > excerpted below, on Thu, 30 Aug 2007 10:33:58 -0400: > >> This did the trick: >> eix -S 'kernel.*X' >> >> * x11-base/x11-drm > > Thanks. Obviously, my knowledge wasn't complete, as I had warned might > be the case. > No problem. Now, if only I could find a clean way (within the portage system) to determine exactly which X.org packages need to be unmasked to get xf86-video-intel to work properly since 'emerge -av xf86-video-intel' doesn't want to upgrade anything... thx, Jason. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] Re: xf86-video-i810 (now intel) upgrade path?
Duncan wrote:
> Jason <[EMAIL PROTECTED]> posted [EMAIL PROTECTED],
> excerpted below, on Wed, 29 Aug 2007 16:37:37 -0400:
>
>> Duncan wrote:
>>> Jason ...:
>>>
>>>> Also, when compiling X.org/mesa/drm from source, it builds the kernel
>>>> modules drm.ko and i915.ko. What package does that in gentoo?
>>> That's the kernel, AFAIK. [snip]
>> Yep, that's what I'm looking to replace with the ones from the X.org
>> tree. I'd like to do it within the portage system, but 'equery files
>> mesa' didn't have any *.ko's and 'equery files libdrm' didn't either...
>>
>> The kernel version usually lags behind primary developer's version,
>> especially when there a lot of development occurring (like the intel
>> driver).
>>
>> I also tried 'eix -S 'X\.org.*kernel'' and got nothing... Does anyone
>> have any idea if there is even a Gentoo pkg for the X.org drm/i915
>> modules?
[snip]
> So (again) to my knowledge, which might be incorrect as I don't have the
> hardware, I believe if you want newer than in-kernel versions, you'll
> need to compile them manually, *OR*...
This did the trick:
eix -S 'kernel.*X'
* x11-base/x11-drm
Available versions: ~20051223 20060608 ~20060608-r1 ~20070314
{kernel_FreeBSD kernel_linux video_cards_i810 video_cards_mach64
video_cards_mga video_cards_nv video_cards_r128 video_cards_radeon
video_cards_savage video_cards_sis video_cards_sunffb video_cards_tdfx
video_cards_via}
Homepage:http://dri.sf.net
Description: DRM Kernel Modules for X11
Now I have to figure out what other ebuilds need to unmasked/rebuilt to
get it running smoothly. It was in the base portage tree.
Jason.
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] Re: xf86-video-i810 (now intel) upgrade path?
Duncan wrote: > Jason <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], > excerpted below, on Wed, 29 Aug 2007 10:18:57 -0400: > >> Also, when compiling X.org/mesa/drm from source, it builds the kernel >> modules drm.ko and i915.ko. What package does that in gentoo? > > That's the kernel, AFAIK. Under Device Drivers > Character Devices, I'm > guessing (don't have your chipset) Intel ... I8xx ... chipset support > (for i915.ko) and Direct Rendering Manager ... (for drm.ko, I use this > but have it configured as built-in not module, and the help text doesn't > say what the module name is, so again, can't say for sure). Yep, that's what I'm looking to replace with the ones from the X.org tree. I'd like to do it within the portage system, but 'equery files mesa' didn't have any *.ko's and 'equery files libdrm' didn't either... The kernel version usually lags behind primary developer's version, especially when there a lot of development occurring (like the intel driver). I also tried 'eix -S 'X\.org.*kernel'' and got nothing... Does anyone have any idea if there is even a Gentoo pkg for the X.org drm/i915 modules? thx, Jason -- [EMAIL PROTECTED] mailing list
[gentoo-amd64] xf86-video-i810 (now intel) upgrade path?
All, I'd like to unmask xf86-video-i810 to grab v2.1.1, however, when I do, my compiz-fusion/kde setup gets borked. (I have to resize terminals to get the screen to update, etc) Is there a handy way to determine what needs to be re-merged/unmasked after upgrading xf86-video-i810? I'd prefer to avoid re-merging all of x.org/compiz-fusion/emerald if I can avoid it. Also, when compiling X.org/mesa/drm from source, it builds the kernel modules drm.ko and i915.ko. What package does that in gentoo? thx, Jason -- [EMAIL PROTECTED] mailing list
[gentoo-amd64] Eterm wierdness
Got a wierd one. Sometimes (usually after a memory intensive task, like
emerging ooffice), Eterms in which I'm logged in as root will cause a
PrintScreen whenever I hit an arrow key.
To avoid the printjobs, I start Eterm with '--print-pipe /usr/bin/true',
which prevents the waste of paper, but crashes the Eterm. Once the
condition trips (after emerging ooffice), it is 100% repeatable. root
logins in xterm do _not_ exhibit the same behavior. User logins in
either Eterm or xterm don't do it either.
I'm thinking it is some sort of memory access error in bash when
'TERM=Eterm', but I'm having trouble narrowing it down. I tried using
the Eterm.ti file ('tic -o /usr/share/terminfo/ Eterm.ti') from the
Eterm tarball (Gentoo recently started using the one provided by
ncurses). No luck.
If I shut down the X server and restart it, it goes away.
Anyone have a clue where I can look? I'd like to isolate and fix it so
I can just provide a patch to the appropriate folks. For all I know, it
could be a problem in X or enlightenment...
thx,
Jason.
--
gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] emerge --newuse world error
Daniel Iliev wrote: > Sean wrote: >> Mathieu Seigneurin wrote: >>> On Tuesday 31 October 2006 16:23, Daniel Iliev wrote: >>>> Sean wrote: >>>>> Thanks, forgot the -C is clean or remove. >>>>> Followed your steps and on the modprobe line received the following >>>>> 'FATAL: Error inserting nvidia >>>>> (/lib/modules/2.6.16-gentoo-r9/video/nvidia.ko): Invalid module >>>>> format' >>>> That is not supposed to happen. ;-( >>>> Did you get any errors from "emerge nvidia-drivers"? >>>> >>>> Please, re-emege nvidia-drivers again and watch its output. I >>>> suppose it >>>> should say something about your "kernel tree/sources". >>>> >>>> -- >>>> Best regards, >>>> Daniel >>> Also look at what dmesg says - you probably have more details about the >>> error there. >>> And make sure you emerge nvidia-drivers with the same version of GCC as >>> you used to build your active kernel. >>> >>> Regards, >>> Mat >> I already had looked at dmesg. Since upgrading gcc many, if not all my >> modules are now having problems. I wanted to try to get X working >> first, then the others. > > I would say that upgrading gcc and the problems with your kernel modules > are not related but if you have such problems, you have to rebuild the > kernel no matter the reason. > The above is wrong. The kernel (and modules) record what version of GCC they were compiled with. This version is checked at module load. If the kernel's GCC version doesn't match the modules GCC version, the module loading fails. This only becomes an issue with modules that are compiled outside of the kernel tree [1]. To fix this you have two options. either switch out which version of gcc you are using and recompile modules that are maintained outside of the tree, or recompile your kernel with the current version of gcc. First though, you need info: # modinfo | grep vermagic # cat /proc/version # gcc-config -l I would recommend recompiling the kernel, but it's up to you. hth, Jason [1] - The caveat being when the GCC version has changed after the kernel tree was already compiled and installed, and you are recompiling the kernel tree for one module, without cleaning the tree. -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Using encrypted swap via cryptsetup-luks on amd64
On Sunday 22 October 2006 06:16, Richard Freeman wrote: > 3. Generate a random encryption key (WHOA - why on earth is that script > using urandom for this - it only pulls 18 bytes - I just changed it to > /dev/random in mine (more secure in the event the entropy pool gets low > - although normally they are the same)). For those not in the know, > /dev/random blocks if it runs out of entropy, but /dev/urandom just > gives out a less random value. If you need 50MB of random data you have > to use urandom if you don't want to freeze the system for 12 hours, but > for 18 bytes we can afford to wait for quality data. Nice catch. At this point in booting we should have plenty of entropy in the random pool. Would be wise to start service random a few steps back to make sure it's really random and not boot-sequence-pridictable-random, although the script is plenty paranoid. > > 4. /dev/(u)random dumps binary data - losetup wants something more sane > as a key, so uuencode is used to convert to text. No source of > compromise here - the original data was random so the uuencoded data is > still random (it is now constrained in potential output values, but is > longer which compensates). I actually ran this script many times without uuencode, just passing the random string to losetup without any complaints. glad i have uuencode now though ;) -Jason -- gpg public key: http://lazybird.hyperintelligent.net/~jbooth/jbooth_key.asc -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Using encrypted swap via cryptsetup-luks on amd64
On Sunday 22 October 2006 06:16, Richard Freeman wrote: > I'd just make SWAPDEVICE and LOOPDEV command-line parameters and then > call the script 4 times. or drop a for loop into it... I don't know much about raid, but if it's treated in /dev as a single device, you may just be able to replace it and go. May be overly paranoid, but writing encrypted data multiple times could help someone to guess what certain file is and make an attack on the encryption easier. I use ext2 for my encrypted loops so there's no journal as well. Although the power fails sometimes, and can be a pain to fsck, i haven't lost anything yet. > > > swap again, wipe the partitions, and simply leave swap off. Only if they > > ever get suspend to disk working semi-reliably... > > Not sure encrypted swap will play well with suspend to disk. Somehow > when the system wakes up it needs to find out what the encryption key > actually was, otherwise the loop device can't be reactivated. Last time i tried S2D, albeit a couple of years now, the loops all had to be re-mounted after wake(and of course fsck'd) > Now, it > is possible that the kernel will just write the key to disk somewhere, > but this defeats much of the security of an encrypted swap device (where > after a reboot the swap space is impossible to read without a brute > force attack on AES-CBC). I think key retention support in kernel may accomplish this > If the key isn't written to disk the kernel > will boot and look around and not see any valid swap partitions on the > disk at all. Also, it seems AES-CBC is the standard for swap.. at least per the loop-aes package that contained this script. Does anyone of a good benchmark list? I found this but didn't see aes on it http://www.eskimo.com/~weidai/benchmarks.html -Jason -- gpg public key: http://lazybird.hyperintelligent.net/~jbooth/jbooth_key.asc -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Using encrypted swap via cryptsetup-luks on amd64
On Sunday 22 October 2006 05:59, Richard Freeman wrote: > Portage file search is your friend: > > http://www.rommel.stw.uni-erlangen.de/~fejf/cgi-bin/pfs-web.pl > > If you have a diverse set of packages try running the client to improve > the index (not that it needs all that much improvement). Thanks. Yeah I thought I had forgotten a command to do it, but appearently not.. -Jason -- gpg public key: http://lazybird.hyperintelligent.net/~jbooth/jbooth_key.asc -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Using encrypted swap via cryptsetup-luks on amd64
On Sunday 22 October 2006 00:21, Francesco Talamona wrote: > On Sunday 22 October 2006 07:16, Jason Booth wrote: > > I can't find which gentoo package contains uuencode(installed > > uucp,uulib,uudeview and googled to no avail). > > [08:19] [EMAIL PROTECTED]:~]$ equery belongs /usr/bin/uuencode > [ Searching for file(s) /usr/bin/uuencode in *... ] > app-arch/sharutils-4.2.1-r11 (/usr/bin/uuencode) only works if already installed ;) lazybird ~ # equery belongs /usr/bin/uuencode [ Searching for file(s) /usr/bin/uuencode in *... ] lazybird ~ # > > Ciao > Francesco > > -- > Linux Version 2.6.18-gentoo-r1, Compiled #1 PREEMPT Wed Oct 18 22:52:55 > CEST 2006 > One 2.2GHz AMD Athlon 64 Processor, 2GB RAM, 4408.88 Bogomips Total > aemaeth -- gpg public key: http://lazybird.hyperintelligent.net/~jbooth/jbooth_key.asc -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Using encrypted swap via cryptsetup-luks on amd64
On Saturday 21 October 2006 23:16, Jason Booth wrote:
> On Saturday 21 October 2006 21:26, Richard Freeman wrote:
> > Duncan wrote:
> > > I'm not running encrypted swap tho I've always thought it'd be nice to
> > > setup /someday/, so I can't help directly.
> >
> > I just run the following script from local.start. I forget where I
> > found it online. Obviously change the swapdevice variable!
> >
> > Honestly, my guess is that it is overly paranoid. You could probably
> > eliminate most of the steps this script takes, but it runs in only a
> > second or two so it isn't a big deal. I would leave in the bit that
> > zeros the start of the encrypted swap partition - it probably helps to
> > keep mkswap from getting confused.
> >
> > Not sure what the fancy scripts that are being discussed do, but this is
> > plenty good for me, and I'm sure Duncan could get this running in about
> > 15 seconds...
>
> Yeah this script has worked fine for me for like 5 years except for one
> thing:
>
> I can't find which gentoo package contains uuencode(installed
> uucp,uulib,uudeview and googled to no avail).
Nevermind I just found it: sharutils
>
> > #!/bin/sh
> > # Run this script somewhere in your startup scripts _after_ random
> > # number generator has been initialized and /usr has been mounted.
> > # (md5sum, uuencode, tail and head programs usually reside in /usr/bin/)
> >
> > # encrypted swap partition
> > SWAPDEVICE=/dev/hda3
> >
> > # loop device name
> > LOOPDEV=/dev/loop6
> >
> > MD=`dd if=${SWAPDEVICE} bs=4k count=10 2>/dev/null | md5sum`
> > for X in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ; do
> > dd if=/dev/zero of=${SWAPDEVICE} bs=4k count=10 conv=notrunc
> > 2>/dev/null sync
> > done
> > UR=`dd if=/dev/urandom bs=18 count=1 2>/dev/null \
> >
> > | uuencode -m - | head -n 2 | tail -n 1`
> >
> > echo ${MD}${UR} | losetup -p 0 -e aes-cbc-256 ${LOOPDEV} ${SWAPDEVICE}
> > MD=
> > UR=
> > dd if=/dev/zero of=${LOOPDEV} bs=4k count=10 conv=notrunc 2>/dev/null
> > sync
> > mkswap ${LOOPDEV}
> > sync
> > swapon ${LOOPDEV}
>
> Thanks,
> Jason
>
> --
> gpg public key:
> http://lazybird.hyperintelligent.net/~jbooth/jbooth_key.asc
--
gpg public key: http://lazybird.hyperintelligent.net/~jbooth/jbooth_key.asc
--
gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Using encrypted swap via cryptsetup-luks on amd64
On Saturday 21 October 2006 21:26, Richard Freeman wrote:
> Duncan wrote:
> > I'm not running encrypted swap tho I've always thought it'd be nice to
> > setup /someday/, so I can't help directly.
>
> I just run the following script from local.start. I forget where I
> found it online. Obviously change the swapdevice variable!
>
> Honestly, my guess is that it is overly paranoid. You could probably
> eliminate most of the steps this script takes, but it runs in only a
> second or two so it isn't a big deal. I would leave in the bit that
> zeros the start of the encrypted swap partition - it probably helps to
> keep mkswap from getting confused.
>
> Not sure what the fancy scripts that are being discussed do, but this is
> plenty good for me, and I'm sure Duncan could get this running in about
> 15 seconds...
Yeah this script has worked fine for me for like 5 years except for one thing:
I can't find which gentoo package contains uuencode(installed
uucp,uulib,uudeview and googled to no avail).
>
> #!/bin/sh
> # Run this script somewhere in your startup scripts _after_ random
> # number generator has been initialized and /usr has been mounted.
> # (md5sum, uuencode, tail and head programs usually reside in /usr/bin/)
>
> # encrypted swap partition
> SWAPDEVICE=/dev/hda3
>
> # loop device name
> LOOPDEV=/dev/loop6
>
> MD=`dd if=${SWAPDEVICE} bs=4k count=10 2>/dev/null | md5sum`
> for X in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ; do
> dd if=/dev/zero of=${SWAPDEVICE} bs=4k count=10 conv=notrunc
> 2>/dev/null sync
> done
> UR=`dd if=/dev/urandom bs=18 count=1 2>/dev/null \
>
> | uuencode -m - | head -n 2 | tail -n 1`
>
> echo ${MD}${UR} | losetup -p 0 -e aes-cbc-256 ${LOOPDEV} ${SWAPDEVICE}
> MD=
> UR=
> dd if=/dev/zero of=${LOOPDEV} bs=4k count=10 conv=notrunc 2>/dev/null
> sync
> mkswap ${LOOPDEV}
> sync
> swapon ${LOOPDEV}
Thanks,
Jason
--
gpg public key: http://lazybird.hyperintelligent.net/~jbooth/jbooth_key.asc
--
gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] newcomer:
On Sunday 08 October 2006 03:02, Daniel Iliev wrote: > First things first: CHEERS! ;-) yes... -- I'll find my signature on that box in the corner later... it's jbooth and my gpg public is: http://lazybird.hyperintelligent.net/~jbooth/jbooth_key.asc -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] newcomer:
On Sunday 08 October 2006 02:03, benedikt wrote: > Am Sonntag, den 08.10.2006, 02:02 -0600 schrieb Jason Booth: > > hello, > > cheers, > > and... > > hello, > cheers, > and... > and grez from germany thank you, bot or not... And I must apologize in advance: I run my mailserver off of a sometimes shaky satellite connection. I won't change this, until I have a colo, as my users, especially myself, will not be subjected to mail stored on a non-encrypted partition with strangers having access. That being said, sometimes I answer things that were answered an hour ago and look like a total fool. I'm a total fool for sure, but this is due to mailserver issues. Please have a little patience for this thanks, Jason -- I'll find my signature on that box in the corner later... it's jbooth and my gpg public is: http://lazybird.hyperintelligent.net/~jbooth/jbooth_key.asc -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] newcomer:
Hi. I'm new to the list, although not new to gentoo. I am new to amd64 (3 weeks). I don't really have any questions yet; I actually want to join this list to help, as well as learn because I am new to 64 bit. I do have some comments though: I have had a hard time joining this list because of the off-topic siliness and nonsense. I think there are very intelligent people here (including me) that don't need to waste their time on questions that are irrellevant, silly, way off-topic, and frankly, BELOW US. I learned about off-topicness in gentoo-user, when I was off topic, discovered I was a prick, and apologised because I can be a total prick when I think I'm right (which, of course, is always the case). Anyways, hello, cheers, and... let's go somewhere with this. ~J -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Processor Temprature
On Saturday 07 October 2006 07:15, Paul Stear wrote: > I have started using the athlon cool and quiet facility with cpudyn. > However, ksensors show that the processor speed reduced from 2200 to 1 > during low activity but the processor temprature remains at 40 degree C. > I was expecting this to reduce. Is this temp normal? > For anybody who has an Athlon 64 3500 - What temps are you showing. > > Thanks for any help > Paul It's been a funky night, and I'm about to anounce myself to this list because it's new for me, and this not having anything to do with you at all, I think this list has been full of B.S. lately and hard to join I'm running an amd64 3500 at 2.2ghz and I don't think I compiled my kernel with support for temperature. If your compiles aren't failing and sed/gcc or anything that deals with floating point numbers isn't failing, you're not too hot or too overclocked or, as my dumb donkey thinks, not overclocked enough. cheers, jbooth > -- > This message has been sent using kmail with gentoo linux -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: gcc 4.1 upgrade - bad desktop interactivity anyone?
On Saturday 23 September 2006 16:21, Peter Humphrey wrote: > Nope. SSE and SSE2, but not SSE3. According to /proc/cpuinfo, that is. The flag in cpuinfo is pni for "Prescott New Instructions". Cheers, Jason -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] 64 newbie
Thierry de Coulon ([EMAIL PROTECTED]) wrote: [snip] > - are there special points I should pay attention to or can I simply follow > the amd64 install instruction? Executable file formats / Emulations --> [*] IA32 Emulation [*] IA32 a.out support jason. -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Gentoo/amd64 Documentation Changes
If anyone has any significant documentation changes (not spelling and grammar corrections) they would like made to the amd64.gentoo.org site, please email them to me. I'm taking over Documentation for the team for gerrynjr. I'm planning to freshen up the docs this weekend as I have time... -- Jason Huebel Gentoo/amd64 Documentation Lead Gentoo Board Of Trustees Member Gentoo Developer Relations/Recruiter GPG Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9BA9E230 "Do not weep; do not wax indignant. Understand." Baruch Spinoza (1632 - 1677) pgpDbFqpHhLk9.pgp Description: PGP signature
Re: [gentoo-amd64] test
Anthony Gorecki ([EMAIL PROTECTED]) scribbled: > On Thursday, December 01, 2005 03:19, Taka John Brunkhorst wrote: > > congrats, yours is working. > > My reply-before-quote filter is working, too :) You can read from /dev/null? neat. jason. -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] [OT] test, please ignore.
Now there you go. FFI. Failure to Follow Instructions. :) Looking at buying a new MB and processor so thought I'd listen in on amd64 and (possibly) dual-core issues under gentoo. Yes, am reading the docs also. :) jason. -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] My portage went all broke
On Wednesday 05 October 2005 15:08, Brian Litzinger wrote:
> Traceback (most recent call last):
> File "/usr/bin/emerge", line 3202, in ?
> mydepgraph.merge(pkglist)
> File "/usr/bin/emerge", line 1848, in merge
>
> retval=portage.doebuild(y,"clean",myroot,self.pkgsettings,edebug,cleanup=1)
> File "/usr/lib/portage/pym/portage.py", line 2434, in doebuild
> raise Exception("Unable to pull EAPI from cpv %s, tree %s; can't
> confirm that it's supported by this portage, thus unable to merge it:
> Exception was '%s'" % (mycpv, tree, e))
> Exception: Unable to pull EAPI from cpv net-dns/jbigkit-1.6-r1, tree
> porttree; can't confirm that it's supported by this portage, thus unable
> to merge it: Exception was '"'net-dns/jbigkit-1.6-r1' at None"'
Please try again with 2.0.53_rc3 or the soon-to-be-released 2.0.53_rc4.
If you can't upgrade portage, reply back with the version of portage that you
are using and I'll spin you a patch to fix this specific bug.
--
Jason Stubbs
--
gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Re: Announcement Regarding Strategic Lead
On Monday 09 May 2005 9:36 pm, Jason Huebel wrote: > Just wanted to let you guys know that I will be remaining the Strategic > Lead for Gentoo/amd64 for the near term, despite having been recently named > Operational Lead for Developer Relations. > > Since I've been around a while, I feel more comfortable maintaining an > oversight role for Gentoo/amd64 for now. My overall involvement in > Gentoo/amd64 development will be limited, so any day-to-day technical > questions should be referred to KingTaco or Kugelfang. > > I also want take the opportunity to thank a few people who have worked hard > on Gentoo/amd64 lately. If I leave anyone out, please don't feel offended. > Your work is very much appreciated! > > KingTaco and Kugelfang have been doing a great job as Operational Leads for > Gentoo/amd64. Their contributions have kept the forward momentum going for > an arch that is growing faster than we could have imagined a year ago. > Kugelfang has been especially helpful to us over the past months as he took > over the Release Engineering role for our arch. > > In addition to the Op Leads, I also want to acknowledge HParker's > contributions as AT Lead. KingTaco came up with a great idea in the Arch > Tester program, and HParker has done a superb job leading it. I know we > don't thank him enough for his contributions. The AT program has given us > several top-notch new developers. > > I also want to acknowledge cryos for all his hard work, Astinus for riding > my butt about new devs I've assigned to myself (as a recruiter) and > gerrynjr for doing such a great job getting the amd64 docs in shape. So, I sent out this email not long ago, but a few things have changed. Good things. :-) As many of you may know, I was elected as a Trustee recently. It's a great privilege to have such an important role in the development of the Gentoo community. I'm really excited and want to make the most of the position I've been granted. I've also found Developer Relations to be more demanding lately. While not a particularly popular position to fill, I consider it a good challenge to be Developer Relations Lead. I hope to make Developer Relations a group that developers will feel free to talk to. If anyone has complaints regarding Developer Relations and our methods, please bring them to my attention privately. I'll make every effort to address those concerns. So, that being said, I'd like to announce that I'll be stepping down as Gentoo/amd64 Strategic Lead, effective June 1st. Taking my place will be KingTaco. He's proven to be a capable Operational Lead and has shown himself to have quite a gift for rallying the troops. :-) And since KingTaco will be vacating one of the Operational Co-Lead positions, we need someone to fill his spot. I'm proud to announce that blubb will be taking up that post. He's a top-notch developer and has helped a lot with day-to-day amd64 work. Exciting changed happening in the Gentoo community. Let's all make the best of them! :-) -- Jason Huebel Gentoo/amd64 Strategic Lead Gentoo Developer Relations Operational Lead Gentoo Trustee Board Member Gentoo Recruiter GPG Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9BA9E230 "Do not weep; do not wax indignant. Understand." Baruch Spinoza (1632 - 1677) pgpSeQ9eR3lNU.pgp Description: PGP signature
[gentoo-amd64] Announcement Regarding Strategic Lead
Just wanted to let you guys know that I will be remaining the Strategic Lead for Gentoo/amd64 for the near term, despite having been recently named Operational Lead for Developer Relations. Since I've been around a while, I feel more comfortable maintaining an oversight role for Gentoo/amd64 for now. My overall involvement in Gentoo/amd64 development will be limited, so any day-to-day technical questions should be referred to KingTaco or Kugelfang. I also want take the opportunity to thank a few people who have worked hard on Gentoo/amd64 lately. If I leave anyone out, please don't feel offended. Your work is very much appreciated! KingTaco and Kugelfang have been doing a great job as Operational Leads for Gentoo/amd64. Their contributions have kept the forward momentum going for an arch that is growing faster than we could have imagined a year ago. Kugelfang has been especially helpful to us over the past months as he took over the Release Engineering role for our arch. In addition to the Op Leads, I also want to acknowledge HParker's contributions as AT Lead. KingTaco came up with a great idea in the Arch Tester program, and HParker has done a superb job leading it. I know we don't thank him enough for his contributions. The AT program has given us several top-notch new developers. I also want to acknowledge cryos for all his hard work, Astinus for riding my butt about new devs I've assigned to myself (as a recruiter) and gerrynjr for doing such a great job getting the amd64 docs in shape. -- Jason Huebel Gentoo/amd64 Strategic Lead Gentoo Developer Relations Operational Lead Gentoo Recruiter GPG Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9BA9E230 "Do not weep; do not wax indignant. Understand." Baruch Spinoza (1632 - 1677) pgpg3y3EY0tDX.pgp Description: PGP signature
Re: [gentoo-amd64] tightvnc segfault
> > if I run vncserver I get > > > > Couldn't start Xvnc; trying default font path. > > Please set correct fontPath in the vncserver script. > > Couldn't start Xvnc process. This error may be confusing. Perhaps you need to see the bug I raised against tightvnc: http://bugs.gentoo.org/show_bug.cgi?id=82583 A few others are seeing this problem too. -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Welcome Back Tester!
Everybody welcome Tester back to the amd64 team. For those of you who don't know, Tester and DRobbins originally started the amd64 arch builds for Gentoo. Tester just got another amd64 box, so he'll be able to contribute more great things to the arch. :-) Welcome back Tester! -- Jason Huebel Gentoo/amd64 Strategic Lead Gentoo Developer Relations/Recruiter GPG Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9BA9E230 "Do not weep; do not wax indignant. Understand." Baruch Spinoza (1632 - 1677) pgps2VMntqKh6.pgp Description: PGP signature
[gentoo-amd64] Motherboard/chip set recommendations for Gentoo/AMD64?
What motherboard/chip set combinations are best supported in recent kernels under AMD64? I am thinking of Gigabyte or Asus boards, which seem to be the most readily available around here, with either nVidia or VIA chip sets. I do care about open drivers and want to support hardware that has fully open-source, free software drivers, avoiding anything that will taint my kernel or involve binary-only components. I don't wish to debate this preference on the mailing list, though I do hold it for various ethical and practical reasons; rather I'm just stating it as a principle I'm going to abide by in choosing this hardware in upgrading my desktop machine to AMD64. I already have a laptop with Gentoo-AMD64 installed, and my plan is to copy all of the files onto new partitions on the upgraded desktop machine, to make whatever configuration changes are necessary, install grub and, I hope, have a running system. The kernel is fairly generic 2.6.10, with a lot of hardware options compiled in or as modules, and may not even have to be re-compiled to run on the new machine. I'll compile 2.6.11 in any case, but for the initial boot the existing kernel from the laptop might suffice. -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Mysql 4.1 doesn't run
Nuitari writes: > I am succesfully running Mysql 4.1.9 on my system The latest ebuild appears to be 4.1.8, which is causing trouble. Is there a 4.1.9 ebuild around, or did you compile manually? -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Mysql 4.1 doesn't run
The latest mysql 4.1 for ~amd64 compiles, but when run it issues an error to the effect that there are no fast mutexes available for this architecture, can't init databases. Has anyone else encountered this? If not, I'll put together the required information and write a bug report. I need to get mysql 4.1 running, as I am planning to upgrade my desktop machine to an amd64 system soon, and my dspam databases take advantages of features introduced in mysql 4.1 that aren't available in 4.0. -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] 2005.0 Upgrade
Mark Constable writes: > > So I start by following these points... > > # nano /etc/make.conf (add multilib to USE var) > # emerge gcc > # FEATURES=-sandbox emerge gcc Try emerge portage after setting the multilib use flag. This should install portage with multilib support. -- gentoo-amd64@gentoo.org mailing list
