Re: Some issues on fresh installed Debian-Hurd
Justus Winter, le Mon 02 Jun 2014 12:22:36 +0200, a écrit : Quoting Jens Rehsack (2014-06-02 11:46:10) Am 02.06.2014 um 11:21 schrieb Justus Winter 4win...@informatik.uni-hamburg.de: Quoting Jens Rehsack (2014-06-02 10:58:17) Am 02.06.2014 um 10:47 schrieb Justus Winter 4win...@informatik.uni-hamburg.de: Hi :) Quoting Jens Rehsack (2014-06-02 08:28:50) Beside the kernel choice the installation went smoothly (a problem Debian-Hurd shares with Debian-kFreeBSD ^^). I don't follow. I most likely pebcak :) Generally it's (for me) poorly documented which kernel is meant by hurd-1 vs. hurd-1.3.nnn I got it later by doing apt-cache search (but initial boot was with 1.3.nnn) I still don't follow. Hurd is not a kernel. There is no package hurd-1 or hurd-1.3.nnn. Ok - what I was talking about (and I'm sure the installer named it kernel or with a similar term) was gnumach-image-1.3.99-486 vs. gnumach-image-1.4-486 Fair enough. Gnumach is our kernel allright. I wonder why 1.3.99 is still available. Samuel? Remember that he installed from the 2013 image, so that kernel got installed, before installing the 1.4 version on upgrade, and Debian doesn't remove old kernels. Grub should have put them in the 1.4 then 1.3.99 order, though. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140604061139.GE4983@type
Re: Some issues on fresh installed Debian-Hurd
Hi :) Quoting Jens Rehsack (2014-06-02 08:28:50) Beside the kernel choice the installation went smoothly (a problem Debian-Hurd shares with Debian-kFreeBSD ^^). I don't follow. I had to modify line 117 in /etc/hurd/rc: settrans -c /proc /hurd/procfs --compatible - settrans -c /proc /hurd/procfs, otherwise the /proc file system didn't came up. That reduces the noise during boot dramatically (cannot stat /proc or something like that). Which is very strange, as we switched to sysv-rc and don't use /etc/hurd/rc no more. Could you please double check that (e.g. update-alternatives --display runsystem should say /etc/hurd/runsystem.sysv). But still (the VM is 06:03:47 up 3 days, 10:16) the console (xl vncviewer) doesn't come to a prompt. OpenSSH-Server runs, so I can access remotely. I'm quite unsure if it has to do with procfs or another issue (nothing suspicious in log or on screen) - but I'd like to mention it. Check that the hurd console is running. Also, check that you have an entry like c:23:respawn:/sbin/getty 38400 console in your /etc/inittab to get a getty on the mach console (of course inittab is only used if you use sysvinit). Cheers, Justus -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140602084703.10651.90...@thinkbox.jade-hamburg.de
Re: Some issues on fresh installed Debian-Hurd
Am 02.06.2014 um 10:47 schrieb Justus Winter 4win...@informatik.uni-hamburg.de: Hi :) Quoting Jens Rehsack (2014-06-02 08:28:50) Beside the kernel choice the installation went smoothly (a problem Debian-Hurd shares with Debian-kFreeBSD ^^). I don't follow. I most likely pebcak :) Generally it's (for me) poorly documented which kernel is meant by hurd-1 vs. hurd-1.3.nnn I got it later by doing apt-cache search (but initial boot was with 1.3.nnn) Same at kFreeBSD - it's for first attempt unclear whether kernel-8 is favored over kernel (and which version is kernel - 8+patches, 9, ???) Enlightening comes later by trying it out ... But beside that - Hurd installation was impressive sane for experimental why kFreeBSD crashs because it always installs 9'er kernel (regardless the choice I make at installer - but maybe PEBCAK, let's do Hurd first). I had to modify line 117 in /etc/hurd/rc: settrans -c /proc /hurd/procfs --compatible - settrans -c /proc /hurd/procfs, otherwise the /proc file system didn't came up. That reduces the noise during boot dramatically (cannot stat /proc or something like that). Which is very strange, as we switched to sysv-rc and don't use /etc/hurd/rc no more. Could you please double check that (e.g. update-alternatives --display runsystem should say /etc/hurd/runsystem.sysv). # update-alternatives --display runsystem runsystem - auto mode link currently points to /etc/hurd/runsystem.sysv /etc/hurd/runsystem.gnu - priority 5 slave halt: /sbin/halt-hurd slave reboot: /sbin/reboot-hurd /etc/hurd/runsystem.sysv - priority 10 slave halt: /sbin/halt-sysv slave reboot: /sbin/reboot-sysv Current 'best' version is '/etc/hurd/runsystem.sysv'. I cannot say why no proc was mounted before I removed --compatible when /etc/hurd/rc isn't used. But it works (proved by visual examination ^^) Maybe we should first check why /etc/hurd/rc is involved in boot-process? But still (the VM is 06:03:47 up 3 days, 10:16) the console (xl vncviewer) doesn't come to a prompt. OpenSSH-Server runs, so I can access remotely. I'm quite unsure if it has to do with procfs or another issue (nothing suspicious in log or on screen) - but I'd like to mention it. Check that the hurd console is running. Also, check that you have an entry like c:23:respawn:/sbin/getty 38400 console in your /etc/inittab to get a getty on the mach console (of course inittab is only used if you use sysvinit). I have some lines looking similar (was 'c' a placeholder for [1-9]?) 1:2345:respawn:/sbin/getty 38400 tty1 2:23:respawn:/sbin/getty 38400 tty2 3:23:respawn:/sbin/getty 38400 tty3 Cheers -- Jens Rehsack rehs...@gmail.com -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/75f9eaa1-38ed-46b6-b499-7880a5bf1...@gmail.com
Re: Some issues on fresh installed Debian-Hurd
Quoting Jens Rehsack (2014-06-02 10:58:17) Am 02.06.2014 um 10:47 schrieb Justus Winter 4win...@informatik.uni-hamburg.de: Hi :) Quoting Jens Rehsack (2014-06-02 08:28:50) Beside the kernel choice the installation went smoothly (a problem Debian-Hurd shares with Debian-kFreeBSD ^^). I don't follow. I most likely pebcak :) Generally it's (for me) poorly documented which kernel is meant by hurd-1 vs. hurd-1.3.nnn I got it later by doing apt-cache search (but initial boot was with 1.3.nnn) I still don't follow. Hurd is not a kernel. There is no package hurd-1 or hurd-1.3.nnn. Same at kFreeBSD - it's for first attempt unclear whether kernel-8 is favored over kernel (and which version is kernel - 8+patches, 9, ???) Enlightening comes later by trying it out ... But beside that - Hurd installation was impressive sane for experimental why kFreeBSD crashs because it always installs 9'er kernel (regardless the choice I make at installer - but maybe PEBCAK, let's do Hurd first). I had to modify line 117 in /etc/hurd/rc: settrans -c /proc /hurd/procfs --compatible - settrans -c /proc /hurd/procfs, otherwise the /proc file system didn't came up. That reduces the noise during boot dramatically (cannot stat /proc or something like that). Which is very strange, as we switched to sysv-rc and don't use /etc/hurd/rc no more. Could you please double check that (e.g. update-alternatives --display runsystem should say /etc/hurd/runsystem.sysv). # update-alternatives --display runsystem runsystem - auto mode link currently points to /etc/hurd/runsystem.sysv /etc/hurd/runsystem.gnu - priority 5 slave halt: /sbin/halt-hurd slave reboot: /sbin/reboot-hurd /etc/hurd/runsystem.sysv - priority 10 slave halt: /sbin/halt-sysv slave reboot: /sbin/reboot-sysv Current 'best' version is '/etc/hurd/runsystem.sysv'. I cannot say why no proc was mounted before I removed --compatible when /etc/hurd/rc isn't used. But it works (proved by visual examination ^^) Also, --compatible is a valid argument and it is recommended to use that for compatibility with Linux' /proc. There is no reason to believe it should cause any trouble. Maybe we should first check why /etc/hurd/rc is involved in boot-process? Yes. Add exit 0 at the top. It is not used. But still (the VM is 06:03:47 up 3 days, 10:16) the console (xl vncviewer) doesn't come to a prompt. OpenSSH-Server runs, so I can access remotely. I'm quite unsure if it has to do with procfs or another issue (nothing suspicious in log or on screen) - but I'd like to mention it. Check that the hurd console is running. Also, check that you have an entry like c:23:respawn:/sbin/getty 38400 console in your /etc/inittab to get a getty on the mach console (of course inittab is only used if you use sysvinit). I have some lines looking similar (was 'c' a placeholder for [1-9]?) 1:2345:respawn:/sbin/getty 38400 tty1 2:23:respawn:/sbin/getty 38400 tty2 3:23:respawn:/sbin/getty 38400 tty3 No it's not. Apparently, 'c' is a valid identifier. If you have no getty for the console, please add it. ttyX is used when the Hurd console is running, 'console' refers to the mach console. Justus -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140602092118.10651.4...@thinkbox.jade-hamburg.de
Re: Some issues on fresh installed Debian-Hurd
Am 02.06.2014 um 11:21 schrieb Justus Winter 4win...@informatik.uni-hamburg.de: Quoting Jens Rehsack (2014-06-02 10:58:17) Am 02.06.2014 um 10:47 schrieb Justus Winter 4win...@informatik.uni-hamburg.de: Hi :) Quoting Jens Rehsack (2014-06-02 08:28:50) Beside the kernel choice the installation went smoothly (a problem Debian-Hurd shares with Debian-kFreeBSD ^^). I don't follow. I most likely pebcak :) Generally it's (for me) poorly documented which kernel is meant by hurd-1 vs. hurd-1.3.nnn I got it later by doing apt-cache search (but initial boot was with 1.3.nnn) I still don't follow. Hurd is not a kernel. There is no package hurd-1 or hurd-1.3.nnn. Ok - what I was talking about (and I'm sure the installer named it kernel or with a similar term) was gnumach-image-1.3.99-486 vs. gnumach-image-1.4-486 Same at kFreeBSD - it's for first attempt unclear whether kernel-8 is favored over kernel (and which version is kernel - 8+patches, 9, ???) Enlightening comes later by trying it out ... But beside that - Hurd installation was impressive sane for experimental why kFreeBSD crashs because it always installs 9'er kernel (regardless the choice I make at installer - but maybe PEBCAK, let's do Hurd first). I had to modify line 117 in /etc/hurd/rc: settrans -c /proc /hurd/procfs --compatible - settrans -c /proc /hurd/procfs, otherwise the /proc file system didn't came up. That reduces the noise during boot dramatically (cannot stat /proc or something like that). Which is very strange, as we switched to sysv-rc and don't use /etc/hurd/rc no more. Could you please double check that (e.g. update-alternatives --display runsystem should say /etc/hurd/runsystem.sysv). # update-alternatives --display runsystem runsystem - auto mode link currently points to /etc/hurd/runsystem.sysv /etc/hurd/runsystem.gnu - priority 5 slave halt: /sbin/halt-hurd slave reboot: /sbin/reboot-hurd /etc/hurd/runsystem.sysv - priority 10 slave halt: /sbin/halt-sysv slave reboot: /sbin/reboot-sysv Current 'best' version is '/etc/hurd/runsystem.sysv'. I cannot say why no proc was mounted before I removed --compatible when /etc/hurd/rc isn't used. But it works (proved by visual examination ^^) Also, --compatible is a valid argument and it is recommended to use that for compatibility with Linux' /proc. There is no reason to believe it should cause any trouble. I cannot tell why it caused trouble - but now after I uninstalled gnumach-image-1.3.99-486 the issue disappears. Maybe we should first check why /etc/hurd/rc is involved in boot-process? Yes. Add exit 0 at the top. It is not used. Done without harming anything - seems to have a relation to gnumach-image-1.3.99-486 But still (the VM is 06:03:47 up 3 days, 10:16) the console (xl vncviewer) doesn't come to a prompt. OpenSSH-Server runs, so I can access remotely. I'm quite unsure if it has to do with procfs or another issue (nothing suspicious in log or on screen) - but I'd like to mention it. Check that the hurd console is running. Also, check that you have an entry like c:23:respawn:/sbin/getty 38400 console in your /etc/inittab to get a getty on the mach console (of course inittab is only used if you use sysvinit). I have some lines looking similar (was 'c' a placeholder for [1-9]?) 1:2345:respawn:/sbin/getty 38400 tty1 2:23:respawn:/sbin/getty 38400 tty2 3:23:respawn:/sbin/getty 38400 tty3 No it's not. Apparently, 'c' is a valid identifier. If you have no getty for the console, please add it. ttyX is used when the Hurd console is running, 'console' refers to the mach console. Added and there is a login :) From original mail now only the nfs issue remains. Playing around I see differences between $ mount # no output, returns immediately # mount typed:device:hd0s1 on / type ext2fs (rw,no-inherit-dir-group) # cat /proc/mounts /dev/hd0s1 / ext2fs writable,no-inherit-dir-group,store-type=typed 0 0 none /run /hurd/tmpfs writable,no-suid,no-exec,no-inherit-dir-group,no-sync,size=102148K 0 0 none /run/lock /hurd/tmpfs writable,no-suid,no-exec,no-inherit-dir-group,no-sync,size=5M 0 0 none /run/shm /hurd/tmpfs writable,no-suid,no-exec,no-inherit-dir-group,no-sync,size=613980K 0 0 waldorf:/data/pkgsrc /data/pkgsrc /hurd/nfs hard,read-size=8192,write-size=8192,stat-timeout=3,cache-timeout=3,init-transmit-timeout=1,max-transmit-timeout=30,name-cache-timeout=3,name-cache-neg-timeout=3 0 0 Is there any reason for it? BTW: why I initially assumed the is a problem with the way mounting /proc: # top Error, do this: mount -t proc proc /proc Cheers -- Jens Rehsack rehs...@gmail.com -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ff75fc0e-2d6c-466a-96a2-39cbb538a...@gmail.com
Re: Some issues on fresh installed Debian-Hurd
Quoting Jens Rehsack (2014-06-02 11:46:10) Am 02.06.2014 um 11:21 schrieb Justus Winter 4win...@informatik.uni-hamburg.de: Quoting Jens Rehsack (2014-06-02 10:58:17) Am 02.06.2014 um 10:47 schrieb Justus Winter 4win...@informatik.uni-hamburg.de: Hi :) Quoting Jens Rehsack (2014-06-02 08:28:50) Beside the kernel choice the installation went smoothly (a problem Debian-Hurd shares with Debian-kFreeBSD ^^). I don't follow. I most likely pebcak :) Generally it's (for me) poorly documented which kernel is meant by hurd-1 vs. hurd-1.3.nnn I got it later by doing apt-cache search (but initial boot was with 1.3.nnn) I still don't follow. Hurd is not a kernel. There is no package hurd-1 or hurd-1.3.nnn. Ok - what I was talking about (and I'm sure the installer named it kernel or with a similar term) was gnumach-image-1.3.99-486 vs. gnumach-image-1.4-486 Fair enough. Gnumach is our kernel allright. I wonder why 1.3.99 is still available. Samuel? ` Same at kFreeBSD - it's for first attempt unclear whether kernel-8 is favored over kernel (and which version is kernel - 8+patches, 9, ???) Enlightening comes later by trying it out ... But beside that - Hurd installation was impressive sane for experimental why kFreeBSD crashs because it always installs 9'er kernel (regardless the choice I make at installer - but maybe PEBCAK, let's do Hurd first). I had to modify line 117 in /etc/hurd/rc: settrans -c /proc /hurd/procfs --compatible - settrans -c /proc /hurd/procfs, otherwise the /proc file system didn't came up. That reduces the noise during boot dramatically (cannot stat /proc or something like that). Which is very strange, as we switched to sysv-rc and don't use /etc/hurd/rc no more. Could you please double check that (e.g. update-alternatives --display runsystem should say /etc/hurd/runsystem.sysv). # update-alternatives --display runsystem runsystem - auto mode link currently points to /etc/hurd/runsystem.sysv /etc/hurd/runsystem.gnu - priority 5 slave halt: /sbin/halt-hurd slave reboot: /sbin/reboot-hurd /etc/hurd/runsystem.sysv - priority 10 slave halt: /sbin/halt-sysv slave reboot: /sbin/reboot-sysv Current 'best' version is '/etc/hurd/runsystem.sysv'. I cannot say why no proc was mounted before I removed --compatible when /etc/hurd/rc isn't used. But it works (proved by visual examination ^^) Also, --compatible is a valid argument and it is recommended to use that for compatibility with Linux' /proc. There is no reason to believe it should cause any trouble. I cannot tell why it caused trouble - but now after I uninstalled gnumach-image-1.3.99-486 the issue disappears. Maybe we should first check why /etc/hurd/rc is involved in boot-process? Yes. Add exit 0 at the top. It is not used. Done without harming anything - seems to have a relation to gnumach-image-1.3.99-486 But still (the VM is 06:03:47 up 3 days, 10:16) the console (xl vncviewer) doesn't come to a prompt. OpenSSH-Server runs, so I can access remotely. I'm quite unsure if it has to do with procfs or another issue (nothing suspicious in log or on screen) - but I'd like to mention it. Check that the hurd console is running. Also, check that you have an entry like c:23:respawn:/sbin/getty 38400 console in your /etc/inittab to get a getty on the mach console (of course inittab is only used if you use sysvinit). I have some lines looking similar (was 'c' a placeholder for [1-9]?) 1:2345:respawn:/sbin/getty 38400 tty1 2:23:respawn:/sbin/getty 38400 tty2 3:23:respawn:/sbin/getty 38400 tty3 No it's not. Apparently, 'c' is a valid identifier. If you have no getty for the console, please add it. ttyX is used when the Hurd console is running, 'console' refers to the mach console. Added and there is a login :) Good. That means (most likely), that your hurd console isn't running. From original mail now only the nfs issue remains. Our nfs client is likely just crappy. Playing around I see differences between $ mount # no output, returns immediately # mount typed:device:hd0s1 on / type ext2fs (rw,no-inherit-dir-group) # cat /proc/mounts /dev/hd0s1 / ext2fs writable,no-inherit-dir-group,store-type=typed 0 0 none /run /hurd/tmpfs writable,no-suid,no-exec,no-inherit-dir-group,no-sync,size=102148K 0 0 none /run/lock /hurd/tmpfs writable,no-suid,no-exec,no-inherit-dir-group,no-sync,size=5M 0 0 none /run/shm /hurd/tmpfs writable,no-suid,no-exec,no-inherit-dir-group,no-sync,size=613980K 0 0 waldorf:/data/pkgsrc /data/pkgsrc /hurd/nfs hard,read-size=8192,write-size=8192,stat-timeout=3,cache-timeout=3,init-transmit-timeout=1,max-transmit-timeout=30,name-cache-timeout=3,name-cache-neg-timeout=3 0 0 Is there any reason for it? Hurd's mount simply does not work like Linux' mount. Our mount doesn't
Re: Some issues on fresh installed Debian-Hurd
Am 02.06.2014 um 12:22 schrieb Justus Winter 4win...@informatik.uni-hamburg.de: Quoting Jens Rehsack (2014-06-02 11:46:10) Am 02.06.2014 um 11:21 schrieb Justus Winter 4win...@informatik.uni-hamburg.de: [...] Ok - what I was talking about (and I'm sure the installer named it kernel or with a similar term) was gnumach-image-1.3.99-486 vs. gnumach-image-1.4-486 Fair enough. Gnumach is our kernel allright. I wonder why 1.3.99 is still available. Samuel? ` [...] No it's not. Apparently, 'c' is a valid identifier. If you have no getty for the console, please add it. ttyX is used when the Hurd console is running, 'console' refers to the mach console. Added and there is a login :) Good. That means (most likely), that your hurd console isn't running. Didn't got installed ... Now it's running ;) From original mail now only the nfs issue remains. Our nfs client is likely just crappy. Playing around I see differences between $ mount # no output, returns immediately # mount typed:device:hd0s1 on / type ext2fs (rw,no-inherit-dir-group) # cat /proc/mounts /dev/hd0s1 / ext2fs writable,no-inherit-dir-group,store-type=typed 0 0 none /run /hurd/tmpfs writable,no-suid,no-exec,no-inherit-dir-group,no-sync,size=102148K 0 0 none /run/lock /hurd/tmpfs writable,no-suid,no-exec,no-inherit-dir-group,no-sync,size=5M 0 0 none /run/shm /hurd/tmpfs writable,no-suid,no-exec,no-inherit-dir-group,no-sync,size=613980K 0 0 waldorf:/data/pkgsrc /data/pkgsrc /hurd/nfs hard,read-size=8192,write-size=8192,stat-timeout=3,cache-timeout=3,init-transmit-timeout=1,max-transmit-timeout=30,name-cache-timeout=3,name-cache-neg-timeout=3 0 0 Is there any reason for it? Hurd's mount simply does not work like Linux' mount. Our mount doesn't parse /proc/mounts. It should do so, if only to avoid this reoccurring confusion. BTW: why I initially assumed the is a problem with the way mounting /proc: # top Error, do this: mount -t proc proc /proc At this point, did you verify that /proc is mounted at all? But indeed: $ mount -t proc proc ./foo procfs: Too many arguments Try `procfs --help' or `procfs --usage' for more information. mount: cannot start translator /hurd/procfs: Translator died Finally there is something - even if I don't know what: # ls -l /proc | wc -l 75 # cat /proc/1/cmdline init [2] So it seems to me something what feels like a procfs is there - but what ;) But /proc/mounts doesn't show itself (what else could be missing?) Cheers -- Jens Rehsack rehs...@gmail.com -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/37cfdd1f-585f-44c3-bed7-e202a0680...@gmail.com
