Re: [lfs-support] Can't login after boot, typing keyboard doesn't display any character on console, why?
Il 30 dic 2016 5:02 AM, "ssmtpmailtesting ssmtpmailtesting" < ssmtpmailtest...@gmail.com> ha scritto: > > cat /etc/inittab > # Begin /etc/inittab > > id:3:initdefault: > > si::sysinit:/etc/rc.d/init.d/rc S > > l0:0:wait:/etc/rc.d/init.d/rc 0 > l1:S1:wait:/etc/rc.d/init.d/rc 1 > l2:2:wait:/etc/rc.d/init.d/rc 2 > l3:3:wait:/etc/rc.d/init.d/rc 3 > l4:4:wait:/etc/rc.d/init.d/rc 4 > l5:5:wait:/etc/rc.d/init.d/rc 5 > l6:6:wait:/etc/rc.d/init.d/rc 6 > > ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now > > su:S016:once:/sbin/sulogin > > 1:2345:respawn:/sbin/agetty --noclear tty1 9600 > 2:2345:respawn:/sbin/agetty tty2 9600 > 3:2345:respawn:/sbin/agetty tty3 9600 > 4:2345:respawn:/sbin/agetty tty4 9600 > 5:2345:respawn:/sbin/agetty tty5 9600 > 6:2345:respawn:/sbin/agetty tty6 9600 > > # End /etc/inittab > > There is no /etc/rc.d folder though. After booting the kernel it says: there is no /etc/rc.d/init.d/rc > > On Fri, Dec 30, 2016 at 9:57 AM, ssmtpmailtesting ssmtpmailtesting < ssmtpmailtest...@gmail.com> wrote: >> >> I looks, kernel is booting well. Mounted rootfs(ext4). I got the login prompt as: (none) login: , if I type username there, characters are not displayed there. It's not doing anything from there. I think, system is freezed. >> >> cat /etc/sysconfig/console: >> KEYMAP="us" >> FONT="lat1-16 -m 8859-1" >> >> I didn't install this: http://www.linuxfromscratch.org/lfs/view/stable/chapter07/bootscripts.html >> >> cat /etc/sysconfig/ifconfig.eth0 >> >> ONBOOT=yes >> IFACE=eth0 >> SERVICE=ipv4-static >> IP=192.168.1.2 >> GATEWAY=192.168.1.1 >> PREFIX=24 >> BROADCAST=192.168.1.255 >> >> (none) login: prompt was before. I was able to login before without installing lfs bootscripts. But I recompiled the kernel, then tried again to change the (none) login: to mybox login: prompt. Now can't type anything and can't login. >> >> cat /etc/hostname >> mybox >> >> What can be the problem? What should I do? > > How did you manage to finish the system in less then a week? did you follow all the book? The problem might be in /etc/passwd /etc/group or /etc/passwd > > -- > http://lists.linuxfromscratch.org/listinfo/lfs-support > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page > > Do not top post on this list. > > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > > http://en.wikipedia.org/wiki/Posting_style > -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Can't login after boot, typing keyboard doesn't display any character on console, why?
cat /etc/inittab # Begin /etc/inittab id:3:initdefault: si::sysinit:/etc/rc.d/init.d/rc S l0:0:wait:/etc/rc.d/init.d/rc 0 l1:S1:wait:/etc/rc.d/init.d/rc 1 l2:2:wait:/etc/rc.d/init.d/rc 2 l3:3:wait:/etc/rc.d/init.d/rc 3 l4:4:wait:/etc/rc.d/init.d/rc 4 l5:5:wait:/etc/rc.d/init.d/rc 5 l6:6:wait:/etc/rc.d/init.d/rc 6 ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now su:S016:once:/sbin/sulogin 1:2345:respawn:/sbin/agetty --noclear tty1 9600 2:2345:respawn:/sbin/agetty tty2 9600 3:2345:respawn:/sbin/agetty tty3 9600 4:2345:respawn:/sbin/agetty tty4 9600 5:2345:respawn:/sbin/agetty tty5 9600 6:2345:respawn:/sbin/agetty tty6 9600 # End /etc/inittab There is no /etc/rc.d folder though. After booting the kernel it says: there is no /etc/rc.d/init.d/rc On Fri, Dec 30, 2016 at 9:57 AM, ssmtpmailtesting ssmtpmailtesting < ssmtpmailtest...@gmail.com> wrote: > I looks, kernel is booting well. Mounted rootfs(ext4). I got the login > prompt as: (none) login: , if I type username there, characters are not > displayed there. It's not doing anything from there. I think, system is > freezed. > > cat /etc/sysconfig/console: > KEYMAP="us" > FONT="lat1-16 -m 8859-1" > > I didn't install this: http://www.linuxfromscratch. > org/lfs/view/stable/chapter07/bootscripts.html > > cat /etc/sysconfig/ifconfig.eth0 > > ONBOOT=yes > IFACE=eth0 > SERVICE=ipv4-static > IP=192.168.1.2 > GATEWAY=192.168.1.1 > PREFIX=24 > BROADCAST=192.168.1.255 > > (none) login: prompt was before. I was able to login before without > installing lfs bootscripts. But I recompiled the kernel, then tried again > to change the (none) login: to mybox login: prompt. Now can't type anything > and can't login. > > cat /etc/hostname > mybox > > What can be the problem? What should I do? > -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
[lfs-support] Can't login after boot, typing keyboard doesn't display any character on console, why?
I looks, kernel is booting well. Mounted rootfs(ext4). I got the login prompt as: (none) login: , if I type username there, characters are not displayed there. It's not doing anything from there. I think, system is freezed. cat /etc/sysconfig/console: KEYMAP="us" FONT="lat1-16 -m 8859-1" I didn't install this: http://www.linuxfromscratch.org/lfs/view/stable/chapter07/bootscripts.html cat /etc/sysconfig/ifconfig.eth0 ONBOOT=yes IFACE=eth0 SERVICE=ipv4-static IP=192.168.1.2 GATEWAY=192.168.1.1 PREFIX=24 BROADCAST=192.168.1.255 (none) login: prompt was before. I was able to login before without installing lfs bootscripts. But I recompiled the kernel, then tried again to change the (none) login: to mybox login: prompt. Now can't type anything and can't login. cat /etc/hostname mybox What can be the problem? What should I do? -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] New directory layout and FHS 3.0
On Thu, Dec 29, 2016 at 12:59 AM, Hazel Russmanwrote: > On Wed, 28 Dec 2016 23:47:45 +0100 > Frans de Boer wrote: > > > I have said that I will forward some patches to get rid of the > > [...]/lib64 notions after I have tested my older patches against the > > newest sources. > > > > I have created several source code changes and tested them, only to find > > out that glibc, gcc, libcap and perl have at some places hard coded the > > path to [...]/lib64 if an x86_64 machine is detected. I can change most > > of it with good result. > > > > Still I do not send the changes yet because I am more and more convinced > > that on machines with multiarch capabilities one should always use a > > qualifier in the directory name for libraries. > > Now, LFS is about teaching others how to start building your own > > operating system and minimal support utilities. The project started out > > in the era of 32-bit machines, adopted the 64-bit machine on the fly by > > use of links to legacy library directories who's naming is no longer > > discriminatory any more. What if we slip into the 128-bit (or +64-bit) > > era? Still using the legacy [...]/lib notion? > > The mail list has already many questions about the naming, maybe time to > > step into the current reality? > > > > Looking at production machines, with current UNIX and Linux > > distributions, many of them are already using a schema which > > differentiate already between bit sizes. > > Currently, I have a conversation on the FHS mailing list of due to the > > ambiguous nature of qualifiers. > > > > A snippet from the latest mail exchange: > > That said, I can appreciate also the idea that on hardware capable of > > handling multiple architectures - read size of data paths - you always > > use qualifiers, regardless if only one or multiple library directories > > are used. So my previous second proposal is then augmented into: > > > >[/usr[/local]]/lib for each different set of libraries > > > > For compatibility one should also add > >[/usr/[/local]]/lib -> [/usr[/local]]/lib > >Where .../lib links to the library directory supporting the native bit > >size. > > > > This implies that on 32-bit intel like systems, you always have a > > [...]/lib32 directory, an optional [...]/lib16 and [...]/lib is a link > > to [...]/lib32. > > On 64-bit Intel like systems you have [...]/lib64, an optional > > [...]/lib<32|16> and [...]/lib is a link to [...]/lib64. > > > > The above schema is already in widespread use on 64-bit machines, with > > the exception of the legacy use of [...]/lib for 32-bit library > directories. > > Also, modification of sources for glibc, gcc, libcap, perl etc, are not > > needed anymore. Due to the fact that some of these packages are core > > packages and it would require a lot of effort for the maintainers to > > change their current hard coded assumptions into more flexible code. > > --- > > > > I wait to see where this all is going before I decide what to do with > > the current patches. Note that there are more patches required then > > currently given in the LFS development branch. > > > > Regards, Frans. > > > Will this change do away with the very annoying screens of warning > messages from package libtool scripts about libraries seemingly having > moved? I'm sure I'm not the only person who finds them off-putting. > -- Our current setup (thanks to DJ) gets rid of them entirely. I haven't seen a single one -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] New directory layout and FHS 3.0
On 29-12-16 07:59, Hazel Russman wrote: On Wed, 28 Dec 2016 23:47:45 +0100 Frans de Boerwrote: I have said that I will forward some patches to get rid of the [...]/lib64 notions after I have tested my older patches against the newest sources. I have created several source code changes and tested them, only to find out that glibc, gcc, libcap and perl have at some places hard coded the path to [...]/lib64 if an x86_64 machine is detected. I can change most of it with good result. Still I do not send the changes yet because I am more and more convinced that on machines with multiarch capabilities one should always use a qualifier in the directory name for libraries. Now, LFS is about teaching others how to start building your own operating system and minimal support utilities. The project started out in the era of 32-bit machines, adopted the 64-bit machine on the fly by use of links to legacy library directories who's naming is no longer discriminatory any more. What if we slip into the 128-bit (or +64-bit) era? Still using the legacy [...]/lib notion? The mail list has already many questions about the naming, maybe time to step into the current reality? Looking at production machines, with current UNIX and Linux distributions, many of them are already using a schema which differentiate already between bit sizes. Currently, I have a conversation on the FHS mailing list of due to the ambiguous nature of qualifiers. A snippet from the latest mail exchange: That said, I can appreciate also the idea that on hardware capable of handling multiple architectures - read size of data paths - you always use qualifiers, regardless if only one or multiple library directories are used. So my previous second proposal is then augmented into: [/usr[/local]]/lib for each different set of libraries For compatibility one should also add [/usr/[/local]]/lib -> [/usr[/local]]/lib Where .../lib links to the library directory supporting the native bit size. This implies that on 32-bit intel like systems, you always have a [...]/lib32 directory, an optional [...]/lib16 and [...]/lib is a link to [...]/lib32. On 64-bit Intel like systems you have [...]/lib64, an optional [...]/lib<32|16> and [...]/lib is a link to [...]/lib64. The above schema is already in widespread use on 64-bit machines, with the exception of the legacy use of [...]/lib for 32-bit library directories. Also, modification of sources for glibc, gcc, libcap, perl etc, are not needed anymore. Due to the fact that some of these packages are core packages and it would require a lot of effort for the maintainers to change their current hard coded assumptions into more flexible code. --- I wait to see where this all is going before I decide what to do with the current patches. Note that there are more patches required then currently given in the LFS development branch. Regards, Frans. Will this change do away with the very annoying screens of warning messages from package libtool scripts about libraries seemingly having moved? I'm sure I'm not the only person who finds them off-putting. As far as I have seen, they only appear when creating the target binaries. So it is just a minor issue, I guess. But to give a straight answer to your question: I don't know yet. I will change the layout (again) and test everything. I don't expect any difficulty or bump since the proposed layout is very similar to what was used under LFS. The only real change is that links and directories switch contents. We should also not forget to preserve the purpose of LFS in the first place. A means to get familiar of building a own Linux OS. There is - in my view - a need to get closer to real world examples and therefor be done with library directory names originating from the 16/32-bit era. --- Frans. -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style