Re: [gentoo-user] Problems setting up sshd on an installation kernel
On Sun, Dec 06, 2009 at 01:56:06PM -0500, Joshua Murphy wrote: On Sun, Dec 6, 2009 at 11:59 AM, Florian Philipp li...@f_philipp.fastmail.net wrote: Alan Mackenzie schrieb: Hi, folks! I'm trying to get sshd working on an embryonic Gentoo installation on my laptop. The reason is that I want to ssh from my nice comfy desktop system into this laptop to do the rest of the installation stuff. The installation kernel with which I'm having problems is: Linux livecd 2.6.30-gentoo-r8 #1 SMP Tue Nov 3 11:40:51 UTC 2009. Having started sshd on my laptop, when I do ssh -lroot 192.168.2.101 from my desktop, I get prompted for my ssh key's pass phrase, which I enter. Thereafter, nothing happens, and it continues to happen for a long, long time. [...] Clearly openpty (a C function) is failing to find some file. Don't you just love error messages like No such file or directory which forget to identify the filename? I'm guessing that the file it can't find is the device file for the new pty. Is there anything I can do to get sshd working from this kernel (and if so, what?), or is there something fundamentally wrong with the kernel configuration? Where did you start sshd, in the chrooted environment or on the live cd itself? My first thought as well... I'd guess, just at a glance, that sshd was started in the chroot, and that /mnt/gentoo/dev/ is bind mounted properly, but /mnt/gentoo/dev/pts/ isn't. As said, I fixed the problem by mounting /dev with --rbind. This misunderstanding cost me, perhaps, 10 hours of my time. I then reported my problem to the bug tracker, suggesting that the manual should be amended to say --rbind here. I really wish I hadn't bothered. My attempt to contribute was brusquely brushed aside by somebody who didn't even bother to thank me for my trouble (I always thank people reporting bugs to my project), said that he couldn't reproduce [my] error, and asserted that sshd wasn't meant to work in the chrooted environment (why on Earth not?), implying it was my stupid fault for not following the manual rigidly and droidwise. To cap it all, he patronisingly referred me to the appropriate sections of the fine manual (that's after my having reported how I'd already fixed the problem for me). See https://bugs.gentoo.org/show_bug.cgi?id=296073 Seems to me, reporting problems to Gentoo is a waste of time, at least documentation problems. -- Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] Re: went from x86 to ~x86: no more X11
On 12/08/2009 11:28 PM, Stefan G. Weichinger wrote: I tested DISPLAYMANAGER=xdm now, X is coming up and lets me log in ... but I only get some ugly and very simple desktop (xsm ...). This only as a test ... So it seems more gdm/gnome-related to me, right? That would be my guess. I don't use gdm so I don't know how to fix it. I use startx with exec /etc/X11/Sessions/gnome in my ~/.xinitrc. You could try that to see if gnome starts correctly.
Re: [gentoo-user] Problems setting up sshd on an installation kernel
On Wednesday 09 December 2009 17:24:16 Alan Mackenzie wrote: My first thought as well... I'd guess, just at a glance, that sshd was started in the chroot, and that /mnt/gentoo/dev/ is bind mounted properly, but /mnt/gentoo/dev/pts/ isn't. As said, I fixed the problem by mounting /dev with --rbind. This misunderstanding cost me, perhaps, 10 hours of my time. I then reported my problem to the bug tracker, suggesting that the manual should be amended to say --rbind here. I really wish I hadn't bothered. My attempt to contribute was brusquely brushed aside by somebody who didn't even bother to thank me for my trouble (I always thank people reporting bugs to my project), said that he couldn't reproduce [my] error, and asserted that sshd wasn't meant to work in the chrooted environment (why on Earth not?), implying it was my stupid fault for not following the manual rigidly and droidwise. To cap it all, he patronisingly referred me to the appropriate sections of the fine manual (that's after my having reported how I'd already fixed the problem for me). I can see his point of view, the chroot environment is something that exists only while doing the installation and as such is a temporary dodge so that you can do it. No binary distro runs sshd in the chroot it creates while performing the install either. The supported method is to ssh into the LiveCD environment then chroot from that shell. It's hard to imagine a scenario where you would have more than one user doing that at the same time, so why run sshd in the chroot at all? See https://bugs.gentoo.org/show_bug.cgi?id=296073 Seems to me, reporting problems to Gentoo is a waste of time, at least documentation problems. That is a classic case of applying a specific case to the general case. You had a problem with one specific dev regarding one specific bug relating to one specific piece of documentation. To then assert that contributing anything to any aspect of Gentoo documentation is pointless merely on the basis of one experience is disingenuous to say the least. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: went from x86 to ~x86: no more X11
Am 09.12.2009 16:31, schrieb walt: So it seems more gdm/gnome-related to me, right? That would be my guess. I don't use gdm so I don't know how to fix it. I use startx with exec /etc/X11/Sessions/gnome in my ~/.xinitrc. You could try that to see if gnome starts correctly. Yep, that works! So I could see how to always start X via startx or research where gdm fails. Thanks for helping me this step further ... S
Re: [gentoo-user] Problems setting up sshd on an installation kernel
Hi, Alan, Thanks for the quick reply. On Wed, Dec 09, 2009 at 05:43:50PM +0200, Alan McKinnon wrote: On Wednesday 09 December 2009 17:24:16 Alan Mackenzie wrote: My first thought as well... I'd guess, just at a glance, that sshd was started in the chroot, and that /mnt/gentoo/dev/ is bind mounted properly, but /mnt/gentoo/dev/pts/ isn't. As said, I fixed the problem by mounting /dev with --rbind. This misunderstanding cost me, perhaps, 10 hours of my time. I then reported my problem to the bug tracker, suggesting that the manual should be amended to say --rbind here. I really wish I hadn't bothered. My attempt to contribute was brusquely brushed aside by somebody who didn't even bother to thank me for my trouble (I always thank people reporting bugs to my project), said that he couldn't reproduce [my] error, and asserted that sshd wasn't meant to work in the chrooted environment (why on Earth not?), implying it was my stupid fault for not following the manual rigidly and droidwise. To cap it all, he patronisingly referred me to the appropriate sections of the fine manual (that's after my having reported how I'd already fixed the problem for me). I can see his point of view, the chroot environment is something that exists only while doing the installation and as such is a temporary dodge so that you can do it. No binary distro runs sshd in the chroot it creates while performing the install either. However, setting up /dev completely (with --rbind) costs nothing, adds capability, and takes nothing away. The supported method is to ssh into the LiveCD environment then chroot from that shell. It's hard to imagine a scenario where you would have more than one user doing that at the same time, so why run sshd in the chroot at all? If you run sshd in the bare installation (as suggested), the ssh client has to update his ~/.ssh/known_hosts every time the system is booted (what? There are people who only boot it once before getting Gentoo completely installed? ;-). When sshd'ing from within the chrooted environment, the ssh client has to add an entry to known_hosts just once, and this entry will persist even when the embryonic gentoo has been fully installed and configured. More to the point, though, is that the manual doesn't explicitly state that sshd must be started from outside the chroot. It sort of implies it, but doesn't emphasise it. Reading the manual, it was clear to me that it didn't matter (turns out I was wrong). Also, people are going to be running sshd on their own initiative, and it seems perverse knowingly to leave a hindrance on one of the two ways they'll choose to do it. This situation cost me around 10 hours of frustration. Looks like I'll not be the last victim. See https://bugs.gentoo.org/show_bug.cgi?id=296073 Seems to me, reporting problems to Gentoo is a waste of time, at least documentation problems. That is a classic case of applying a specific case to the general case. You had a problem with one specific dev regarding one specific bug relating to one specific piece of documentation. To then assert that contributing anything to any aspect of Gentoo documentation is pointless merely on the basis of one experience is disingenuous to say the least. What you write is indeed true, but only up to a point. I reported how things seem to me, and truly hope that my experience is not typical. By contrast, the posters on gentoo-user, including yourself, have been very helpful indeed. Thank you! -- alan dot mckinnon at gmail dot com -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Problems setting up sshd on an installation kernel
On Wednesday 09 December 2009 18:46:11 Alan Mackenzie wrote: The supported method is to ssh into the LiveCD environment then chroot from that shell. It's hard to imagine a scenario where you would have more than one user doing that at the same time, so why run sshd in the chroot at all? If you run sshd in the bare installation (as suggested), the ssh client has to update his ~/.ssh/known_hosts every time the system is booted (what? There are people who only boot it once before getting Gentoo completely installed? ;-). When sshd'ing from within the chrooted environment, the ssh client has to add an entry to known_hosts just once, and this entry will persist even when the embryonic gentoo has been fully installed and configured. More to the point, though, is that the manual doesn't explicitly state that sshd must be started from outside the chroot. It sort of implies it, but doesn't emphasise it. Reading the manual, it was clear to me that it didn't matter (turns out I was wrong). Also, people are going to be running sshd on their own initiative, and it seems perverse knowingly to leave a hindrance on one of the two ways they'll choose to do it. This situation cost me around 10 hours of frustration. Looks like I'll not be the last victim. All I can add is that if I were the maintainer, I wouldn't support what you are asking either. Installation is supposed to be an atomic operation - it starts then continues till it ends. It either fully completes or is considered to not have happened, meaning that persistence is diametrically opposed to what an install is. It's analogous to a compile - terminating compilation at some arbitrary point then picking up from where it ended at some later point is just not supported. Possible yes, but not supported by default. But it's easy to get what you want: take what is there, modify it and create a fork. You become the maintainer of the fork and can accept or decline suggestions as you see fit. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Problems setting up sshd on an installation kernel
On 9 Dec 2009, at 16:46, Alan Mackenzie wrote: ... (what? There are people who only boot it once before getting Gentoo completely installed? ;-). Yes, absolutely. I would consider this to be the normal scenario. When sshd'ing from within the chrooted environment, the ssh client has to add an entry to known_hosts just once, and this entry will persist even when the embryonic gentoo has been fully installed and configured. Well, it was totally worth wasting 10 hours of your time not to have to delete one line of a text file. ;) FWIW I have in .bashrc: alias ssg=ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/ dev/null I do totally sympathise with you on trying to open bugs improve Gentoo. I have been brushed off and received snotty responses from devs on a number of occasions. They're either a bunch of arrogant knobs, or they simply deal with bugs in a terse manner (which, totally unintended, happens to offend certain people such as you I). I suppose charitably we must assume the latter. Stroller.
Re: [gentoo-user] Problems setting up sshd on an installation kernel
On 9 Dec 2009, at 19:42, Alan McKinnon wrote: ... Installation is supposed to be an atomic operation - it starts then continues till it ends. It either fully completes or is considered to not have happened, meaning that persistence is diametrically opposed to what an install is. It's analogous to a compile - terminating compilation at some arbitrary point then picking up from where it ended at some later point is just not supported. Possible yes, but not supported by default. I'd disagree with you on that point, assuming I'm reading you right. If a compile fails it shouldn't be an unsupported situation. One should be able to reemerge the package, possibly after emerging a required dependency first. That should work just fine (and surely it always does?). Likewise it's not at all uncommon to make a mistake during the installation process - to miss out an essential kernel driver or package, and find that the installation fails to boot. The way I interpret your statement is that the supported remedy is to start again completely from scratch. Clearly this is not what one does - one boots again with the LiveCD, chroots into the installation, makes the fix and then reboots again to see if the system is now fixed. Every new Gentoo user has to do this a number of times, it is our standard advice to them, and we, as experienced users, will still have to do the same thing occasionally due to our own oversights. However, I would agree with you that resolving Alan Mackenzie's problems with ssh should not be a priority. The standard procedure should be written for a user sitting in front of the machine on which Gentoo is being installed. Installing via SSH is an advanced procedure and should be considered to be undertaken by users who know what they're doing. The requirement to rarely remove a line from ~/.ssh/known_hosts is really not much hassle. I am somewhat surprised that Mr Mackenzie managed to waste as much time as 10 hours attempting to SSH into the wrong environment, as it has never occurred to me to do it that way around, and Florian posted appropriate advice to resolve the problem less than 2 hours after Alan's original post. I think this is typical of the kind of mistake we all make and learn from - we have all wasted 10 hours on some occasion, only to kick ourselves afterwards. When we do this we learn never again to make the same mistake. On 9 Dec 2009, at 16:46, Alan Mackenzie wrote: However, setting up /dev completely (with --rbind) costs nothing, adds capability, and takes nothing away. It is not clear to me that this is the obvious and optimal solution. It may be. I cannot foresee whether it may introduce side- effects. Stroller.
[gentoo-user] 2.6.31 vfat driver broken?
Hi guys n gals I use FAT32 on my external HDDs to make it easier to share with other people and OSes. Never had a problem before, but now I do. Lately, when I save videos to my disks, and play them back after the file system cache is emptied, they have completely different content (of files that are long deleted). I just had the magnificent idea to look into the syslog and found loads of kernel: bio too big device sdb (248 240) I heard romours of problems with the current FAT implementation due to M$. I went back to 2.6.30 for the moment. So what’s your proposal? Usually I don’t have the need for übercurrent kernels, but would installing 2.6.32 help? TIA -- Gruß | Greetings | Qapla' LCARS - Linux Can Also Run Starships signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Problems setting up sshd on an installation kernel
On Wednesday 09 December 2009 23:57:18 Stroller wrote: On 9 Dec 2009, at 19:42, Alan McKinnon wrote: ... Installation is supposed to be an atomic operation - it starts then continues till it ends. It either fully completes or is considered to not have happened, meaning that persistence is diametrically opposed to what an install is. It's analogous to a compile - terminating compilation at some arbitrary point then picking up from where it ended at some later point is just not supported. Possible yes, but not supported by default. I'd disagree with you on that point, assuming I'm reading you right. If a compile fails it shouldn't be an unsupported situation. One should be able to reemerge the package, possibly after emerging a required dependency first. That should work just fine (and surely it always does?). I made an analogy, a poor one :-), which only goes as far as it goes (and that's not very far). I meant that if gcc is running and compiling some arbitrary .c and you hit ^C, there's no magic incantation to tell gcc to find what it was doing and continue from that point as if the interruption never happened. Likewise with installation - you can't just decide to stop halfway, shut the box down and continue tomorrow expecting the software to pick up where you left off automagically (without you having to do anything extra). Consider *any* installation media of your choice for *any* OS; none of them that I have ever used allow you to interrupt the install and continue later. I see no reason why the install dev and the doc dev should support such a feat on Gentoo even if it is technically feasible. Likewise it's not at all uncommon to make a mistake during the installation process - to miss out an essential kernel driver or package, and find that the installation fails to boot. The way I interpret your statement is that the supported remedy is to start again completely from scratch. Clearly this is not what one does Correct, one normally redoes the setup commands: boot, mkdir, mount, mkmoredirs, more mount, mount proc, chroot, cp resolv.conf etc etc etc and continue. This only works because any data written to the disk during $INSTALL_ATTEMPT_1 is persistent by virtue of it being written to *disk*. And there is no need to untar a stage all over again. By happy coincidence, oftentimes after chrooting one finds an environment that has everything required to run sshd, but there is no guarantee of that at all. So one can try start sshd, if it works then all well and good, if not then that's tough. Either way the human running the show is on his own with this one. I still maintain that the doc dev is correct in refusing to document such a thing - it's way too unreliable and uncertain to even warrant a mention. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Problems setting up sshd on an installation kernel
Hi, Alan, On Wed, Dec 09, 2009 at 09:42:56PM +0200, Alan McKinnon wrote: On Wednesday 09 December 2009 18:46:11 Alan Mackenzie wrote: The supported method is to ssh into the LiveCD environment then chroot from that shell. It's hard to imagine a scenario where you would have more than one user doing that at the same time, so why run sshd in the chroot at all? If you run sshd in the bare installation (as suggested), the ssh client has to update his ~/.ssh/known_hosts every time the system is booted (what? There are people who only boot it once before getting Gentoo completely installed? ;-). When sshd'ing from within the chrooted environment, the ssh client has to add an entry to known_hosts just once, and this entry will persist even when the embryonic gentoo has been fully installed and configured. More to the point, though, is that the manual doesn't explicitly state that sshd must be started from outside the chroot. It sort of implies it, but doesn't emphasise it. Reading the manual, it was clear to me that it didn't matter (turns out I was wrong). Also, people are going to be running sshd on their own initiative, and it seems perverse knowingly to leave a hindrance on one of the two ways they'll choose to do it. This situation cost me around 10 hours of frustration. Looks like I'll not be the last victim. All I can add is that if I were the maintainer, I wouldn't support what you are asking either. What you seem to be missing is that this change COSTS NOTHING, bar the time it takes to change a few bytes of source code, recompile and commit. Nothing which previously worked would cease to work, and the amount of support required would decrease or stay the same. Installation is supposed to be an atomic operation - it starts then continues till it ends. It either fully completes or is considered to not have happened, meaning that persistence is diametrically opposed to what an install is. OK, we don't live on the same planet. I have never completed a Linux installation in a single sitting, and don't expect ever to do so. Particularly on a distribution like Gentoo where so much has to be done by hand. (That's not a criticism, by the way. It's one of the things which has attracted me to Gentoo.) You and others around this list might be supermen, I'm not, and I feel no shame about it. It's analogous to a compile - terminating compilation at some arbitrary point then picking up from where it ended at some later point is just not supported. That analogy is so week as to be meaningless. Installation, unlike compilation, consists of a large number of discrete manual steps, and it is silly to suggest that if you don't finish by bedtime you should wipe the hard drive and start again from scratch when you get up in the morning. Possible yes, but not supported by default. The manual neither states nor implies that you've got to finish at one sitting. The only difficulty, and it's not much of one, is working out how to restart in the middle. Hey, even I managed that. But it's easy to get what you want: take what is there, modify it and create a fork. You become the maintainer of the fork and can accept or decline suggestions as you see fit. Oh, that old stuff. No thanks, Alan, I've got quite enough to do supporting my own project (Emacs CC Mode). I'll just carry on with my own way of doing things, supported or not. I'll keep my bright ideas and customer feedback to myself from now on, since nobody here seems to want them. But I'll ask for help when I need it - you guys are great at helping, and that's most appreciated. Thanks for the chat, and good night for now! -- alan dot mckinnon at gmail dot com -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Problems setting up sshd on an installation kernel
Stroller wrote: On 9 Dec 2009, at 16:46, Alan Mackenzie wrote: ... (what? There are people who only boot it once before getting Gentoo completely installed? ;-). Yes, absolutely. I would consider this to be the normal scenario. +1 I have done that several times, even over ssh to another country. When sshd'ing from within the chrooted environment, the ssh client has to add an entry to known_hosts just once, and this entry will persist even when the embryonic gentoo has been fully installed and configured. Well, it was totally worth wasting 10 hours of your time not to have to delete one line of a text file. ;) FWIW I have in .bashrc: alias ssg=ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null I do totally sympathise with you on trying to open bugs improve Gentoo. I have been brushed off and received snotty responses from devs on a number of occasions. They're either a bunch of arrogant knobs, or they simply deal with bugs in a terse manner (which, totally unintended, happens to offend certain people such as you I). I suppose charitably we must assume the latter. Stroller. +1 here too. I haven't filed a bug in a while although I have found a couple. I also very rarely post on -dev. I learned that if you don't say anything, they don't know you are there to bite on. ;-) Sort of like a fly on the wall. Dale :-) :-)
[gentoo-user] problem with install-x86-minimal-20091103
Hello, I just burned the install-x86-minimal-20091103 iso on a cd and tried to boot a relatively old machine with it. Here is where it stops Mounting the squashfs filesystem mount: mounting /dev/loop0 on /newroot/mnt/livecd failed: Invalid argument !! Failed to $1; failing back to the shell... Also, somewhere at the top of the screen output during the boot process it says this is a LiveCD? I am confused here. Wasn't the minimal iso not Live in the past? Thanks for inputs. -- Valmor
Re: [gentoo-user] Re: went from x86 to ~x86: no more X11
On Wed, Dec 9, 2009 at 11:22 AM, Stefan G. Weichinger li...@xunil.at wrote:
Am 09.12.2009 16:31, schrieb walt:
So it seems more gdm/gnome-related to me, right?
That would be my guess. I don't use gdm so I don't know how to fix it.
I use startx with exec /etc/X11/Sessions/gnome in my ~/.xinitrc. You
could try that to see if gnome starts correctly.
Yep, that works!
So I could see how to always start X via startx or research where gdm
fails. Thanks for helping me this step further ...
S
Well, on my netbook, where I have to give a passphrase to access the
encrypted root anyhow (and am, therefore, not terribly interested in
typing yet more passwords moments later), I have this...
in /etc/inittab:
...
c6:2345:respawn:/sbin/agetty 38400 tty6 linux
c7:345:respawn:/usr/sbin/auto_start_x.sh
...
and /usr/sbin/auto_start_x.sh:
#!/bin/bash
ASXFILE=/var/run/asx.pid
if [ ! -r /etc/nologin ] ; then
if [ -f $ASXFILE ] ; then
XPID=`head -1 $ASXFILE`
if NAME=`ps -p $XPID -o command=` ; then
OLDNAME=`tail -1 $ASXFILE`
if [ $NAME == $OLDNAME ] ; then
sleep 5
exit 1
else
rm -f $ASXFILE /dev/null
fi
else
rm -f $ASXFILE /dev/null
fi
fi
/bin/su myuser -l -c startx /dev/null 21
XPID=$!
NAME=`ps -p $XPID -o command=`
echo $XPID $ASXFILE
echo $NAME $ASXFILE
wait $XPID
exit $?
fi
# ** End auto_start_x.sh
Respawns on close/crash... doesn't allow attempts to start more than
once (hence the 'lockfile' type hack in the script), doesn't break on
a stale lockfile, and does whatever the user ('myuser' should be
replaced with a real username) wishes in terms of WM/desktop by way of
the user's ~/.xinitrc ... and all without ever asking me for a user
password.
--
Poison [BLX]
Joshua M. Murphy
Re: [gentoo-user] Problems setting up sshd on an installation kernel
On 9 Dec 2009, at 22:35, Alan Mackenzie wrote: ... Installation is supposed to be an atomic operation - it starts then continues till it ends. It either fully completes or is considered to not have happened, meaning that persistence is diametrically opposed to what an install is. OK, we don't live on the same planet. I have never completed a Linux installation in a single sitting, and don't expect ever to do so. Particularly on a distribution like Gentoo where so much has to be done by hand. (That's not a criticism, by the way. It's one of the things which has attracted me to Gentoo.) You and others around this list might be supermen, I'm not, and I feel no shame about it. You only chroot after untarring the stage 3. When you do chroot then you emerge grub, the kernel and add sshd to the default runlevel. Remove the live CD, reboot. Job done. Obviously there's a lot more to do after this to get a *fully working* operating system, but you should by this stage now be able to boot from the hard-drive into your embryonic system, and from there you can add a user, a system logger, cron, perform updates c. Stroller.
Re: [gentoo-user] problem with install-x86-minimal-20091103
On 10 Dec 2009, at 03:07, Valmor de Almeida wrote: ... I just burned the install-x86-minimal-20091103 iso on a cd and tried to boot a relatively old machine with it. Here is where it stops ... Have you tried SystemRescueCD? http://www.sysresccd.org/Download Also, somewhere at the top of the screen output during the boot process it says this is a LiveCD? I am confused here. Wasn't the minimal iso not Live in the past? I think this may depend upon your definition of a LiveCD. To me it is an operating system which boots from CD which requires no hard- drive. Stroller.
