Quoting Raffaele BELARDI <[EMAIL PROTECTED]>:
Raffaele Belardi wrote:
the sdb.img as a disk image, so mount it as a disk (not as a partition)
so maybe it automatically skips the first 0x7e00 bytes and gives me an
aligned first partition?
have you tried playing with losetup ?
this link might h
Peter Humphrey wrote:
[EMAIL PROTECTED] ~ $ xterm
[EMAIL PROTECTED] ~ $ xhost local:localhost
[EMAIL PROTECTED] ~ $ l32 bash
[EMAIL PROTECTED] ~ $ sh /usr/local/src/install-crossover-standard-5.0.0.sh
[EMAIL PROTECTED] ~ $ xhost local:localhost
[EMAIL PROTECTED] ~ $ l32 bash
[EMAIL PROTECTED] ~ $
On Mon, 19 Dec 2005, Mark Knecht wrote:
> a user killing an existing setup or something like that. Also, do I
> need to make sure user IDs, groups, passwords are consistent between
> the two environments?
I did it by doing this:
# cp -a /etc/{passwd,shadow,gshadow,group} /mnt/gentoo32/etc
and
Mark Knecht wrote:
The tmp directories do seem to be shared at the moment. In 64-bit the
results are below. I'm not sure how to check this in the 32-bit area
but the presumption is that it's /tmp inside that environment.
ah.. try sharing your /home as well:
mount --bind /home /mnt/gentoo32/hom
Mark Knecht wrote:
If anyone sees the same thing or has some things I should try to get
it working please write back when you get a chance.
what does "df" show? Are you sharing your /tmp directory between the
64-bit and the chroot?
--
gentoo-amd64@gentoo.org mailing list
Peter Humphrey wrote:
This happens whether I'm root or myself. I dare say I'm doing something
stupid, but at the moment I can't see what.
I made a mistake in the code. I was overzealous in commenting out lines.
I have fixed it and added some more checks to ensure it does switch
personalities.
Mark Knecht wrote:
lightning ~ # l32 /bin/bash
maybe do this:
# strace -o log l32 true
that should run "true" in the 32-bit chroot, and send the strace to the
file called "log".
email me the log privately? (so we don't pollute the list)
--
gentoo-amd64@gentoo.org mailing list
Mark Knecht wrote:
Show me the error of my ways!
that is very interesting. A bug?
l32 should be suid root:
ls -l `which l32`
--
gentoo-amd64@gentoo.org mailing list
Mark Knecht wrote:
[EMAIL PROTECTED] ~ $ l32 /bin/bash
first off, to find out if you're indeed in the chroot, you can do a "df"
or a "w" to see. It should print something different than what is
reality.. ie you're in the chroot.
second, you can do a "uname -a" to see if you're i686 or x86_6
Brett Johnson wrote:
But so far, this seems to work really well for me.
or just use :
# l32 $CMD
where $CMD is whatever you wanna run (bash, firefox-bin, vim)
:)
--
gentoo-amd64@gentoo.org mailing list
Mark Knecht wrote:
Billy - I would agree with a default of /mnt/gentoo32 for now, just to
match the manual.
ok. I'll make the change to the patch and upload it to the bug report.
/usr/local/portage/distfiles. I take it from reading the rest of this
thread that this is not required?
that's c
Peter Humphrey wrote:
(Pardon my butting in, Billy; I thought my experience might help Mark.)
no worries! What you said is pretty much on target except for the
distfiles, but as Duncan said, if you run a distfile cleaner it will
clean out the original tarball, however, the ebuild *should* dow
Billy Holmes wrote:
(2) copy the patch to sys-apps/l32/files
sorry for replying to my own message, but just to let you know.. files
should be a directory:
# mkdir -p /usr/local/portage/sys-apps/l32/files
--
gentoo-amd64@gentoo.org mailing list
Mark Knecht wrote:
What's the proper way to make this work for a user? I find myself
confused by the idea of making too much of the /mnt/gentoo32 directory
that's why I made this little program and an ebuild to go with it:
http://bugs.gentoo.org/show_bug.cgi?id=111367
http://www.gonoph.net
Brett Johnson wrote:
As an example, look for your primary hard drive entry (hda, hde, sda etc).
There should be a similar entry for st0 after it detects the tape drive.
he could also post a gzip'd copy of his dmesg, or better yet.. provide a
link to it.
--
gentoo-amd64@gentoo.org mailing list
Duncan wrote:
I'm /definitely/ not sure on this, hopefully someone else will correct me
if I'm wrong, but I /believe/ "virtual address space" or "virtual memory"
in this case means something other than swap. I /believe/ swap would
still be part of the physical memory address space.
well, I did
Mark Knecht wrote:
I'm sure I don't have this quite right in my mind yet. I presume that
to build FIrefox and mplayer in the chrooted environemnt I will end up
building a 32-bit version of X, etc., but I guess it's not used?
exactly :)
it just needs those 32-bit libraries to link against. All
Duncan wrote:
The current AMD spec says the CPUs offer 40-bit physical memory
addressing, 48-bit virtual memory addressing. So, 256 TB virtual memory,
but only a terabyte physical memory, in a flat-address configuration.
thanks Duncan! that's good to know :)
can you imagine the RAID array ne
Duncan wrote:
for here, unfortunately. Still, if you have a blog or the like with your
thoughts on FLOSS accessibility both there and in general, feel free to
post a link!
Aye, I'd be mega-interested in reading that as well.
--
gentoo-amd64@gentoo.org mailing list
Mark Knecht wrote:
2) If I build a 32-bit install is there anyway to run this 32-bit
environment within the 64-bit environment? I assume not.
that's exactly what a 32-bit chroot is. You run 64-bit, but you chroot
into the 32-bit directory which basically has a copy of gentoo in it but
with "a
Conway S. Smith wrote:
assumption on this list, then you automatically get support for well
over 4GiB of memory (I can't remember exactly how much is supported, but
If we low ball it and just assume 48-bits are used to address memory,
then that's
256 Terabytes of RAM :)
I think we're safe f
Mark Knecht wrote:
installed so it seems to be an AMD64 issue. Note that the AMD64 box
uses firefox-bin while the 32-bit machine uses Firefox from source.
that is why :)
your amd64 is running a 32-bit firefox, and you installed a 64-bit java.
install the firefox from source and you'll have a
Mark Knecht wrote:
What am I doing wrong?
Is there a better Java in portage than Blackdown for AMD64?
I actually use 32-bit and 64-bit java as I have a 32-bit firefox, but we
also run some extensive java applications - they are running as 64-bit.
I use this to test:
http://java.sun.co
Herman Roozenbeek wrote:
The same goes for me... But I really can't believe that nobody at
Microsoft knows why this is so. Unless Linux-users know more about
Microsoft's history than Microsoft itself does. ;-)
I have several theories:
(1) they want to forget about DOS, and want us to do the s
Nuitari wrote:
The whole list of forbidden names (from memory):
aux (eg ttyS0), prn (eg lp0), com1 to com4, lpt1 to lpt3, con, nul and
clock$
beat me to it.. and you have a better memory than I...
--
gentoo-amd64@gentoo.org mailing list
Nuitari wrote:
I'd much prefer to keep the actual /home data outside of the chroot.
You could mount -bind the /home into the chroot like you do with /tmp.
yes, this was probably the smartest way to do it, however, I had already
sliced up my partitions and /home had the largest available. This
sean wrote:
So would a chroot environment perhaps help with the problem apps?
I am sure I am not the first on this path, so how have some you done who
have tried these games?
I've always found that the chroot just makes things work easier. Yes,
you have a large investment period (creating the
John Myers wrote:
if you broke up the path in another table, and referenced that to the
basename, you could probably save lots of space - especially since most
It would save a lot of space proportional to the number of unique filenames,
but it wouln't really matter in practice. Each filename is
John Myers wrote:
filenames | 381,200 | 27.1M
are you storing the full pathname here?
if you broke up the path in another table, and referenced that to the
basename, you could probably save lots of space - especially since most
applications install lots of files in a limited num
Luis Medinas wrote:
desktop or server environments. Most of those kernel patches makes your
system more responsive but it doesn't do any miracles. I recommend for
exactly. It doesn't change your system into something that it's not - ie
a super computer. However, those patches may seem to creat
Karol Krizka wrote:
Would you say that gentoo-source handle this problem with around the same
quality, or would you suggest ck-sources for a desktop only environment?
ck-sources has a much different process scheduler than gentoo-sources.
This process scheduler is what makes it more interactive
Luis Medinas wrote:
Yes there's a way... buy a faster processor. Those patches for kernel
might speed up a few ms but nothing special.
those patches are not designed to speed up your machine, but to allow
you use it for many tasks that don't require high throughput. When, the
goal is to trea
Mark Knecht wrote:
Hi,
Probably no one has tried his but so far I cannot get it to build.
It does build on one of my 32-bit Intel machines:
this is a major hack. It compiles, but I don't guarantee that it won't eat
your harddrive. It reads my scsi drive OK, but it has the size wrong.
However
Karol Krizka wrote:
read the Gentoo Kernel Guide and from it seems to me that ck-sources
are the best.
I use ck-sources, but from the rc-releases (patched myself) for my
desktop as I like to test things, and I use ck-sources (server) on the
office terminal server.
I like ck-sources because
Mark Knecht wrote:
of lasting for years and becoming urban legends. So many people seem
happy with ck-sources so I think if it doesn't work for me it must be
me.
the ck kernel has specific uses. It's main purpose is to be a good
desktop kernel with a concentration on interactivity. This goal d
Mark Knecht wrote:
running SCHED_FIFO on my jackd processes, so I tried it. Clamitous
extensive testing reported on the ck-mailing list has repeatedly shown
that SCHED_FIFO does not perform anywhere like SCHED_ISO or real time.
However, the hard locks are probably due to a race condition.
T
Mark Knecht wrote:
If I cannot google something then I'll sign up for the ck list.
go ahead and sign up, you'll have about 10 answers and suggestions in
about 30 minutes - and almost all the answers will be better informed
than mine :)
I use ck-sources on all my desktop machines, plus a ter
Mark Knecht wrote:
None the less, when recording in Ardour I'll be doing a reasonable
amount of disk I/O. Not so much bandwitch - probably never more than
5-10MB/S on large recordings, but still it's a large number of audio
files and therefore more disk seeking, etc., so I'll want the whole
di
Mark Knecht wrote:
Thanks. Yes, I've run ck-sources a few times in the past but not had
when you run with ck-sources, others have found it's best to use
SCHED_ISO rather than SCHED_NORM (ck was patched with ISO support) -
which is like real time scheduling for users processes. From what I hea
Mark Knecht wrote:
everything caught up and worked well. Probably the same here. I expect
it will be fine one of these days soon.
take a look in the ck (ck-sources) mailing list:
http://bhhdoa.org.au/mailman/listinfo/ck
http://kernel.kolivas.org/
It's moderated by the author. They always ha
Tres Melton wrote:
the /tmp dirs and other things and I do this at boot. Further I have
written a program that will allow any user (approved by the sudoers file
in the chroot and the regular root) to run any program from wherever
they are without the headache of becoming root, etc.. Here ya go:
Chris S wrote:
if the answer is yes, then perhaps save your money, invest in a hdd and
usb 2 / firewire drive and backup.
in my experience usb and firewire drives are not good backup devices. A
good backup device is one that does not go tits up when you need to
retreive the data.
usb and fi
42 matches
Mail list logo
