Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
so lets think linux. lsusb lspci lsmod and dmesg. after that info is shown we may actually know how to handle this situation in a linux manner.
raw info. to see the device see how the kernel is loading it. see if there is missing firmware etc etc etc.
so little more info. I really doubt your laptop uses v4l1 unless it is like 9 years old.
this has been solved before. lets find if you do have a /dev/video0 and if it is associated with any user space.
v4l1 is sometimes needed for compatibility with older applications.
You do not need to replace your stable. You can chroot to other distros under stable. You can borrow kernels from other sources and boot those in stable. You can even install other linux's in linux. With a live linux image you can boot those without burning them to optical media, lots of ways to use a usb stick ($20 for 32GB these days) to do this type of stuff. Easy2boot, sysconfig, and other options. If it's the versions of things that's preventing skype from working, it's a quick way to verify that it does work (on distro X). Then you can start to narrow down what's different between distro A and distro B. Debian stable is a fine OS, but if you don't have old hardware with all of it's bugs fixed at least a year ago, it can be less than a joy to deal with.
Shadow 7 this is about skype and a camera I used v4l1 up to last year finally found a newer camera at a garage sale a hp. that uses v4l2 I am very well acquainted with this problem ok. Motion eye a motion detector program for your cam was one of the last ones till 2004 required you to force it to use v4l1.
there is obviously a library missing that is causing this. I have tested the latest Debian I find it rather unpolished not bad but from my point of view they could use a little more testing.
since I do not use Debian very often I only rate it to Slackware out of the box can it do xyz.
since I do not know if they are using 64 bit or 32 Debian I may have missed that. a simple dmesg output would tell a bunch.
I find doing a complete reinstall of a operating system to get one program to work is a little to much for my head.
Perhaps replace is too drastic a description. You can chroot into another distro without installing it. From your existing distro. It's a little complex, but the process is relatively simple. You download a live distro image. Then you mount it. Then you chroot into it. You'll be using the kernel and virtual filesystems of the host distro, but you'll be running all the software and libs of the live image in the chroot. It has limits and quirks, but it's an almost simple way to see if your issue is a missing lib, or a library versioning issue.
Various ways to rsync the root fs of the live image to a read and write filesystem so you can install extra stuff and do customizations. If you stick to the chroot option, you don't even need to put the root fs of the live image on dedicated partition, you can make it a subset of your /home directory. All of which assumes that you have a few G's of free space to play with.
The complexity comes in that before you chroot you need to share things with the host distro. Like the /proc and /dev of the host distro. If you want to launch gui apps inside the hosts running X, then you need to clone the .Xauthority file and set the DISPLAY and XAUTHORITY vars as well as share a few more things with the host distro. Like /dev/pts, /run, /sys, /tmp. If you need to play with kernel modules you might need to share the /lib/modules/ path for the current kernel. If the host distro is 32 bit and the chroot is 64 bit you'll need to be using a 64 bit kernel on the host distro. And a few other quirks.
I'm probably making it sound more complex than it is, so let me list an example of sharing the X with a second distro on a partition. Since the .Xauthority file needs to be shared, a write-able filesystem makes that simple(r).
# mount /dev/sdc3 /mnt/p3
# cd /mnt/p3
# mount -t proc none ./proc
# mount --rbind /dev ./dev
(if you don't need X, this is good enough to chroot)
(like grabbing and applying updates from the CLI)
# cp /home/UserThatStartedX/.Xauthority ./home/UserOfChroot/
# mount --rbind /dev/pts ./dev/pts
# mount --rbind /run ./run
# mount --rbind /sys ./sys
# mount --rbind /tmp ./tmp
(now chroot into the "other" distro)
# export LANG=C; chroot /mnt/p3 /bin/bash
(hello other distro, how are you today?)
# chown UserOfChroot:UserOfChroot ./home/UserOfChroot/.Xauthority
# su - UserOfChroot
$ export DISPLAY=":0.0"
$ export XAUTHORITY="/home/UserOfChroot/.Xauthority"
(at this point you should be running in the chroot as a user with access to the X / gui)
(or any X application that you desire, like skype)
There's other options like virtual box and the likes. Which should simplify this process. But you don't need it to do stuff like this. You could be running a live distro and chroot into the read+write distro using this method. Any many other neat things that makes linux so useful.
Once you run a few applications it gets a little difficult to undo the mounts that are shared, even after you've exited the chroot. A reboot is the simple undo of those mount points. If your webcam isn't working because of kernel issues, this method wont help that symptom. Unless you clone the kernel on the chroot distro and boot into that kernel on the host distro. Easier said than done of course.
Debian has met most of my needs. At least on my older hardware. The few bleading edge apps that I once a while need to use can be handled by this chroot methodology. Or keep it simpler and just dual boot multiple distros. Although some distros I'd rather chroot into than boot, like pentoo. Plus I'm on old hardware with low ram, so the chroot option lets me keep my ps output short, while still having all the things I need to function. In this way distros that recommend a minimum ram amount greater than my hardware can still be used as the ram requirement of the host distro is a lower spec.
Just an old trick that I learned back when java didn't have a 64 bit browser plugin. Chroot into a 32 bit knoppix install from your 64 bit linux distro of choice and play those buggy EA games. Oddly I've had to do this for much of the same reasons in recent history for other games by other venders. When updates break option A, try the option B aka door number 2.