Re: [lfs-dev] Kernel configuration for systemd
Ken Moffat wrote: > On Fri, Apr 25, 2014 at 10:35:11PM -0500, Bruce Dubbs wrote: >> >> Does this help? >> >> http://wiki.gentoo.org/wiki/Systemd#Kernel >> >> -- Bruce > > No ;-) > > They show "open by fhandle syscalls" as required, so I start to > believe there is no choice for that. But the other items I queried, > as well as > > Firmware Drivers ---> > [*] Export DMI identification via sysfs to userspace > > which we do not seem to have, are listed as "Recommended". In > BLFS, that would mean "you are on your own if you omit this > dependency" (and some are _not_ hard to fix), but I think they > probably mean that some functionality that most gentoo systemd > users will need is probably missing. > > The first question is "what functionality ?", and if we can > discover that, it begs the question whether we should distinguish > the things needed / recommended for systemd (compared to sysvinit). Those are good questions. I don't know the answers. Your comment about being "oun your own" is a little overstated. Checking other places: https://wiki.debian.org/systemd http://cgit.freedesktop.org/systemd/systemd/tree/README This last seems to have some of the info you want. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Kernel configuration for systemd
Ken Moffat wrote: > I've now got to section 8.3, and as-expected I need to change my > kernel config from what I've been using, if I hope it will support > booting with systemd. But I'd like to query if a few of these > settings really are necessary, and also to suggest that we ought to > distinguish between what is required for sysvinit with the LFS > bootscripts (just devtmpfs last time I looked), and those options > which are only needed for systemd. After all, we already know that > some users have no wish to run lennart from scratch. > > I know that Control Group support is needed by systemd, the items > I'm querying are : > > 1. open by fhandle syscalls - this is supposedly for userspace file > servers (according to the kernel help). > > 2. Enable seccomp to safely compute untrusted bytecode - I happen to > have this set (I'm a sucker for enabling new options if they look as > if they might be useful), but it doesn't look like something that I > normally _need_. > > 3. The IPv6 protocol - again I have it set (ISTR one of the LFS > testsuites likes it), but many of us have no expectation of being > able to use this in the near future - is it really required ? > > 4. Kernel automounter version 4 support - this fills me with horror > (I hate it if my system tries to second-guess what I want to do with > a CD or something purporting to be a drive (e.g. something with > compact flash, i.e. using usb-storage) which has been connected by > USB). The kernel help says this needs userspace tools - I am > guessing that systemd replaces the autofs daemon in this context, > but it also says that NFS file system support is needed. Not a > problem for me, because a lot of my data is on nfs, but perhaps > misleading if automounting really is required and people also read > the kernel help - we've always had a tradition of minimal kernels. > > 5. Tmpfs POSIX ACLs and extended attributes. Again, not something > I've ever needed. > > I can willingly believe that systemd is so monolithic that all of > these things really are needed, but I thought I might as well ask - > if some of these enable functionality which might be epected to be > present in systemd, perhaps we should list what they enable, with a > warning that omitting them may cause problems if you run systemd ? Does this help? http://wiki.gentoo.org/wiki/Systemd#Kernel -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] section 7.1 : typo ?
Ken Moffat wrote:
> On Sun, Apr 20, 2014 at 09:27:55PM -0500, Bruce Dubbs wrote:
>> Ken Moffat wrote:
>>>I'm just looking in more detail at the set-systemd and set-sysv
>>> scripts in section 7.1.
>>>
>>>Two questions:
>>>
>>> 1. set-systemd ends with
>>> echo "Now reboot with /sbin/reboot-sysv"
>>>and set-sysv ends with
>>> echo "Now reboot with /sbin/reboot-systemd"
>>
>>>Are these swapped, i.e. set-systemd should instruct
>>> people to run "reboot-systemd" ?
>>
>> When you change the symlinks, you need to reboot with the program for
>> the existing system, not the new one. After the symlinks are changed,
>> the reboot program points to the wrong version.
>>
>> If you booted into a sysv init, reboot normally calls that init. You
>> need to use the sysv reboot.
>>
>>> 2. does a plain reboot not do whatever is necessary to change from
>>> sysv to systemd, or vice-versa ?
>>
>> No. After a symlink change, a plain reboot would use the wrong version.
>>
>> -- Bruce
>
> OK, I take your point that a previous-style reboot is recommended
> after changing between the init systems.
>
> For those of us who enable MagicSysRQ in our kernel builds
> (Alt-PrintScreen-letter) I imagine that Alt-PrintScreen-{S,U,B}
> (sync, umount, boot) will do the job, and that if we have to go back
> to the old init version this will be no worse than any other unclean
> shutdown ?
I'm not aware of the MagicSysRQ function but note that the only time the
standard reboot is not appropriate is immediately after running the
script to change init methods. For those rare times, what's wrong with
just using the version specific reboot from the command line.
I did consider embedding appropriate reboot line in the script, but
thought it was better for the user to see the verbose output of the
commands.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] [lfs-book] r10546 - in trunk/BOOK: chapter01 chapter06
Ken Moffat wrote: > On Tue, Apr 22, 2014 at 11:28:32AM -0700, bdu...@higgs.linuxfromscratch.org > wrote: >> Author: bdubbs >> Date: Tue Apr 22 11:28:32 2014 >> New Revision: 10546 >> >> Log: >> Update users so all acl tests pass >> > >> >> Modified: trunk/BOOK/chapter06/shadow.xml >> == >> --- trunk/BOOK/chapter06/shadow.xml Tue Apr 22 07:58:15 2014(r10545) >> +++ trunk/BOOK/chapter06/shadow.xml Tue Apr 22 11:28:32 2014(r10546) >> @@ -72,6 +72,11 @@ >> sed -i >> 's@DICTPATH.*@DICTPATH\t/lib/cracklib/pw_dict@' >> etc/login.defs >> >> >> +Make a minor change to make the default useradd consistent with >> the LFS >> +groups file: >> + >> +sed -i 's/1000/999/' >> etc/useradd >> + >> Prepare Shadow for compilation: >> >> ./configure >> --sysconfdir=/etc > > Why 999 instead of 1000 ? > > I've had a users group in my own builds for years, probably derived > from fedora, and it has always been 1000. Shadow is now maintained > by debian, no ? So the fact that it too uses 1000 implies many > people will already use 1000 for the group owning their files. > > OK, you can set up a completely new set of groups in the LFS > system, but if you share /home between the original host system and > LFS (e.g. until you feel confident that LFS is the right way for > you) then this justs adds unnecessary change. I put in 999 because it keeps useradd from giving a warning message the first time useradd is run on a base LFS system. It also makes the first useradd create UIDs and GIDs the same number. Perhaps we should ignore that issue. But is it OK (esthetically, not technically) to have a users group of 1000 and the first user with a UID of 1000 and a GID of 1001? Note that the only reason we do any of this is that the acl tests insist on a group with the name users. One alternative may be to hack the test code to use some other group that already exists. Perhaps: sed -i 's/:users/:dialout/' test/misc.test I haven't tried it, but then a 'users' group wouldn't be needed and we could revert that change in shadow. My personal approach is usually to just copy passwd/group/shadow from the old system to the new, but a new user will probably want to just use useradd. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] variables in /etc/vconsole.conf
Ken Moffat wrote: > I'm trying to guess what I need here, but the details seem to be > sparse. > > 1. FONT_MAP and FONT_UNIMAP : I haven't found any relevant examples > yet, but I assume those of use using UTF-8 throughout our system do > not need to specify anything ? I saw an example of FONT_MAP for > legacy 8859-2, so I'm assuming that since systemd is recent it > assumes unicode. > > 2. Googling to try to find examples, I see suggestions that > vconsole.conf is also used to set the Xorg keymap - is that true ? I would doubt it unless the Xorg folks have made the change. > At the moment, I set > Option "XkbLayout" "gb" > in /usr/share/X11/xorg.conf.d/11-keyboard.conf and later (after I'm > running icewm) use xmodmap to set my xorg keymap to one of : british > with a few extra glyphs such as „ (low double quotes), russian > (phonetic) with a few other extras, e.g for ukrainian letters, or > greek with one or two extras. Anyone know if I'll still be able to > override things in xmodmap when / if I try systemd ? I would think so, but I haven't tried. > TIA / спасибі заздалегідь / ευχαριστώ εκ των προτέρων > - and I hope that translate.google.com is accurate for this ;-) Well I got Greek: thanks in advance and the same in Ukranian. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS Chapter 7
Sebastian Plotz wrote: > Am 21.04.2014 23:46, schrieb Bruce Dubbs: >> I have reorganized and rewritten Chapter 7. I'd appreciate feedback. >> Thanks. >> >> -- Bruce > > It looks really good. I have only three minor things to mention: > > 1) > > Unfortunately some (in my opinion) interesting documentation got lost: > > - |description of /etc/init.d/mountvirtfs| > - description of |/etc/rc.d/init.d/udev (it triggers coldplug, |unsets > the uevent handler from the default of |/sbin/hotplug) > - the configfile |/etc/sysconfig/udev_retry is not mentioned anymore > (associated with the *udevadm info --attribute-walk command) > > Would it be meaningful to include this documentation again somewhere? > > 2) > > The is a typo in paragraph "7.5.2. Configuring the Network Interface > Card at boot (systemd)": > > configuartion --> configuration > > 3) > > It may should be mentioned that it is necessary to run "systemctl > disable ifupdown@eth0" before the procedure described under "7.5.3. > Configuring the Network Interface Card for systemd-networkd" can be used. Thank you. I'll work these into my next update. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] LFS Chapter 7
I have reorganized and rewritten Chapter 7. I'd appreciate feedback. Thanks. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] section 7.1 : typo ?
Ken Moffat wrote: > I'm just looking in more detail at the set-systemd and set-sysv > scripts in section 7.1. > > Two questions: > > 1. set-systemd ends with > echo "Now reboot with /sbin/reboot-sysv" > and set-sysv ends with > echo "Now reboot with /sbin/reboot-systemd" > Are these swapped, i.e. set-systemd should instruct > people to run "reboot-systemd" ? When you change the symlinks, you need to reboot with the program for the existing system, not the new one. After the symlinks are changed, the reboot program points to the wrong version. If you booted into a sysv init, reboot normally calls that init. You need to use the sysv reboot. > 2. does a plain reboot not do whatever is necessary to change from > sysv to systemd, or vice-versa ? No. After a symlink change, a plain reboot would use the wrong version. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Use systemd to configure network interfaces
Bruce Dubbs wrote: > Sebastian Plotz wrote: >> Am 14.04.2014 21:52, schrieb Bruce Dubbs: >>> I've thought about it, but my experience with systemd is limited. Do >>> you have specific instructions I can test with LFS? -- Bruce >> >> Ok, I'll try to give a starting point. >> >> 1.) First of all we need to create a .link file (for example >> 15-eth0.link) in /usr/lib/systemd/network: >> >> [Match] >> MACAddress=12:34:56:78:9a:bc >> >> [Link] >> Name=eth0 >> >> This assignes the name eth0 to the interface with the MAC address >> 12:34:56:78:9a:bc. The file name is important: if there would be a >> second file (for example 10-eth1.link) with "Name=eth1"instead of >> "Name=eth0" the interface would get the name eth1. > > Interesting. Do you know what happens if there is a udev rule that > creates eth0? Is this .link file needed? I can test that so it's > somewhat of a rhetorical question. > > >> 2.) The second step would be to create .network files (for example >> 10-eth0-static.network) in /usr/lib/systemd/network. These files are >> read by systemd-networkd. This service is started by default in >> multi-user.target >> (http://www.phoronix.com/scan.php?page=news_item&px=MTYxMTI). Otherwise >> the service can be enabled with >> >> systemctl start systemd-networkd >> >> I took the example configuration from the LFS book: >> >> [Match] >> Name=eth0 >> >> [Network] >> Address=192.168.1.2/24 >> Gateway=192.168.1.1 >> >> >> This configuration assigns the ip address and the gateway to the >> interface eth0. It is also possible to use DHCP and other things (see >> http://www.freedesktop.org/software/systemd/man/systemd.network.html). >> >> I hope this helps a bit. I'm open to discuss further details. > > If I understand correctly, systemd has built in dhcp too. E.g. > > [Match] > Name=eth0 > > [Network] > DHCP=true > > > I'll experiment a little, but probably not until Wednesday. I had a few minutes and did some experimenting. I did: cat > /etc/systemd/network/10-eth0-static.network << EOF [Match] Name=eth0 [Network] Address=192.168.1.2/24 Gateway=192.168.1.1 EOF and disabled ifupdown with 'systemctl disable ifupdown@eth0' (Actually I did this in chroot. There was a warning about not being able to read /proc/cmdline, but that didn't matter) On reboot, eth0 came up. The .link file was not needed because I have /etc/udev/rules.d/70-persistent-net.rules to rename the connection. Right now on a base LFS system I have the following non-kernel processes running: UID PID PPID C STIME TTY TIME CMD root1 0 0 21:00 ?00:00:01 /sbin/init root 86 1 0 21:00 ?00:00:00 /lib/systemd/systemd-journald root 93 1 0 21:00 ?00:00:00 /lib/systemd/systemd-udevd root 176 1 0 21:00 ?00:00:00 /lib/systemd/systemd-logind message+ 178 1 0 21:00 ?00:00:00 /usr/bin/dbus-daemon root 179 1 0 21:00 ?00:00:00 /lib/systemd/systemd-networkd root 188 1 0 21:00 tty1 00:00:00 -bash bdubbs 17053 188 0 21:11 tty1 00:00:00 -su root26169 1 0 21:20 ?00:00:00 /usr/sbin/sshd -D -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Use systemd to configure network interfaces
Sebastian Plotz wrote: > Am 14.04.2014 21:52, schrieb Bruce Dubbs: >> I've thought about it, but my experience with systemd is limited. Do >> you have specific instructions I can test with LFS? -- Bruce > > Ok, I'll try to give a starting point. > > 1.) First of all we need to create a .link file (for example > 15-eth0.link) in /usr/lib/systemd/network: > > [Match] > MACAddress=12:34:56:78:9a:bc > > [Link] > Name=eth0 > > This assignes the name eth0 to the interface with the MAC address > 12:34:56:78:9a:bc. The file name is important: if there would be a > second file (for example 10-eth1.link) with "Name=eth1"instead of > "Name=eth0" the interface would get the name eth1. Interesting. Do you know what happens if there is a udev rule that creates eth0? Is this .link file needed? I can test that so it's somewhat of a rhetorical question. > 2.) The second step would be to create .network files (for example > 10-eth0-static.network) in /usr/lib/systemd/network. These files are > read by systemd-networkd. This service is started by default in > multi-user.target > (http://www.phoronix.com/scan.php?page=news_item&px=MTYxMTI). Otherwise > the service can be enabled with > > systemctl start systemd-networkd > > I took the example configuration from the LFS book: > > [Match] > Name=eth0 > > [Network] > Address=192.168.1.2/24 > Gateway=192.168.1.1 > > > This configuration assigns the ip address and the gateway to the > interface eth0. It is also possible to use DHCP and other things (see > http://www.freedesktop.org/software/systemd/man/systemd.network.html). > > I hope this helps a bit. I'm open to discuss further details. If I understand correctly, systemd has built in dhcp too. E.g. [Match] Name=eth0 [Network] DHCP=true I'll experiment a little, but probably not until Wednesday. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Use systemd to configure network interfaces
Sebastian Plotz wrote: > What about using systemd to bring up the network interfaces? > > There was already a discussion about this topic before: > > https://www.mail-archive.com/lfs-dev@linuxfromscratch.org/msg19837.html > > The systemd version wouldn't need the LFS-Network-Scripts anymore. > The main book could use both the scripts (if booted by Sysvinit) and > .link and .network files (if booted by systemd). > > Here are some useful links: > > http://coreos.com/blog/intro-to-systemd-networkd/ > http://www.freedesktop.org/software/systemd/man/systemd.link.html > http://www.freedesktop.org/software/systemd/man/systemd.network.html I've thought about it, but my experience with systemd is limited. Do you have specific instructions I can test with LFS? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Incorporating upstream patches
I would like to get the opinion of the community. Right now we have four tickets: #3537 MPFR-3.1.2 Patchlevel 5 #3536 Fix BC-1.06.95 bug #3532 Readline-6.3 patchlevel 3 #3532 Bash-4.3 patchlevel 8 All of these call for adding patches from upstream. My question is whether it should be the policy of LFS to add these types of upstream patches to the book when upstream does not feel the need to release a new stable version to make these fixes. In the case of BC, I think that it may be reasonable since there has been no stable releases since 2006. However, the fact that the problem has evidently been around for 8 years and is now just coming up indicates the level of importance. For the others, I'm even less sure. My problem is not with making the specific patches mentioned, but what the policy should be. Should we be checking all packages daily for these types of patches? Clearly that would be a time consuming task. If we are going to patch, what patches should be used? There are patches from various sources: Debian, Arch, Gentoo, as well as the originating site. These are not always the same. Generally, these patches address corner cases and rarely come up in common usage. What's your opinion? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS : SVN : "/lib/udev/devices does not exist" and "/dev/pts does not exist"
Magnus Larsson wrote: > On 2014-04-12 23:04, Bruce Dubbs wrote: >> Magnus Larsson wrote: >>> (resend with correct subject title) >>> Magnus >>> >>> dearlfs-...@linuxfromscratch.org, >>> >>> LFS : SVN : "/lib/udev/devices does not exist" and "/dev/pts does not >>> exist" >>> >>> === my lfs system === >>> >>> I built SVN circa 140331-140408. I can boot the system and log in as >>> root. It works! Great! >>> >>> I used the development version SVN circa 140331-140408. >>> http://www.linuxfromscratch.org/lfs/view/development/ >>> >>> I have a few comments and I also need some help with "udev" and "/dev/pts". >>> >>> I have not installed udev or eudev. I followed the systemd instruction >>> in >>> http://www.linuxfromscratch.org/lfs/view/development/chapter06/systemd.html >>> and the rest of SVN instruction. >>> >>> In System Configuration and Bootscripts >>> http://www.linuxfromscratch.org/lfs/view/development/chapter07/introduction.html, >>> >>> I selected system V as my boot method with "/usr/sbin/set-sysv". >>> >>> === errors when booting system === >>> >>> When I boot lfs I get a few errors and complaints regarding udev and >>> /dev/pts. >>> >>> 1) Question: When I boot I get and mountvirtfs executes, I get "Mounting >>> virtual file systems.. /run /proc /syscp: Cannot stat >>> '/lib/udev/devices/*' no such file or directory". This is correct. I do >>> not have the "devices" sub directory in /lib/udev. >>> How can I resolve this? >>> >>> 2) Comment: S10Udev (S10udev -> ../init.d/udev) looks for >>> "/sbin/udevadm", but I had udevadm as /bin/udevadm. I copied >>> /bin/udevadm to /sbin to solve this. >>> >>> 3) The same udev script row 52 has: "/sbin/udevd --daemon", but I do >>> not have udevd. Do I have to install udev as well? >>> >>> 4) When the mountfs script executes it states: "Mounting remaining file >>> systems... : mount point /dev/pts does not exist". That is correct, I do >>> not have /dev/pts. >>> >>> I noticed there is now a systemd development version as well. I did not >>> use that. Is it so that the regular development version >>> http://www.linuxfromscratch.org/lfs/view/development/ need updated >>> lfs-Bootscripts? >> >> You don't say what version of the bootscripts. The current version 0s >> lfs-bootscripts-20140404 >> >> /dev/pts is created in /etc/init.d/mountfs. The mention of >> /lib/udev/devices needs to be corrected. > I have used lfs-bootscripts-20140321. That's been updated. Welcome to the joys of -dev. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS : SVN : "/lib/udev/devices does not exist" and "/dev/pts does not exist"
Magnus Larsson wrote: > (resend with correct subject title) > Magnus > > dearlfs-...@linuxfromscratch.org, > > LFS : SVN : "/lib/udev/devices does not exist" and "/dev/pts does not > exist" > > === my lfs system === > > I built SVN circa 140331-140408. I can boot the system and log in as > root. It works! Great! > > I used the development version SVN circa 140331-140408. > http://www.linuxfromscratch.org/lfs/view/development/ > > I have a few comments and I also need some help with "udev" and "/dev/pts". > > I have not installed udev or eudev. I followed the systemd instruction > in > http://www.linuxfromscratch.org/lfs/view/development/chapter06/systemd.html > and the rest of SVN instruction. > > In System Configuration and Bootscripts > http://www.linuxfromscratch.org/lfs/view/development/chapter07/introduction.html, > > I selected system V as my boot method with "/usr/sbin/set-sysv". > > === errors when booting system === > > When I boot lfs I get a few errors and complaints regarding udev and > /dev/pts. > > 1) Question: When I boot I get and mountvirtfs executes, I get "Mounting > virtual file systems.. /run /proc /syscp: Cannot stat > '/lib/udev/devices/*' no such file or directory". This is correct. I do > not have the "devices" sub directory in /lib/udev. > How can I resolve this? > > 2) Comment: S10Udev (S10udev -> ../init.d/udev) looks for > "/sbin/udevadm", but I had udevadm as /bin/udevadm. I copied > /bin/udevadm to /sbin to solve this. > > 3) The same udev script row 52 has: "/sbin/udevd --daemon", but I do > not have udevd. Do I have to install udev as well? > > 4) When the mountfs script executes it states: "Mounting remaining file > systems... : mount point /dev/pts does not exist". That is correct, I do > not have /dev/pts. > > I noticed there is now a systemd development version as well. I did not > use that. Is it so that the regular development version > http://www.linuxfromscratch.org/lfs/view/development/ need updated > lfs-Bootscripts? You don't say what version of the bootscripts. The current version 0s lfs-bootscripts-20140404 /dev/pts is created in /etc/init.d/mountfs. The mention of /lib/udev/devices needs to be corrected. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] systemd ifup get run before systemd rename interface sometimes.
xinglp wrote: > $ journalctl -b|grep enp > Apr 08 22:37:25 vm1 ifup[123]: Adding IPv4 address 192.168.3.1 to the > enp4s0 interface...Cannot find device "enp4s0" > Apr 08 22:37:26 vm1 systemd-udevd[173]: renamed network interface eth0 to > enp4s0 > > So it won't startup network. Are you using /etc/udev/rules.d/70-persistent-net.rules? In the latest book it should be created automatically. I don't know what rule would cause renaming from eth0 to anything. BTW, the contents of 70-persistent-net.rules has changed lately. The predicate KERNEL=="something" has been removed. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] The joys of systemd
thomas wrote:
> Am Samstag, den 05.04.2014, 19:17 -0500 schrieb Bruce Dubbs:
>> Armin K. wrote:
>>> On 04/06/2014 01:19 AM, thomas wrote:
>>>> Am Samstag, den 05.04.2014, 16:41 -0500 schrieb Bruce Dubbs:
>>>>> Working with systemd, there seem to be lots of "learning" issues.
>>>>>
>>>>> I was trying to watch the boot sequence and the screen clears and I get
>>>>> a login prompt. How to disable clearing the screen? Well that's simple
>>>>> enough:
>>>>>
>>>>> mkdir -p /etc/systemd/system/getty@tty1.service.d
>>>>>
>>>>> cat > /etc/systemd/system/getty@tty1.service.d/noclear.conf < EOF
>>>>> [service]
>>>>> TTYVTDisallocate=no
>>>>> EOF
>>>>
>>>> So you finally managed to start discovering all the real and fancy
>>>> benefits of systemd. It has been really time now that a system comes up
>>>> which forces the user to figure out how to deal with the login prompt
>>>> again. Think about what else you could do in this time this new stuff
>>>> prevents you from. Thanks the lord, otherwise you could even go meet
>>>> friends and have a nice weekend. Ah, by default or not (i don't know),
>>>> systemd ignores the /tmp mointpoint in fstab and handle it by itself
>>>> somehow.
>>
>> That's not true for me. I have:
>>
>> /dev/sdb5 /tmp ext4 6%
> The support guys now need to ask: Which init have you started? May be
> fstab is not ignored on your system, now you have to figure out why.
> Simplest case would be that there is no .mount file. Maybe in ArchLinux
> the install such a .mount file by default...
systemd seems to create some .mount files on the fly from fstab. I did
find out that they do not wipe /tmp by default. Of course it does start
out empty if it is a tmpfs.
> That is what I call consistence, and it immediatly shows me the urge of
> inventing .mount files. Changing fstab rebooting will from now on not
> neccessarily show any effect.
I don't think that will be needed unless the users wants /tmp files on a
regular directory and then I think it will be a one liner:
ln -s /dev/null tmp.mount
>> I don't know if systemd wipes it or not. It may and I'll need to figure
>> out how to disable that. So there are two issues here.
> See my comment about efforts below...
>
>>
>> (lots of blah blah of mine)
>>>>
>>>> I believe giving the user the option between systemd and sysvinit is
>>>> brilliant and in times systemd seems to become more popular (for
>>>> whatever reason) simply consequent and valid. But I really do not
>>>> understand the point in having both in parallel on the machine. The
>>>> option should apply to the build time.
>>
>> How better to compare and contrast then to use exactly the same system
>> with the exception of the init program and /etc/init.d?
> How often this will be done? And by whom? By trend I use computers -
> even with LFS installed - for productive work (more or less). Sometimes
> there is a bit more work on the system itself, lets say when a new
> version of KDE comes up (which is true this year), but finally, the
> system is there to be used and hardly to be booted in X vs. Y seconds.
> Maybe that everyone else except me is interested in rebooting to
> different init systems 24 hours a day, I'm not. I'm interested in a rock
> solid foundation on which the next step (build BLFS packages) is to be
> done.
If used in production there is nothing to force a user to switch init
systems. How many other files are installed that are never used?
> Btw, how better to compare than watching two VMs starting. Each doing
> its crystal clean own stuff. I assume that "who does the compare" is
> answered by "mainly the LFS developers", right? They should be able to
> script the build-process entirely, maybe with a parameter like
> --init-system={sysvinit,systemd}. Than you can compare two identical
> systems (except IP-address, init-system and probably hostname) even at
> the same time.
The vm route is a little misleading when looking at init systems IMO.
It is a lot faster for all systems because the HW is emulated and the SW
responds faster than real HW.
> I wished all the efforts would have been put in the theory and maybe
> even practice of package management. A also interesting area to learn
> something. There has been a perfect working SysV and also a well
> maintained systemd version of the LFS book. They both are gone, a
> mixture came up. Too bad
Re: [lfs-dev] The joys of systemd
Armin K. wrote: > On 04/06/2014 01:19 AM, thomas wrote: >> Am Samstag, den 05.04.2014, 16:41 -0500 schrieb Bruce Dubbs: >>> Working with systemd, there seem to be lots of "learning" issues. >>> >>> I was trying to watch the boot sequence and the screen clears and I get >>> a login prompt. How to disable clearing the screen? Well that's simple >>> enough: >>> >>> mkdir -p /etc/systemd/system/getty@tty1.service.d >>> >>> cat > /etc/systemd/system/getty@tty1.service.d/noclear.conf < EOF >>> [service] >>> TTYVTDisallocate=no >>> EOF >> >> So you finally managed to start discovering all the real and fancy >> benefits of systemd. It has been really time now that a system comes up >> which forces the user to figure out how to deal with the login prompt >> again. Think about what else you could do in this time this new stuff >> prevents you from. Thanks the lord, otherwise you could even go meet >> friends and have a nice weekend. Ah, by default or not (i don't know), >> systemd ignores the /tmp mointpoint in fstab and handle it by itself >> somehow. That's not true for me. I have: /dev/sdb5 /tmp ext4 6% I don't know if systemd wipes it or not. It may and I'll need to figure out how to disable that. So there are two issues here. It was overdue that something comes up which spread everything >> cross over the machine away from the places it alway has been. Too long >> we where stuck in /etc/fstab. Too long all the systems has simply > > systemd has so called ".mount" files that act as a (not sure if this is > a right word) fstab "lines". There is a file shipped by systemd called > "tmp.mount" that will mount /tmp as a tmpfs as default. But as > everything else, defaults can be overriden. No single person/project can > please everyone. > > To override or even to disable (called "mask") default (or any kind of) > unit in systemd environment is to create a file with the same name in > /etc/systemd/system as a symlink to /dev/null. In this case it would be > "ln -s /dev/null /etc/systemd/system/tmp.mount" if I'm not mistaken. > >> worked. Next you will find a challenge to tell journalctl not immediatly >> end to command line when Ctrl-C has been given to end live-log-mode. The >> oldfashion "less" does that, but this pager worked well for too long, >> its time to do it in a new way. That's all real benefical stuff to deal >> with, proper invested time... > > On my system, journalctl uses less. If for some reason it doesn't on > yours, you can always export PAGER env var, ie PAGER=less. Simple "q" > works to terminate pager here. > >> >> >> Error: tag without opening tag >> >> -- >> Sorry about that, but I still think it was one of the worst moves LFS >> has ever done. But it seems that I'm the only one thinking that way and >> facing that, it seems that I'm too old now for that shit^H^H^Htuff. >> >> I believe giving the user the option between systemd and sysvinit is >> brilliant and in times systemd seems to become more popular (for >> whatever reason) simply consequent and valid. But I really do not >> understand the point in having both in parallel on the machine. The >> option should apply to the build time. How better to compare and contrast then to use exactly the same system with the exception of the init program and /etc/init.d? > Yea, I'd prefer the same approach, but that would make it way harder for > BLFS. Ie, some packages in BLFS will be installed if building systemd, > others will not, and having two udevs will cause twice the trouble for > post-LFS part (2 udev sections, for gudev lib, etc). Actually, most of the BLFS differences seem to be in the boot scripts. Having 'make install-sshd' install to both systems is almost trivial. I'm sure there will be other differences, but those are not as frequent. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] The joys of systemd
Working with systemd, there seem to be lots of "learning" issues.
I was trying to watch the boot sequence and the screen clears and I get
a login prompt. How to disable clearing the screen? Well that's simple
enough:
mkdir -p /etc/systemd/system/getty@tty1.service.d
cat > /etc/systemd/system/getty@tty1.service.d/noclear.conf < EOF
[service]
TTYVTDisallocate=no
EOF
Isn't that special! How intuitive! Compare to the standard login that
does nothing unless you specify a clear tty sequence in /etc/issue.
Who says the user knows more than the systemd developers? See how easy
systemd is to learn?
Now I come to setting up udev and networking. I have the rule:
/etc/udev/rules.d/70-persistent-net.rules
The contents are
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
ATTR{address}=="00:11:11:79:4d:17", ATTR{dev_id}=="0x0", \
ATTR{type}=="1", KERNEL=="enp*", NAME="eth0"
It doesn't work in udev-211, although it did using udev-208. I can add
net.ifnames=0 to the kernel command line and get eth0, but why doesn't
the custom udev rule work?
Actually, when I run
# udevadm test-builtin net_id /sys/class/net/enp0s25
Then the rule kicks in and renames the interface, but it doesn't seem to
run automatically. Armin, do you have any insight?
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Major changes in -dev
xinglp wrote: > 2014-04-05 19:50 GMT+08:00 Armin K. : >> On 04/05/2014 05:50 AM, Bruce Dubbs wrote: >>> xinglp wrote: >>>> 2014-04-05 11:04 GMT+08:00 Bruce Dubbs : >>>>> xinglp wrote: >>>>>> When boot into systemd, got the below message: >>>>> >>>>> Lets work the problems one at a time. >>> >>>>>> [/usr/lib/tmpfiles.d/systemd.conf:25] Unknown group 'systemd-journal'. >>>>> >>>>> Something else I forgot. What happens if you add >>>>> >>>>> systemd-journal:x:97 >>>>> >>>>> to /etc/groups. >>>> There's no "[FAILED] Failed to start Create Volatile Files and >>>> Directories." now, >>> >>> Good. I'll add that group to the book. I just rebuilt and am also >>> having trouble with the renaming of the network connection. Try 'ls >>> /sys/class/net' and make ifconfig conform to that. The ifup >>> should work. >>> >>> I'm not sure why the login service is failing for you. It's working for >>> me. The failure message wasn't very informative. >>> >>> -- Bruce >>> >> >> You are missing messagebus user and group as well as adm and >> systemd-journal group. Please use the same values as in systemd book. > This fixed my problems, thanks. Only network was not brought up now. Two ways to workaround the problem: 1. Put net.ifnames=0 on the kernel command line in GRUB 2. Change the ifconfig file to match the value that udev assigns I'll be working on a udev rule to do the reassignment today. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Major changes in -dev
Armin K. wrote: > On 04/05/2014 05:50 AM, Bruce Dubbs wrote: >> xinglp wrote: >>> 2014-04-05 11:04 GMT+08:00 Bruce Dubbs : >>>> xinglp wrote: >>>>> When boot into systemd, got the below message: >>>> >>>> Lets work the problems one at a time. >> >>>>> [/usr/lib/tmpfiles.d/systemd.conf:25] Unknown group 'systemd-journal'. >>>> >>>> Something else I forgot. What happens if you add >>>> >>>> systemd-journal:x:97 >>>> >>>> to /etc/groups. >>> There's no "[FAILED] Failed to start Create Volatile Files and >>> Directories." now, >> >> Good. I'll add that group to the book. I just rebuilt and am also >> having trouble with the renaming of the network connection. Try 'ls >> /sys/class/net' and make ifconfig conform to that. The ifup >> should work. >> >> I'm not sure why the login service is failing for you. It's working for >> me. The failure message wasn't very informative. >> >> -- Bruce >> > > You are missing messagebus user and group as well as adm and > systemd-journal group. Please use the same values as in systemd book. > > http://www.linuxfromscratch.org/lfs/view/systemd/chapter06/createfiles.html OK, I'll do that. I did have it in one of my builds, but it never got translated to the book and I forgot yesterday. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Major changes in -dev
Bryan Kadzban wrote: > Bruce Dubbs wrote: >> I did have a private email with a volunteer to write a hint. If I get >> that, I'll add a note in the systemd section that points there. > > I saw a commit mail to -book that added the hint link. > > However, if someone (like me...) *really really* doesn't want systemd, and > knows it from the get-go, shouldn't they avoid building all the other junk > like libacl / libattr / expat / *dbus* / etc., too? The current list of > packages that are only necessary because systemd was added are in the hint, > but how do we keep those packages in that state? I agree that dbus is not needed for servers, but I think most X environments are using it now. Are you able to get around that? The word I've been hearing is that dbus will get integrated into the kernel, although I suspect that would be a configuration option. > Because now that all this stuff is present, I can see a whole lot of changes > that don't realize they're adding even more dependence on these libraries, > because the libs are there in all the testing, which follows the book. For > any such change, I would rather default to not making it than force the extra > libraries, although what to actually do depends on what each change is and > which library in particular it needs. > > (dbus can go jump off a cliff with its abort() calls from a library, crashing > the X server and breaking video hardware. expat is annoying but not quite so > much as dbus. libacl/libcap and whatever else are at least small and simple, > but having e.g. acl support in coreutils seems like it has some side effects > that aren't clear yet.) The hint does suggest what packages are not needed. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Major changes in -dev
xinglp wrote: > 2014-04-05 10:59 GMT+08:00 William Harrington : >> >> On Apr 4, 2014, at 9:44 PM, xinglp wrote: >> >>> [FAILED] Failed to start Create Volatile Files and Directories. >>> See 'systemctl status systemd-tmpfiles-setup.service' for details. >> >> View the README in the systemd-xxx/ source directory or at /usr/share/ >> systemd-xxx/README and make sure your kernel options are proper. > All these options in systemd-xxx/README were proper set, except > "Filesystem wide access notification" metioned in > http://wiki.gentoo.org/wiki/Systemd , I'm recompiling. I do not have that option and have not run into problems for the limited amount of use so far. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Major changes in -dev
xinglp wrote: > 2014-04-05 11:04 GMT+08:00 Bruce Dubbs : >> xinglp wrote: >>> When boot into systemd, got the below message: >> >> Lets work the problems one at a time. >>> [/usr/lib/tmpfiles.d/systemd.conf:25] Unknown group 'systemd-journal'. >> >> Something else I forgot. What happens if you add >> >> systemd-journal:x:97 >> >> to /etc/groups. > There's no "[FAILED] Failed to start Create Volatile Files and > Directories." now, Good. I'll add that group to the book. I just rebuilt and am also having trouble with the renaming of the network connection. Try 'ls /sys/class/net' and make ifconfig conform to that. The ifup should work. I'm not sure why the login service is failing for you. It's working for me. The failure message wasn't very informative. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Major changes in -dev
xinglp wrote: > When boot into systemd, got the below message: Lets work the problems one at a time. > [FAILED] Failed to start Create Volatile Files and Directories. > See 'systemctl status systemd-tmpfiles-setup.service' for details. > ---split--- > root [ ~ ]# systemctl status systemd-tmpfiles-setup.service > systemd-tmpfiles-setup.service - Create Volatile Files and Directories > Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; > static) > Active: failed (Result: exit-code) since Sat 2014-04-05 02:24:19 > GMT-8; 8h ago > Docs: man:tmpfiles.d(5) > man:systemd-tmpfiles(8) >Process: 126 ExecStart=/bin/systemd-tmpfiles --create --remove > --boot --exclude-prefix=/dev (code=exited, status=1/FAILURE) > Main PID: 126 (code=exited, status=1/FAILURE) > > Apr 05 02:24:19 lfs_linux systemd-tmpfiles[126]: > [/usr/lib/tmpfiles.d/systemd.conf:25] Unknown group 'systemd-journal'. Something else I forgot. What happens if you add systemd-journal:x:97 to /etc/groups. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] An interesting thread about systemd
http://lkml.iu.edu//hypermail/linux/kernel/1404.0/01327.html -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Major changes in -dev
Ken Moffat wrote: >> The scripts to reconfigure are in /usr/local/sbin and are named >> set-systemd and set-sysv. I recommend re-reading Chapter 7 as there are >> a lot of changes there. > > Why /usr/local ? They will be an intrinsic part of LFS if this all > works out. Some of us occasionally try things in /usr/local, and > then wipe it all out. [ Well, I do ;-) ]. I just noticed that I forgot the #! /bin/bash line on one of the set scripts. I can change the location when I add that. Where do you think they should go? /usr/sbin? /sbin? /root? other? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Major changes in -dev
Denis Mugnier wrote: > Hi > > On 04/04/2014 02:02, Ken Moffat wrote: >>I'm sorry to see eudev disappear from the book after its brief >> appearance, but more power to your elbow for providing the two >> alternative init systems. > I'm sorry too. > > It is possible to integrate eudev on the BLFS book to provide a solution > without the systemd package? Not without changing the flow. I understand the yucky feeling you get when installing something you don't really want, but what does it really cost? A few MBs and SBUs. I did have a private email with a volunteer to write a hint. If I get that, I'll add a note in the systemd section that points there. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Major changes in -dev
Pierre Labastie wrote: >> -- Bruce > Built using jhalfs, with all final testsuites: > Errors (FWIW): > - glibc : 2 errors (+ 2 ignored), seems as usual > - coreutils : 1 error (test/misc/nohup) > - bash (a few, not sure, seems similar to usual) > - bc (a few, similar to usual) > - systemd : 2 failures : test-strv, test-journal-flush) > - utili-linux : 2 failures :last/last and last/ipv6 Note sure about these errors, but most seem normal. I don't know what would have changed for coreutils or bash. glibc, bc, and util-linux are normal. I don't have experience with systemd so I can't say they are normal in the chroot environment or not. > The first line of 7.8 Configuring the system hostname, has some weird typos: > "Durein gthe boot process, both Systemd and System V use the same file > for establixhg..." LOL. Sometimes I go too fast. "Durein gthe" -> "During the". establixhg -- what can I say? :) > Same errors as xinglp at boot. They are fixed. > The initramfs built with BLFS instructions does not work (I guess it > comes from the missing /lib/systemd-udevd, so maybe no big deal). BLFS is another animal. There are several places to fix. My thought on bootscripts there are to change it so both systemd units and System V boot scripts are installed in parallel. It would appear to me that the extra overhead would be negligible. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Major changes in -dev
akhiezer wrote:
>
> SVN-20140403 :
> --
> * Appendix C. 'Dependencies':
> - still got an entry for eudev.
> - no entry for systemd or d-bus.
Fixed at revision 10521.
> * Preface, 'v. Rationale for Packages in the Book':
> - still to be updated for newly added/removed pkgs since 7.5 rel.
Created ticket #3533
> * wget list
> ('http://www.linuxfromscratch.org/lfs/view/development/wget-list'):
> - still has an entry for 'udev-lfs-...':
It is still valid, but the contents have been reduced substantially.
>
> http://anduin.linuxfromscratch.org/sources/other/udev-lfs-20140302.tar.bz2
>Should it still have that?
Yes.
> - 'libcap' entry seems to be out of normal sort-ordering.
Fixed.
xinglp wrote:
> set-systemd line 7
> ln -sfvn $(tool}-systemd /sbin/${tool}
> should be
> ln -sfvn ${tool}-systemd /sbin/${tool}
Also fixed at revision 10521.
I've re-rendered the book on the website. Grab the new wget-list,
md5sums, and lfs-bootscripts-20140404.tar.bz2.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Major changes in -dev
akhiezer wrote:
>> Date: Thu, 03 Apr 2014 17:11:10 -0500
>> From: Bruce Dubbs
>> To: LFS Developers Mailinglist
>> Subject: [lfs-dev] Major changes in -dev
>>
>> I've committed a major change to the -dev version of LFS.
>>
>> The new version installs systemd and System V side-by-side with the
>> ability to reconfigure and come up in the other system.
>>
> .
> .
>>
>> I've done a render of the book on the website, so the changes are
>> reflected there now.
>>
> .
> .
>>
>> I'm sure there are still latent bugs in the current commit, whether they
>> be in scripts, build instructions, or text. Please test this out and
>> let me know of needed changes.
>>
>
>
> I guess you're maybe waiting for things to settle-down a bit, but anyhow:
>
> SVN-20140403 :
> --
> * Appendix C. 'Dependencies':
> - still got an entry for eudev.
> - no entry for systemd or d-bus.
> * Preface, 'v. Rationale for Packages in the Book':
> - still to be updated for newly added/removed pkgs since 7.5 rel.
> * wget list
> ('http://www.linuxfromscratch.org/lfs/view/development/wget-list'):
> - still has an entry for 'udev-lfs-...':
>
> http://anduin.linuxfromscratch.org/sources/other/udev-lfs-20140302.tar.bz2
>Should it still have that?
> - 'libcap' entry seems to be out of normal sort-ordering.
Thanks. I'll try to get to those soon.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Major changes in -dev
xinglp wrote:
> 2014-04-04 6:11 GMT+08:00 Bruce Dubbs :
>> I'm sure there are still latent bugs in the current commit, whether they
>> be in scripts, build instructions, or text. Please test this out and
>> let me know of needed changes.
>
> set-systemd line 7
> ln -sfvn $(tool}-systemd /sbin/${tool}
> should be
> ln -sfvn ${tool}-systemd /sbin/${tool}
I thought I fixed that! It will get fixed today.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Major changes in -dev
xinglp wrote: > Some error messages during boot，sysv > Mounting virtual file systems: /runcp: cannot stat > '/lib/udev/devices/*': No such file or directory Hmm. I didn't see this. The command is: cp -a /lib/udev/devices/* /dev and I do not appear to have the /lib/udev/devices directory at all, so the command just needs to be removed. > /etc/rc.d/rcS.d/S10udev: line 52: /lib/systemd-udevd: No such file or > directory That should be /lib/systemd/systemd-udevd I'll fix those and create a new bootscripts tarball. Thanks for testing. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Major changes in -dev
Ken Moffat wrote: > As to the size in the foreword - I think you are probably correct. Perhaps you mean the Preface. The first place I see size mentioned is in the target architectures. My, things gave grown since LFS 6.5. The size for 7.5 (64-bit) is 1.5G. We have increased the minimum recommended partition size in Secion 2.2 to 4G relatively recently. The really big package is still gcc at 1.9G, although 1.6G is recovered when the build directory is deleted. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Major changes in -dev
MENGUAL Jean-Philippe wrote: > Hi, > > OK so LFS doesn't use anymore sysvinit, but Systemd. Incorrect. You have a choice. We install both and you can test them out and choose the one you like best. I thought the book > 9ould use an approach like the CLFS one: one chapter if you use Systemd; > one if sysvinit (in CLFS: if you chroot; if you reboot). Given that the > choice is at runtime or config time, and not at install time, I think > the foreword could be changed. I suppose a 2nd Foreword could be added, but perhaps a little more explanation than usual in the "What's New" would be more appropriate. First because LFS isn't easily > installable on a very little system, Systemd is very big. Is it? Compared to what? My total build is 1.9G. The systemd build space is about 350M, but the installed size is only 62M or about 3% of the total. Then, the > teaching approach seems very different now: are you sure it stays really > easy to learn a system? Is the pedagogic purpose still really reached? I think so. Giving the user two systems to explore without having to rebuild gives many teaching moments. I believe the concept is unique. At least I haven't heard of it before. The default in the book is System V, but that uses udev from systemd. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Major changes in -dev
Ken Moffat wrote: > On Thu, Apr 03, 2014 at 05:11:10PM -0500, Bruce Dubbs wrote: >> I've committed a major change to the -dev version of LFS. >> >> The new version installs systemd and System V side-by-side with the >> ability to reconfigure and come up in the other system. >> > > I'm sorry to see eudev disappear from the book after its brief > appearance, but more power to your elbow for providing the two > alternative init systems. > > I'm now sufficiently interested by this to try a _minimal_ build > (i.e. LFS and not much else - many of the things I normally build > before rebooting have their own local bootscripts, which will > probably give me pain in systemd), and then try running that > [expletive deleted :-o ] init variant. To try a minimal build, try using jhalfs. Without the tests, it takes about 65 SBU on my system at 121 minutes/sbu. That's using -j1. > But first, I'm still in the middle of various non-LFS-related > things, together with some BLFS tickets. I've now completed a build > of my normal desktop on svn-20140331 with the following : linux-3.14, > gmp-6.0.0a, tzdata-2014b, file-5.18, flex-2.5.39 with lex as a > symlink following Armin's suggestion, libpipeline-1.3.0. If it > assists, I can pick up any of those tickets. I can do those easily enough. I want to let the current changes settle for a couple of days though. > Meantime, two brief comments - > >> The scripts to reconfigure are in /usr/local/sbin and are named >> set-systemd and set-sysv. I recommend re-reading Chapter 7 as there are >> a lot of changes there. > > Why /usr/local ? They will be an intrinsic part of LFS if this all > works out. Some of us occasionally try things in /usr/local, and > then wipe it all out. [ Well, I do ;-) ]. /usr/sbin just didn't feel right to me, but it would be easy enough to change. > [...] >> >> I'm sure there are still latent bugs in the current commit, whether they >> be in scripts, build instructions, or text. Please test this out and >> let me know of needed changes. > > Section 7.3.3 (configuring the network with systemd) - I think > there is missing whitespace in front of '@' in each of the three > commands in this section. At the moment they each say > ifupdown@eth0 ? No, the page is correct. There is a learning curve with systemd, and I can't say I've gotten very far yet.Note that the three lines are informative: enable, disable, and start. The actual file that is called is /lib/systemd/system/ifupdown@.service, so the part after the @ is the device. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Major changes in -dev
I've committed a major change to the -dev version of LFS. The new version installs systemd and System V side-by-side with the ability to reconfigure and come up in the other system. The scripts to reconfigure are in /usr/local/sbin and are named set-systemd and set-sysv. I recommend re-reading Chapter 7 as there are a lot of changes there. The lfs-bootscripts now also install the needed systemd unit for bringing up the network. I've done a render of the book on the website, so the changes are reflected there now. I've tested the system. It initial boot comes up using System V, but I've also been able to reconfigure and come up in systemd as well as being able to revert back to System V. There have been no changes yet to BLFS to support these changes directly, but the System V boot scripts should still work without problems. I'm sure there are still latent bugs in the current commit, whether they be in scripts, build instructions, or text. Please test this out and let me know of needed changes. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] udev rules
Ken Moffat wrote: > On Wed, Apr 02, 2014 at 02:00:29PM -0500, Bruce Dubbs wrote: >> I've been trying to figure out whether we need the lfs udev rules when >> transitioning to udev from systemd-211. >> >> 83-cdrom-symlinks.rules needs write_cd_rules, so those go together. >> > Taking a quick look at them, I admit I don't understand how it all > fits together. My memory suggests that those two rules create the cdrom > symlink, and that eject needs that to be able to open the drive > (even when the drive is empty). So, I'll suggest that whether the > cdrom rules are needed is a practical question which can be tested : > > On a new systemd system with a cdrom device, try booting with those > two rules present. Does 'eject' work ? Do you get a /dev/cdrom > symlink ? Compare the symlink(s) and perms with/without a CD in the > drive. [ I assume that eject does work and the /dev/cdrom symlink > will exist - if not, I suggest there is already a usability problem ]. > > Then remove the rules and reboot to be certain that the environment > is clean. Repeat the tests. Either things are worse, or no > different. > > Of course, since I admit to not understanding the details it is > entirely possible that I'm barking up the wrong tree. Thanks Ken. I'll try those tests. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] udev rules
Matt Burgess wrote: > > On 2014-04-02 20:00, Bruce Dubbs wrote: >> I've been trying to figure out whether we need the lfs udev rules when >> transitioning to udev from systemd-211. >> >> What we have is >> 55-lfs.rules, >> 81-cdrom.rules, >> 83-cdrom-symlinks.rules, >> write_cd_rules, >> write_net_rules, and >> init-net-rules.sh >> >> I do think we need init-net-rules.sh and write_net_rules to get back to >> eth0, but I'm not sure if we need the others. > I've not tried it but (the bottom of) > http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ > mentions that one can just pass 'net.ifnames=0' on the kernel command > line to disable the network device renaming. That would, assuming it > has the intended effect, mean that we could drop a boot script and a > rules file...nice :-) For most cases (one net card), I think net.ifnames=0 would be fine, but the init-net-rules.sh seems to be more robust (e.g. laptops). We could also just drop eth? and go with the renaming rules. >> I don't know if we can ignore changing the group for ippp and isdn etc >> devices or not in 55-lfs.rules. > I think those should be in BLFS, if they're still required. That's a good point. We don't even have ppp any more in BLFS. Do we need the cdrom rules? That would appear to be a less frequent issue. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] udev rules
I've been trying to figure out whether we need the lfs udev rules when transitioning to udev from systemd-211. What we have is 55-lfs.rules, 81-cdrom.rules, 83-cdrom-symlinks.rules, write_cd_rules, write_net_rules, and init-net-rules.sh I do think we need init-net-rules.sh and write_net_rules to get back to eth0, but I'm not sure if we need the others. 83-cdrom-symlinks.rules needs write_cd_rules, so those go together. 55-lfs.rules calls the setclock script. It's probably not needed if using systemd, but would be for systemV. I can fix that with a test. I don't know if we can ignore changing the group for ippp and isdn etc devices or not in 55-lfs.rules. What do you think? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Non-zero test result in acl
Ken Moffat wrote: > Since acl is now in the book, I decided to run its tests. I rather > wish I hadn't (my scripts do not lend themselves to keeping the > build directory around, and then going back to it later), but in > case anyone else is tempted to try this I'm reporting that I got a > non-zero return code, which caused my build to stop. > > On the face of it, the commands which were run all succeeded (114 > in tests, 29 in root-tests), but at the start of root-tests I also > got the following message: > > /tools/bin/make -C test/ root-tests > make[1]: Entering directory '/building/attr-2.4.47/test' > Note: Tests must run as root > /bin/sh: @echo: command not found > ^ > [1] $ mkdir d -- ok > (and the tests ran). > > For me, the workaround is to add '|| true ' to the end of the > command. No idea if people using jhalfs will run the acl tests. I've been concentrating on just getting the packages to build and the system to boot and haven't been running the regression tests for now. I fully intend to do that, but we call this version of the book 'development' for a reason. :) -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] systemd vs system V
matthew wrote: > It's been a while since I looked at it, but which of systemd's > utilities doesn't adhere to the 'do one job and do it well' > philosophy? I've already removed that verbage, but see below. > I see systemd as a collection of utilities much like > coreutils and util-linux. I'd agree with your point if the systemd > package just delivered a single systemd binary that handled device > naming, system logging and login management. The problem is that the executables are so interrelated you can't use just some. Can you separate systemd-init and any one of a number of other commands -- systemctl, systemd-ask-password, journalctl, systemd-logind, loginctl, timedatectl, localectl, etc. They are all tied together so tightly that you can't pick and choose but must run all or none. Even udev, which we've shown can be run separately, is now tied so tightly in the libraries, that you have to build a dozen extra library files (not needed by udev), to get the programs to link. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] systemd vs system V
Ken Moffat wrote: > On Mon, Mar 31, 2014 at 01:26:46PM -0500, Bruce Dubbs wrote: >> >> The init program is controlled by the /etc/inittab file and is organized >> into run levels that can be run by the user: >> >> 0 — halt >> 1 — Single user mode >> 2 — Multiuser, without networking >> 3 — Full multiuser mode >> 4 — User definable >> 5 — Full multiuser mode with display manager >> 6 — reboot >> >> The usual default run level is 3 or 5. >> > I believe that debian-based sysv desktop distros make run levels 2 > to 5 identical (full multiuser with display manager), although the > user can customise them to do different things. > > https://wiki.debian.org/RunLevel Right, but the LSB is as above. There are lots of variations though. See http://en.wikipedia.org/wiki/Init and http://en.wikipedia.org/wiki/Runlevel. I went with the LSB spec. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] headers_check : should we drop it ?
Ken Moffat wrote: > On Mon, Mar 31, 2014 at 04:43:26PM -0500, Bruce Dubbs wrote: >> >> I'm not touching Chapter 5 right now. Go ahead. >> > I took the liberty of removing two words from the text in the > chapter 6 headers page. If you are updating anything else today, > feel free to remove my changelog entry : I put it there because some > LFS builders seem to expect a changelog entry if there is a new > date in the book, but it isn't particularly useful. Updated my sandbox. No conflicts. Right now I have: $ svn status M appendices/scripts.xml M appendices/udev-rules.xml M bootscripts/ChangeLog M bootscripts/Makefile D bootscripts/lfs/init.d/functions M bootscripts/lfs/init.d/localnet M bootscripts/lfs/init.d/mountvirtfs M bootscripts/lfs/init.d/rc M bootscripts/lfs/init.d/udev M bootscripts/lfs/init.d/udev_retry M bootscripts/lfs/lib/services/init-functions A bootscripts/lfs/lib/systemd A bootscripts/lfs/lib/systemd/ifupdown@.service M chapter03/packages.xml M chapter03/patches.xml M chapter06/chapter06.xml A chapter06/dbus.xml M chapter06/systemd.xml D chapter06/sysvinit-header.xml M chapter06/sysvinit.xml M chapter07/chapter07.xml M chapter07/introduction.xml M packages.ent M patches.ent Lots more to do in chapter7/8. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] headers_check : should we drop it ?
Ken Moffat wrote: > On Sun, Mar 09, 2014 at 07:39:55PM -0500, Bruce Dubbs wrote: >> Ken Moffat wrote: >>> >>>Should we just drop this command ? >> >> Perhaps we should. What is happening is that scripts/headers_check.pl >> is being run. The comments say: >> >> # Usage: headers_check.pl dir arch [files...] >> # dir: dir to look for included files >> # arch: architecture >> # files: list of files to check >> # >> # The script reads the supplied files line by line and: >> # >> # 1) for each include statement it checks if the >> #included file actually exists. >> #Only include files located in asm* and linux* are checked. >> #The rest are assumed to be system include files. >> # >> # 2) It is checked that prototypes does not use "extern" >> # >> # 3) Check for leaked CONFIG_ symbols >> >> Both soundcard.h and kexec.h violate #2. I don't believe these have >> ever caused a problem and we certainly don't address teh warnings. >> >> -- Bruce > > I see you did this as part of r10508, but only in chapter 6. > Thanks for picking it up (I didn't spot it from looking the changelog > at the time). I can do chapter 5 if you like, but you've go so much > else going on in your reworking that I hesitate to touch it in case > I tread on your toes. I'm not touching Chapter 5 right now. Go ahead. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] systemd vs system V
I've been working on rewriting Chapter 7 to incorporate systemd. I've come up with the following text in the introduction and would like feedback. Thanks, -- Bruce 7.1.1. System V System V is the classic boot process that has been used in Unix and Unix-like systems such as Linux since about 1983. It consists of a small program, init, that sets up basic programs such as login (via getty) and runs a script. This script, usually named rc, controls the execution of a set of additional scripts that perform the tasks required to initialize the system. The init program is controlled by the /etc/inittab file and is organized into run levels that can be run by the user: 0 — halt 1 — Single user mode 2 — Multiuser, without networking 3 — Full multiuser mode 4 — User definable 5 — Full multiuser mode with display manager 6 — reboot The usual default run level is 3 or 5. Advantages + Established, well understood system. + Easy to customize. Disadvantages - Slower to boot. A medium speed base LFS system takes 8-12 seconds where the boot time is measured from the first kernel message to the login prompt. Network connectivity is typically established about 2 seconds after the login prompt. - Serial processing of boot tasks. This is related to the previous point. A delay in any process such as a file system check, will deleay the entire boot process. - Does not directly support advanced features like control groups (cgroups), and per-user fair share scheduling. - Adding scripts requires manual, static sequencing decisions. 7.1.2. Systemd Systemd is a group of interconnected programs that handles system and individual process requests. It provides a dependency system between various entities called "units". It automatically addresses dependencies between units and can execute several startup tasks in parallel. It provides login, inetd, logging, time, networking services, and other tasks. Advantages + Used on many extablished distributions by default. + There is extensive documentation. + Parallel execution of boot processes. A medium speed base LFS system takes 6-10 seconds from kernel start to a login prompt. Network connectivity is typically established about 2 seconds after the login prompt. More complex startup procedures may show a greater speedup when compared to System V. + Implements advanced features such as control groups to manage related processes. + Maintains backward compatibility with System V programs and scripts. Disadvantages - There is a substantial learning curve. - Some advanced features such as dbus or cgroups cannot be diabled if they are not otherwise needed. Systemd knows better than the user. - Logging is done in a binary format. Extra tools must be used to process logs or additional processes must be implemented to duplicate traditional logging programs. - Systemd violates two of the points of traditional Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Thoughts about LFS and systemd
thomas wrote: > Am Sonntag, den 30.03.2014, 12:33 +0200 schrieb Thierry Nuttens: >> Hello. >> >> I thing its a very good idea to go for a possibility to choose between >> systemd and SySV. Simply because, it's an endless debate, peoples are for >> SySV or for systemD, both parties are convinced by they choice. > > That is for sure true for the phase of building a LFS system but I > cannot see a benefit in having both systems installed in the final OS. > It is not clear to me why I would want to boot once using sysv and once > using systemd. BLFS packages do either use systemd or not, depending in > which environment they are built but I hardly believe that they do it as > a runtime choice. > Can you give me a hint why I should have both on the machine at the same > time? Or did I misunderstood the whole discussion? Sure. LFS has education as a major objective. Being able to switch allows users to compare for themselves. The amount of space needed for both systems is negligible. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Thoughts about LFS and systemd
Matt Burgess wrote:
>
> On 2014-03-29 06:32, Bruce Dubbs wrote:
>> Just a progress report. I've had some success. I can boot the same
>> system to either sysd or sysv. I have a couple of short scripts to
>> switch. For example:
>>
>> $ cat set-sysd
>> #! /bin/bash
>> for p in init halt poweroff reboot runlevel shutdown telinit; do
>> ln -sfvn $p-sysd /sbin/$p
>> if [ $p == "init" ]; then continue; fi
>> ln -svfn $p-sysd.8 /usr/share/man/man8/${p}.8
>> done
>>
>> ln -svfn init.d-sysd /etc/init.d
>>
>> At that point a reboot will come up with the new initialization. What I
>> have for the book right now is pretty rough and quite a way from being
>> ready to commit, but the proof of concept is basically done.
>
> Bruce,
>
> Firstly, thanks for picking this up and running with it, especially
> seeing as you were originally (and possibly still are) quite opposed to
> systemd.
I don't think it is a good method of teaching what's needed during boot.
I also think it demands a lot that is frequently not needed or desired.
> Your approach seems like a decent compromise, offering our readers the
> choice of which init system to use.
>
> I only have a minor nitpick with the above. Please look at the
> 'Spelling' section of http://www.freedesktop.org/wiki/Software/systemd/
> - upstream prefer people to refer to the project/binaries as 'systemd';
> would you mind adjusting the names of the symlinked binaries from sysd
> to systemd to comply please (it's only an extra 3 characters after all)?
Well I wanted to use sysd/sysv for symmetry, but I can change it.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Thoughts about LFS and systemd
Bruce Dubbs wrote:
> I did a little more checking. If eudev is dropped and the full systemd
> is substituted in a standard LFS environment, the following have name
> collisions:
>
>1 /usr/share/man/man8/shutdown.8
>2 /usr/share/man/man8/poweroff.8
>3 /usr/share/man/man8/telinit.8
>4 /usr/share/man/man8/halt.8
>5 /usr/share/man/man8/runlevel.8
>6 /usr/share/man/man8/reboot.8
>
>7 /sbin/reboot
>8 /sbin/halt
>9 /sbin/runlevel
> 10 /sbin/telinit
> 11 /sbin/poweroff
> 12 /sbin/shutdown
> 13 /sbin/init
>
> I still need to check out boot scripts and other initialization, but
> combining these boot systems with small script to set the desired system
> seems doable. I don't think it would be necessary to even ask the user
> to choose at build time.
Just a progress report. I've had some success. I can boot the same
system to either sysd or sysv. I have a couple of short scripts to
switch. For example:
$ cat set-sysd
#! /bin/bash
for p in init halt poweroff reboot runlevel shutdown telinit; do
ln -sfvn $p-sysd /sbin/$p
if [ $p == "init" ]; then continue; fi
ln -svfn $p-sysd.8 /usr/share/man/man8/${p}.8
done
ln -svfn init.d-sysd /etc/init.d
At that point a reboot will come up with the new initialization. What I
have for the book right now is pretty rough and quite a way from being
ready to commit, but the proof of concept is basically done.
There is a lot of work to do in documenting the configuration and the
basic settings, especially on the systemd side. For example, how are
messages to the console controlled. In sysv it is done the the basic rc
script with 'dmesg $LOGLEVEL', but I don't know how to execute that
early in systemd.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Thoughts about LFS and systemd
akhiezer wrote: > But those packages would auto- drop-out if a user is building/following the > non-sysd track of the book, right? Not necessarily. There are several packages that people have suggested are not necessary in LFS. I don't remember which, but LFS has never been aimed at a minimum Linux build. Adding a full systemd automatically adds udev so that's useful and things like attr, acl, etc are not really a problem. The only thing I really don't like is dbus, but that's not really a problem either if the user uses svsV and doesn't add the start script. dbus is not needed on most servers that don't also need an X install. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] libcap in chap3
Thomas Trepl wrote: > Hi, > > seems so that libcap is missing in "All packages" in chap3. I thought I did that, but I missed it. It's fixed now. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Thoughts about LFS and systemd
Thomas Trepl wrote: > Am Dienstag, 25. März 2014, 11:22:38 schrieb Bruce Dubbs: >> I've been looking at systemd and had a thought that perhaps both could >> be put into a single LFS build. Looking at the installed package >> contents in the books, I see the following name collisions: >> >> systemd sysvinit eudev >> udevd >> udevadm udevadm >> halt halt >> init init >> poweroff poweroff >> reboot reboot >> runlevel runlevel >> shutdown shutdown >> telinit telinit >> >> I don't know if udevd is missing from the systemd page or is really not >> installed when doing a systemd build, but I suspect it has just been >> omitted from the page. >> >> In any case, this cursory look indicates to me that both could be >> installed with custom names and a script written to swap the names and >> reboot to the desired system. I also suspect a sysV initialization >> could use the systemd version of udev and eudev would not be necessary. >> >> I have not looked at boot scripts or possibly different build options in >> other programs, but wanted to throw out the idea for comments. >> >> -- Bruce > > Hi, > I personally would dislike that approach to merge this two systems together. > Having that all installed, it may confuse more than it helps. While I still > deeply dislike systemd (I cannot argue technically, its more emotional), it is > quite right to have the systemd-branch as systemd really may become part of > the future and we shouldn't close the eyes for that. > But sysv is still valid, clear in its structures (and it does not take ages to > boot). In my eyes ideal for the educational background LFS has. A boot issue > can (mostly) easily tracked down to the bootscript which that can be tweaked > in whatever way for whatever reason. So keeping the "original" alive is also > valid. > I'd vote for not merging the two different init systems. I think systemd is > confusing enough so I'd think that mixing it with the "classic" would add > unnessessary complexity. The charme of a LFS system is to be crystal clear. > That would be somehow lost. If we end up with a combined system, there definitely will be a page describing the advantages and disadvantages of both systems and allow the user to choose. The default will be sysV. The combined version gives the advantage of using the same udev in both systems. One needed package for systemd is dbus. I really don't like adding that. If you are building a server (e.g. web or database server), there is no need for X. Without X applications, I know of no need for dbus. Actually, for an LFS system, I see no need for systemd in any case, but I do feel the need to add it for educational reasons. It will also be interesting to compare it on the same system. > Maybe a if-else in the book would not harm too much if it is only one or two. > I think something like "if you want to install systemd as boot system goto > chap X else continue" is understandable for everyone when a section is added > which describes the differences between sysv and systemd. Thats required to > give the user background to make her decision. So having both in a clear way > in one book may work, but I'd never install both on disk. > > Btw, +1 to add those packages like attr, acl and such to the core. The only > one still missing is cpio. With this one, everything would be available to > setup a Linux system using a initramfs for booting. I'm not so sure about cpio. The only reason to add that (IMO) is to support the initrd, and we don't describe that in LFS at all. In fact, one of the advantages of LFS is to show that an initrd is not necessary most of the time. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Thoughts about LFS and systemd
DJ Lucas wrote: > > On 03/25/14 11:22, Bruce Dubbs wrote: > First, let me say that I personally love that idea. I feel that LFS was kind > of loosing sight of the primary goal by not introducing systemd. However, are > you suggesting that LFS have optional instructions? That's not bad in itself, > just that it has never been acceptable before. I especially like providing > both > methods (again, primary goal of LFS). Ag has already raised the same point > about > optional instructions before I completed this message. Also, I'm not sure > about > scripting the swap. By all means, provide the instructions to switch, but > leave > the scripting to the user IMO. What about BLFS? Install both sysvinit and unit > files from the single install target from the bootscripts tarball? I'm > unfamiliar with the sysvinit compatibility in systemd, never had a need for > it. What I have in mind is to install both systems side-by-side and then asking the user to choose one or the other, and then adding a small script to switch between the two methods. The switch for a plain LFS system looks quite doable. I'm not so sure about BLFS packages though. This is a relatively long term project. I'm intentionally going slow so it may be a few weeks before is shows up in the development portion of the book. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Thoughts about LFS and systemd
Bruce Dubbs wrote: > I've been looking at systemd and had a thought that perhaps both could > be put into a single LFS build. Looking at the installed package > contents in the books, I see the following name collisions: > > systemd sysviniteudev > systemd-udevdudevd > udevadm udevadm > halt halt > init init > poweroff poweroff > reboot reboot > runlevel runlevel > shutdown shutdown > telinit telinit I did a little more checking. If eudev is dropped and the full systemd is substituted in a standard LFS environment, the following have name collisions: 1 /usr/share/man/man8/shutdown.8 2 /usr/share/man/man8/poweroff.8 3 /usr/share/man/man8/telinit.8 4 /usr/share/man/man8/halt.8 5 /usr/share/man/man8/runlevel.8 6 /usr/share/man/man8/reboot.8 7 /sbin/reboot 8 /sbin/halt 9 /sbin/runlevel 10 /sbin/telinit 11 /sbin/poweroff 12 /sbin/shutdown 13 /sbin/init I still need to check out boot scripts and other initialization, but combining these boot systems with small script to set the desired system seems doable. I don't think it would be necessary to even ask the user to choose at build time. Nothing's set, but it does look promising right now. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Thoughts about LFS and systemd
akhiezer wrote: > And in any event, you're still aiming at adding an "ifs'n'buts" layer to > the lfs-main book - the type of thing that has been argued against many > many times. Yes, if we end up doing this, it is a major change from our traditional methodology. It would, in fact, be LFS 8.0. > I do think that the idea is of interest: but it's really a candidate for > a separate branch/project. So far I've just added some packages that sysd needs but doesn't change the essence of the book a lot. Adding sysd is where things really start to change. After I do some work in my sandbox, I may indeed create a separate branch, which, btw, is not really much more than the git method: cd ../../branches; svn cp ../trunk/BOOK experimental -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Thoughts about LFS and systemd
akhiezer wrote: >> Date: Tue, 25 Mar 2014 11:22:38 -0500 >> From: Bruce Dubbs >> To: LFS Developers Mailinglist >> Subject: [lfs-dev] Thoughts about LFS and systemd >> >> I've been looking at systemd and had a thought that perhaps both could >> be put into a single LFS build. Looking at the installed package >> contents in the books, I see the following name collisions: >> >> systemd sysvinit eudev >> udevd >> udevadm udevadm >> halt halt >> init init >> poweroff poweroff >> reboot reboot >> runlevel runlevel >> shutdown shutdown >> telinit telinit >> >> I don't know if udevd is missing from the systemd page or is really not >> installed when doing a systemd build, but I suspect it has just been >> omitted from the page. >> >> In any case, this cursory look indicates to me that both could be >> installed with custom names and a script written to swap the names and >> reboot to the desired system. I also suspect a sysV initialization >> could use the systemd version of udev and eudev would not be necessary. >> >> I have not looked at boot scripts or possibly different build options in >> other programs, but wanted to throw out the idea for comments. >> > > > I'd recommend any such 'lfs-combined' be done in a third branch, separate > from lfs-systemd and lfs-main, and using merges from the latter two: > and *not* try to do all three in a single branch. > > > If instead all three approaches are (attempted to be) done directly on a > single branch, then inter alia you're practising the kind of 'layering' > that has been argued against (incl by yrself?) quite often - e.g. not > having multilib, avoid too many "ifs'n'buts", &c&c, as it would obscure > central educational goals of the book, &usw. > > > Certainly I think, in this respect at least, that it'd be wise of Armin to > not give up the separate lfs-systemd branch lightly. Also, sysd is still in > quite a state of flux; so even more reason to keep it essentially contained > in its own branch. > > > If the three-branches approach appears to be too 'difficult' ... then > maybe that's even more reason to be cautious about any notions of doing > everything on a single branch. I understand your concerns, but the development branch is for, well, development. If what goes there needs to be reverted, that's not a problem. We have until September (our self imposed release date) to decide. BTW, the more I look at systemd, the more I think of busybox. Good is some places, but not really good for all. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [LFS Trac] #3528: GMP-6.0.0
LFS Trac wrote: > #3528: GMP-6.0.0 > Comment (by Krejzi): > > It is 6.0.0a, it's newer than 6.0.0. Minor update to 6.0.0 probably. I thought I looked, but you are right. Why couldn't they have just named it 6.0.1? :( It extracts to 6.0.0. Nothing in the changelog about 6.0.0a. Nothing about why the a suffix. Looking at the commits, I see nothing, so it must have been a packaging error. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Thoughts about LFS and systemd
Armin K. wrote: > On 03/25/2014 05:22 PM, Bruce Dubbs wrote: >> I've been looking at systemd and had a thought that perhaps both could >> be put into a single LFS build. Looking at the installed package >> contents in the books, I see the following name collisions: >> >> systemd sysvinit eudev >> udevd >> udevadm udevadm >> halt halt >> init init >> poweroff poweroff >> reboot reboot >> runlevel runlevel >> shutdown shutdown >> telinit telinit >> >> I don't know if udevd is missing from the systemd page or is really not >> installed when doing a systemd build, but I suspect it has just been >> omitted from the page. >> > It's named systemd-udevd and it's installed in /lib/systemd. Ah, yes. The change in name seems unnecessary, but I remember now. A symlink might be appropriate if this approach turns out to be feasible. -- Bruce >> In any case, this cursory look indicates to me that both could be >> installed with custom names and a script written to swap the names and >> reboot to the desired system. I also suspect a sysV initialization >> could use the systemd version of udev and eudev would not be necessary. >> >> I have not looked at boot scripts or possibly different build options in >> other programs, but wanted to throw out the idea for comments. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Thoughts about LFS and systemd
I've been looking at systemd and had a thought that perhaps both could be put into a single LFS build. Looking at the installed package contents in the books, I see the following name collisions: systemd sysvinit eudev udevd udevadm udevadm halt halt init init poweroff poweroff reboot reboot runlevel runlevel shutdown shutdown telinit telinit I don't know if udevd is missing from the systemd page or is really not installed when doing a systemd build, but I suspect it has just been omitted from the page. In any case, this cursory look indicates to me that both could be installed with custom names and a script written to swap the names and reboot to the desired system. I also suspect a sysV initialization could use the systemd version of udev and eudev would not be necessary. I have not looked at boot scripts or possibly different build options in other programs, but wanted to throw out the idea for comments. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS- SVN-20140323 6.62. Eudev-1.5.3
baho-utot wrote:
> There is an error in the following:
>
> Create some directories now that are needed for tests, but will also be
> used as a part of installation:
>
> mkdir -pv /lib/{firmware,udev/devices/pts}
> mkdir -pv /lib/firmware <-- This is not needed as
> directory is created by above
I agree that it is redundant and should be fixed, but it seems pretty
minor to me.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] eudev-manpages version
Thomas Trepl wrote: > Hi, > > in chap6 the version of the eudev-manpages is hardcoded > > tar -xvf ../eudev-1.5.1-manpages.tar.bz2 -C /usr/share > > which should be > > tar -xvf ../eudev-&eudev-version;-manpages.tar.bz2 -C /usr/share Indeed you are right. I fixed that just now. I will note that (in this case) on anduin where the manpages tarball is located, the 1.5.3 tarball is a symlink to the 1.5.1 version. I've asked upstream to provide the rendered manpages as a part of the tarball so it doesn't need to be separate, but I don't know if they will do it or not. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] pkgconfig and *.pc files
baho utot wrote: > I see that pkgconfig has been removed from LFS and BLFS No it hasn't. http://www.linuxfromscratch.org/lfs/view/development/chapter06/pkg-config.html -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] jhalfs not create proper Makefile for ch6 autoconf
xinglp wrote: > There's many things missed for "105-autoconf:" section. with lfs_book > r10512 and jhalfs r3785 I accidentally dropped autoconf from Chapter 3. I'll fix in a minute. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] chattr and lsattr
baho utot wrote: > > On 03/20/2014 08:41 PM, Bruce Dubbs wrote: >> I've noticed that our instructions for e2fsprogs put chattr and lsattr >> into /usr/bin. Shouldn't these be in /bin? > If you follow Filesystem Hierarchy Standard version 2.3 they are not in > placed into /bin. > I have not found them in that document so it looks to me that /usr/bin > is ok. Taking a look at the LSB 3.0 beta that was released today, it says: /bin contains commands that may be used by both the system administrator and by users, but which are required when no other filesystems are mounted (e.g. in single user mode). It may also contain commands which are used indirectly by scripts. It goes on to say what is required and chattr and lsattr are not in that list. It also gives a list of optional programs that should be in /bin if they are installed. (ed is now optional!) That says, the list of programs presented is not exhaustive. chattr and lsattr would certainly fall into the general definition of "may be used by both the system administrator and by users, but which are required when no other filesystems are mounted". For example, if you need to change a file like fstab and it has the immutable bit set. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] chattr and lsattr
I've noticed that our instructions for e2fsprogs put chattr and lsattr into /usr/bin. Shouldn't these be in /bin? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] few typos - its "it's" // it's "its" .
akhiezer wrote: > - few small typos in lfs svn (as of r10511) per diff below. > > (Didn't include any of the further seven files under > 'BOOK/stylesheets/lfs-xsl/docbook-xsl-1.78.1/' with instances of same/similar > (re case) typo.) Fixed in my sandbox, but I won't make a special commit for them. Looking at the stylesheets, there are about 120 instances of "it's", but most are correct usage. I don't really think we need to be concerned with grammar in internal comments. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Proposal: Firmware instructions
Olaf wrote:
> On 2014-03-15 04:44, Bruce Dubbs wrote:
>
>> Hmm, just tell me in your own words how you do it. Don't worry about
>> what tools to use right now.
>
> This is how I currently create 'snapshots':
>
> # linux-firmware lives in GIT
> http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/
> # The procedure to create a snapshot is something like:
>
> git pull
> TAG=`git log -1 --pretty=format:%h`
> git archive --prefix=linux-firmware-${TAG}/ HEAD | xz >
> /linux-firmware-${TAG}.tar.xz
>
>
> Result is about ~ 22 MiB. Probably best/easiest to make that available
> via anduin?
> The archived snapshot comes with a Makefile which can be used to copy
> the lot to /lib/firmware.
> Or, if disk space is a concern, cherry pick the ones you need.
I checked out your procedure and it works quite well. The problem is
that the directory after using make install is 67M for the entire tree.
My entire /lib directory is only 20M.
I don't know that users would want the whole tree. At least I wouldn't.
How does a user know what firmware is needed? If we could do that, we
could just mirror the tree, updated daily, and let users download from
there.
The only way I would think that the user would know what is needed is to
start with the entire tree in /lib/firmware and check dmesg to see what
it wants and then delete the rest. I would think there is a better way.
One note is that I am suprised that there are copies of firmware in the
main directory and not in vendor specific subdirectories.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Proposal: Firmware instructions
Olaf wrote:
> On 2014-03-15 04:44, Bruce Dubbs wrote:
>
>> Hmm, just tell me in your own words how you do it. Don't worry about
>> what tools to use right now.
>
> This is how I currently create 'snapshots':
>
> # linux-firmware lives in GIT
> http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/
> # The procedure to create a snapshot is something like:
>
> git pull
> TAG=`git log -1 --pretty=format:%h`
> git archive --prefix=linux-firmware-${TAG}/ HEAD | xz >
> /linux-firmware-${TAG}.tar.xz
>
>
> Result is about ~ 22 MiB. Probably best/easiest to make that available
> via anduin?
> The archived snapshot comes with a Makefile which can be used to copy
> the lot to /lib/firmware.
> Or, if disk space is a concern, cherry pick the ones you need.
OK, I'll try this and see want is there. I personally don't need any
firmware so I haven't had a need in the past.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Proposal: Firmware instructions
Armin K. wrote: > On 03/15/2014 02:36 AM, Bruce Dubbs wrote: >> Armin K. wrote: >>> I have noticed that we don't seem to cover firmware installation >>> anywhere in LFS. The trick is that some modern network cards and most >>> wireless ones require firmware to function. Radeon cards also require >>> firmware (most of them does iirc) but we cover that in BLFS. It doesn't >>> stop there, but I find these 3 cases to be most common ones. >>> >>> It would be nice if we included some instructions about firmware in LFS. >>> >>> Most of the firmware can be downloaded from kernel.org git repository: >>> >>> https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/ >>> >>> Some firmware is shipped in the kernel tree. >> >> Firmware is tied pretty tightly to the kernel. I suppose a section at >> the end of Section 8.3 right after Configuring Linux Module Load Order >> would be educational. Would like to make a draft of what you have in mind? > I could write something, but I always get stuck at "How the hell do I > point someone to download the firmware?". Sure, I can link to kernel.org > tree, which is in a git repository but that isn't practical to download > such big number of files. Telling someone to use git to download it > isn't something for just pure LFS. What would you suggest on this issue? Hmm, just tell me in your own words how you do it. Don't worry about what tools to use right now. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Proposal: Firmware instructions
Armin K. wrote: > I have noticed that we don't seem to cover firmware installation > anywhere in LFS. The trick is that some modern network cards and most > wireless ones require firmware to function. Radeon cards also require > firmware (most of them does iirc) but we cover that in BLFS. It doesn't > stop there, but I find these 3 cases to be most common ones. > > It would be nice if we included some instructions about firmware in LFS. > > Most of the firmware can be downloaded from kernel.org git repository: > > https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/ > > Some firmware is shipped in the kernel tree. Firmware is tied pretty tightly to the kernel. I suppose a section at the end of Section 8.3 right after Configuring Linux Module Load Order would be educational. Would like to make a draft of what you have in mind? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS and Git
Bruce Dubbs wrote: > I've been working trying to understand Git a little better and trying to > evaluate whether it is appropriate for LFS to migrate. > > What I've done is to copy the alfs repository to anduin and work with > that copy. > git clone git://git.linuxfromscratch.org/alfs.git > > After download, you can 'cd alfs' and look around. As an additional experiment, I installed and configured Trac 1.0.1 on anduin: http://anduin.linuxfromscratch.org:8000/alfs/ I pointed it to the alfs git clone I created above. The 'browse source' works, but I don't really like the revision log. The hexadecimal 'Rev' just doesn't seem comfortable. It also looks like a lot of change info has been lost. For instance, if I go to jhalfs/jhalfs.sh, there is only one rev in the history. I've set this trac version up so it accepts new tickets from anonymous users. The anonymous user can also change a ticket. I intend to blow this instance away eventually since it is only a test. Also, comparing Trac, I don't see a lot of difference between the version we are currently using, 0.12.3, and the latest version 1.0.1. Please explore and provide feedback. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS and Git
Pierre Labastie wrote: > Just a few more notes about my experience about subversion and git > (more limited for the latter): > - about branching and merging: I created a branch with subversion > for the BLFS part of jhalfs. After moving directories around, I couldnot > merge anymore from the trunk, because the different tree layout > confused the merge. I had to cherry pick revisions from trunk to > branch, and that was just doubling the work. When I merged > everything at the end, it took quite a while to get everything right. > Of course, git is much better in this respect. > > - I think the workflow associated to git is roughly analogous to > subversion+quilt: > svn co<--> git clone > svn up<--> git pull > quilt new <--> git checkout -b > (or nothing if working on the master branch) > quilt add <--> git add > (do it before editingfor quilt, after for git). > quilt pop <--> git checkout master > (or git stash save(master branch) > quilt push<--> git checkout > (or git stash apply (master branch)) > svn ci<--> git checkout master >+ git merge + git commit + git push > (or just git commit + git push (master branch)) Pierre, I'm not familiar with quilt. Can you explain? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [blfs-dev] LFS and Git]
Ken Moffat wrote: > On Sun, Mar 09, 2014 at 11:06:42PM -0500, Bruce Dubbs wrote: >> Ken Moffat wrote: >>>The great benefit of git is in branches - in svn, a branch is "cast >>> in stone" and is a PITA. In git, branches are just pointers. If >>> you want to maintain a stable branch, you can cherry-pick specific >>> commits from another branch (such as master). To do that on LFS or >>> BLFS, I suspect that things might work better if date changes >>> in general.ent were separated from other changes - I think CLFS has >>> usually done that. There have been at least two occasions in the >>> past when I've thought about branching BLFS, but in svn it didn't >>> seem worth the pain. >> >> cd ~/BLFS/trunk/BOOK >> cd ../../branches >> svn cp ../trunk/BOOK my-new-branch >> #edit as required >> svn commit -m "Added new branch.." >> >> Well maybe you can do that in git in one line, but how often is that >> needed? The only time I need that is to do a release. >> > My impression, from looking at the Red Book when I first thought > about this, is that maintaining branches in svn is _hard_. Perhaps > I'm wrong, but with svn I've seen nothing to suggest that branching is > trivial. > > With git, multiple branches are definitely trivial. The result, > from my POV, is that in svn people avoid branches unless they _have_ > to use them, whereas in git they are no big deal. You have used an > svn branch for a relase, but I'm not willing to set up an svn branch > _unless_ I'm intending to use it to make a release. > > Perhaps svn branches are easier than the Red Book implies - if so, > they ought to fix their docs :-) I agree. They want you to make the branch directly in the remote repository and you need to remember the syntax for that. Ugly. Later I developed the above technique for creating a branch. It's not as elegant as git branches, but it's not as ugly as the SVN book. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [blfs-dev] LFS and Git]
Ken Moffat wrote: > - Forwarded message from Ken Moffat - > > #?^€^ ! I managed to send the reply to blfs instead of lfs. > > On Sun, Mar 09, 2014 at 09:16:42PM -0500, Bruce Dubbs wrote: >> >> Merging is generally not needed by me, but that may be the reason Armin >> wants to move to git. I can't remember the last time I needed to do a >> merge. >> > > My back story : I used to contribute to CLFS, but I dropped out > when it went to git beccause at that stage i only knew enough to > break things. Since then, I've moved my own buildscripts to git. > I've broken things a couple of times in my own merges, but now I > feel fairly confident in using it. For me, git merge --no-ff -m > "some message" lets me put a message in my git log (probably not > relevant ot LFS/BLFS), and when merges fail (e.g. because I put a > fix in my master branch, then later put a better fix in my > development branch), "git status ; git diff file-with-problem"shows > what needs to be fixed. > > The great benefit of git is in branches - in svn, a branch is "cast > in stone" and is a PITA. In git, branches are just pointers. If > you want to maintain a stable branch, you can cherry-pick specific > commits from another branch (such as master). To do that on LFS or > BLFS, I suspect that things might work better if date changes > in general.ent were separated from other changes - I think CLFS has > usually done that. There have been at least two occasions in the > past when I've thought about branching BLFS, but in svn it didn't > seem worth the pain. cd ~/BLFS/trunk/BOOK cd ../../branches svn cp ../trunk/BOOK my-new-branch #edit as required svn commit -m "Added new branch.." Well maybe you can do that in git in one line, but how often is that needed? The only time I need that is to do a release. > As has been said, with git you can stash changes, work on fixing > something else, and then go back to them. That is often a great > benefit. > > The big benefit of svn is increasing decimal revision numbers. > Mercurial seems to provide that (as well as hashed commit numbers), > but I cannot see any reason to move to mercurial. When CLFS changed > to git, it appeared that a "gatekeeper" was needed to pull changes, > but freedesktop.org, or at least the xorg parts, appear to have many > people commiting to the master branches. > > I understand why alfs is a good place to try out changes, but it > isn't something I can use (/sources on my development machines is an > nfs mount from my server, I _really_ don't fancy the time it would > take to build there). > > Also, I think Igor has an svn->git feed to github ? I would > welcome his comments. Me too. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS and Git
William Harrington wrote: > > On Mar 9, 2014, at 6:19 PM, Bruce Dubbs wrote: > >> I've been working trying to understand Git a little better and >> trying to >> evaluate whether it is appropriate for LFS to migrate. >> > > Here is an article which presents why a person should move to GIT. > > http://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git > > And as you looking for an answer, it may help you understand why git > would be better suited for a project than subversion in some instances. > >> The biggest issue with git from my perspective is the learning curve. >> It's a completely different paradigm. It seems to me that it takes >> more >> commands to do things than with svn, but the main advantages are >> that it >> brings us up to what so many other open source projects are using and >> that it makes merging easier for coordinating the systemd version of >> lfs >> with the main version. This would be especially important if we >> want to >> create a systemd version of BLFS. > > It depends what you are doing between GIT and subversion for the > commands to be more complex or not. Overall, we definitely like using > GIT for CLFS than Subversion, although subversion is still good in > some instances, such as our patch repo. > > With the amount of development that occurs with LFS, it's rather busy > every day. You will find that after a week or so and when all of the > developers understand how to use git and aren't afraid of messing up a > repo, using git from day to day will be second nature. Granted, I've > used it for over 4 years and I'm still learning how to do things. > Recently I setup my own git server and installed cgit and learned to > mirror repos. > > Most commonly I'll pull, and make some changes, and if I don't like > them, I'll reset head back to the last pull, or if I need to work on > something else, I'll stash my changes and then pull, work on > something, then push. Then I can resetore my stash and continue work. > Or, I'll make a git diff of what I'm doing, restore the diff later > depending if it is needed. Then once changes are all well, run a test > render and make sure the book validates, then I push the changes. > > It is good to have quality control. Make sure how changes will be > committed and how the commit messages will be formatted. Do you change > one file and commit and put exactly what was changed, or change a > bunch of files and one commit and make a huge message about what was > changed or a summary, etc?. A standard way of commits is very helpful. > I don't think CLFS set this up, and I think LFS would benefit greatly > from it. I mostly had to go off what the early development with git > commits were. Well there is a difference between LFS and BLFS. Although there are several devs authorized to commit to LFS, in the last cycle only Matt and I did so. BLFS had seven committers in the same cycle. Generally the only collisions I see are in the changelog or possibly general.ent and then not very often. When I analyze my activities with svn, I find I only use 10 commands: checkout (rarely), update, add, mv, delete, copy, commit, status, propset (rarely), and diff. Creating a branch is only a copy inside my local sandbox and a commit. Note that only three of those require network communication. Occasional diffs from Trac are about the only thing I do from the server other than commits and updates. I did read the document you reference. "Now stop for a moment and try to remember how many times you’ve gone to get a cup of coffee while Subversion has been running some command." My answer: never. Backups may be an issue, but I think Gerard does that daily. Generally on a RAID system you have to have more than one drive to go bad to lose everything and since higgs is now on Linode, bringing up a new system is pretty fast. Merging is generally not needed by me, but that may be the reason Armin wants to move to git. I can't remember the last time I needed to do a merge. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] headers_check : should we drop it ?
Ken Moffat wrote: > I've just noticed that someone on CLFS ran 'make headers_check' and > feared that the usual error reports (from kexec.h and soundcard.h) > about "userspace cannot reference function or variable defined in the > kernel" were errors. > > In theory, running "make headers_check" allows _kernel_ devs to > check that they aren't making things worse. In practice, these two > messages have been present for as long as I can remember, without > any userspace problems that are attributable to this, nor any > interest in removing these two messages. > > So, although illustrating the command may have some use if we have > any users who plan to be kernel devs, for a normal builder it appears > to give zero utility. I suspect, as far as the book is concernd, > that it is another of those ideas which seemed like a good idea at > the time, but now serves no purpose. > > Should we just drop this command ? Perhaps we should. What is happening is that scripts/headers_check.pl is being run. The comments say: # Usage: headers_check.pl dir arch [files...] # dir: dir to look for included files # arch: architecture # files: list of files to check # # The script reads the supplied files line by line and: # # 1) for each include statement it checks if the #included file actually exists. #Only include files located in asm* and linux* are checked. #The rest are assumed to be system include files. # # 2) It is checked that prototypes does not use "extern" # # 3) Check for leaked CONFIG_ symbols Both soundcard.h and kexec.h violate #2. I don't believe these have ever caused a problem and we certainly don't address teh warnings. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] LFS and Git
I've been working trying to understand Git a little better and trying to evaluate whether it is appropriate for LFS to migrate. What I've done is to copy the alfs repository to anduin and work with that copy. Note to Pierre: nothing has been changed on the lfs server. I had to reorganize the repo for best results because the process of migrating is fairly complex and time consuming. I chose ALFS because the repo is much smaller than either the LFS or BLFS. I also created a new name for the server: git.linuxfromscratch.org. What I suggest is for -devs to get a copy of this modified repo and play with it. The command is: git clone git://git.linuxfromscratch.org/alfs.git After download, you can 'cd alfs' and look around. A comparison of svn and git commands is at http://git-scm.com/course/svn.html The one thing you can't do right now is a 'git push' to update the remote repo. Otherwise most commands should work. If you want to be able to push changes back to the server, send me your ssh public key and I can set that up for you. If we do end up deciding (and that is far from a done deal) to use git, there will be a lot of work because a lot of scripts depend on svn. The editor's guide will need to be updated and the web pages too. The biggest issue with git from my perspective is the learning curve. It's a completely different paradigm. It seems to me that it takes more commands to do things than with svn, but the main advantages are that it brings us up to what so many other open source projects are using and that it makes merging easier for coordinating the systemd version of lfs with the main version. This would be especially important if we want to create a systemd version of BLFS. I'm sending to both the lfs and blfs mailing lists, but please reply to just the lfs list to keep the thread together. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] eudev has replaced systemd in LFS
William Harrington wrote: > > On Mar 7, 2014, at 7:00 PM, William Harrington wrote: > I talked to Armin and looked up the Changes between Util linux 2.20 > and 2.21 and found that findmnt and lsblk include udev support. Not > sure what more info would be presented with udev support, but I now > see the reason more clearly. > > https://www.kernel.org/pub/linux/utils/util-linux/v2.21/v2.21-ReleaseNotes FYI. From Karel Zak 1/8/14 -- Bruce > Let me add that util-linux builds very nicely when building up the > different packages in Linux From Scratch. In our sequence when > util-linux is built, we have not yet built udev (we extract only the > udev portion out of the systemd tarball, but do that later). At that > point we have: > $ ldd /bin/findmnt > linux-vdso.so.1 (0x7fffdebff000) > libmount.so.1 => /lib/libmount.so.1 (0x7fe5c4563000) > libblkid.so.1 => /lib/libblkid.so.1 (0x7fe5c432a000) > libuuid.so.1 => /lib/libuuid.so.1 (0x7fe5c4126000) > libc.so.6 => /lib/libc.so.6 (0x7fe5c3d7c000) > /lib64/ld-linux-x86-64.so.2 (0x7fe5c479f000) > > Looking at the code, it's not clear to me what extra functionality > get_tag_from_udev() provides. That's simple -- you don't need root permissions to read from udev, but you need root permissions to parse filesystem/PT on the device by libblkid. udev has also more information collected from more sources, see for example lsblk.c where non-udev part does not provide WWN and serial number. It's also better if all system use information from one place (udev), so libblkid is fallback solution here (in findmnt, lsblk). -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Mailing list
Armin K. wrote: > On 03/08/2014 04:37 PM, MENGUAL Jean-Philippe wrote: >> Hi, >> >> Do you have an experience about the mailing lists on LFS and its >> capability to receive attached files? It seems they are rejected, but is >> it true? Because I'd like to ask contrib to send me their patches here, >> but impossible if the mailing refuses attached files. What do you think? > You should be able to send attachments to the mailing list as long as > they are not that big. You can xz compress the patches before sending > them though. The limit is 50K. Some attachments with extensions are scrubbed. exe bat cmd com pif scr vbs cpl But that shouldn't be a factor. We also have this: Remove message attachments that don't have a matching content type: multipart/mixed multipart/alternative text/plain That may be a factor, but I can add other types if needed. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Mailing list
MENGUAL Jean-Philippe wrote: Hi, Do you have an experience about the mailing lists on LFS and its capability to receive attached files? It seems they are rejected, but is it true? Because I'd like to ask contrib to send me their patches here, but impossible if the mailing refuses attached files. What do you think? The list takes attachments. -- Bruce # Configuration file for dircolors, a utility to help you set the # LS_COLORS environment variable used by GNU ls with the --color option. # Copyright (C) 1996, 1999-2008 # Free Software Foundation, Inc. # Copying and distribution of this file, with or without modification, # are permitted provided the copyright notice and this notice are preserved. # The keywords COLOR, OPTIONS, and EIGHTBIT (honored by the # slackware version of dircolors) are recognized but ignored. # Below, there should be one TERM entry for each termtype that is colorizable TERM Eterm TERM ansi TERM color-xterm TERM con132x25 TERM con132x30 TERM con132x43 TERM con132x60 TERM con80x25 TERM con80x28 TERM con80x30 TERM con80x43 TERM con80x50 TERM con80x60 TERM cons25 TERM console TERM cygwin TERM dtterm TERM eterm-color TERM gnome TERM gnome-256color TERM jfbterm TERM konsole TERM kterm TERM linux TERM linux-c TERM mach-color TERM mlterm TERM putty TERM rxvt TERM rxvt-cygwin TERM rxvt-cygwin-native TERM rxvt-unicode TERM screen TERM screen-256color TERM screen-bce TERM screen-w TERM screen.linux TERM vt100 TERM xterm TERM xterm-16color TERM xterm-256color TERM xterm-88color TERM xterm-color TERM xterm-debian # Below are the color init strings for the basic file types. A color init # string consists of one or more of the following numeric codes: # Attribute codes: # 00=none 01=bold 04=underscore 05=blink 07=reverse 08=concealed # Text color codes: # 30=black 31=red 32=green 33=yellow 34=blue 35=magenta 36=cyan 37=white # Background color codes: # 40=black 41=red 42=green 43=yellow 44=blue 45=magenta 46=cyan 47=white #NORMAL 00 # no color code at all #FILE 00 # regular file: use no color at all RESET 0 # reset to "normal" color DIR 01;34 # directory LINK 01;36 # symbolic link. (If you set this to 'target' instead of a # numerical value, the color is as for the file pointed to.) HARDLINK 44;37 # regular file with more than one link FIFO 40;33 # pipe SOCK 01;35 # socket DOOR 01;35 # door BLK 40;33;01 # block device driver CHR 40;33;01 # character device driver ORPHAN 40;31;01 # symlink to nonexistent file, or non-stat'able file SETUID 37;41 # file that is setuid (u+s) SETGID 30;43 # file that is setgid (g+s) CAPABILITY 30;41 # file with capability STICKY_OTHER_WRITABLE 30;42 # dir that is sticky and other-writable (+t,o+w) OTHER_WRITABLE 34;42 # dir that is other-writable (o+w) and not sticky STICKY 37;44 # dir with the sticky bit set (+t) and not other-writable # This is for files with execute permission: EXEC 01;32 # List any file extensions like '.gz' or '.tar' that you would like ls # to colorize below. Put the extension, a space, and the color init string. # (and any comments you want to add after a '#') # If you use DOS-style suffixes, you may want to uncomment the following: #.cmd 01;32 # executables (bright green) #.exe 01;32 #.com 01;32 #.btm 01;32 #.bat 01;32 # Or if you want to colorize scripts even if they do not have the # executable bit actually set. #.sh 01;32 #.csh 01;32 # archives or compressed (bright red) .tar 01;31 .tgz 01;31 .arj 01;31 .taz 01;31 .lzh 01;31 .lzma 01;31 .zip 01;31 .z 01;31 .Z 01;31 .dz 01;31 .gz 01;31 .bz2 01;31 .bz 01;31 .tbz2 01;31 .tz 01;31 .deb 01;31 .rpm 01;31 .jar 01;31 .rar 01;31 .ace 01;31 .zoo 01;31 .cpio 01;31 .7z 01;31 .rz 01;31 # image formats .jpg 01;35 .jpeg 01;35 .gif 01;35 .bmp 01;35 .pbm 01;35 .pgm 01;35 .ppm 01;35 .tga 01;35 .xbm 01;35 .xpm 01;35 .tif 01;35 .tiff 01;35 .png 01;35 .svg 01;35 .svgz 01;35 .mng 01;35 .pcx 01;35 .mov 01;35 .mpg 01;35 .mpeg 01;35 .m2v 01;35 .mkv 01;35 .ogm 01;35 .mp4 01;35 .m4v 01;35 .mp4v 01;35 .vob 01;35 .qt 01;35 .nuv 01;35 .wmv 01;35 .asf 01;35 .rm 01;35 .rmvb 01;35 .flc 01;35 .avi 01;35 .fli 01;35 .flv 01;35 .gl 01;35 .dl 01;35 .xcf 01;35 .xwd 01;35 .yuv 01;35 # http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions .axv 01;35 .anx 01;35 .ogv 01;35 .ogx 01;35 # audio formats .aac 00;36 .au 00;36 .flac 00;36 .mid 00;36 .midi 00;36 .mka 00;36 .mp3 00;36 .mpc 00;36 .ogg 00;36 .ra 00;36 .wav 00;36 # http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions .axa 00;36 .oga 00;36 .spx 00;36 .xspf 00;36 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] eudev has replaced systemd in LFS
xinglp wrote: > 2014-03-08 3:54 GMT+08:00 Bruce Dubbs : >> xinglp wrote: >>> 2014-03-08 2:09 GMT+08:00 Bruce Dubbs : >>>> xinglp wrote: >>>> >>>>>> And most importantly, /dev/disk was not created. >>>> >>>>> I got it, eudev should be after util-linux, for libblkid >>>> >>>> It's not picking up util-linux from Chapter 5? If not, we'll need to >>>> adjust some flags. >>> In the last version I build with jhalfs, udevd not linked to libblkid.so >> >> OK, I see in my log I have >> >> checking for BLKID... no >> >> looking at the configure script, I think we need to add: >> >> PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/tools/lib/pkgconfig as a part of the >> ./configure line. >> >> A more straight forward way might be to add: >> >> BLKID_CFLAGS=-I/tools/include BLKID_LIBS=-L/tools/lib >> >> Do you want to test that for us? > Yes, I'm doing this now. Thanks. I did a build test, but have not rebooted this iteration to check functionality yet. It will finish in about 4 hours on machine. > And I just finished a build with eudev after util-linux, it boot fine, > but enpXsXX change to eth0 again. Yes, that's intended now. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] eudev has replaced systemd in LFS
William Harrington wrote: > > On Mar 7, 2014, at 1:56 PM, Bruce Dubbs wrote: > >> There is a circular dependency between util-linux and udev/eudev. >> That's why I added util-linux to Chapter 5. > > Well util linux is great for tools when booting or chroot, but why is > it so late in your final system build in ch6? > > The problem is that ch6 eudev is after util-linux. > > Has nothing to do with util-linux needing to be in temp system. > You also have to be careful where you put util linux in your build for > test suite results. I was also seeing in CLFS we have iana-etc after > util-linux and that affects test suite failures. As long as you have > Util linux before udev, and after iana-etc, should be fine in most > cases. I had a conversation with the util-linux devs and they said there were some advantages to building after udev but the capabilities were silently left out if not. But udev needs BLKID in util-linux. That's why I added util-linux to Ch 5. So what we have is util-linux in Ch 5 eudev in Ch 6 util-linux in Ch 6 That reminds me. I still need to update C. Dependencies for eudev. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] eudev has replaced systemd in LFS
Armin K. wrote: > On 03/07/2014 08:37 PM, Bruce Dubbs wrote: >> William Harrington wrote: >>> >>> On Mar 7, 2014, at 11:51 AM, xinglp wrote: >>> >>>> When use initrd, with /dev/disk/by-xxx present, I can use >>>> root=UUID=xxx instead of root=/dev/sdxx >>> >>> Your initrd should do that. You need to troubleshoot your initrd. >> >> What you really want to do is use gpt: >> >> >> http://www.linux-archive.org/gentoo-user/481167-mounting-root-partition-uuid-no-initrd-needed.html >> >> -- Bruce >> > > It should be fixed nonetheless. /dev/disk/by-label /dev/disk/by-id and > /dev/disk/by-uuid are used by many people and required by lots of programs. Sure. We are testing now. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] eudev has replaced systemd in LFS
xinglp wrote: > 2014-03-08 2:09 GMT+08:00 Bruce Dubbs : >> xinglp wrote: >> >>>> And most importantly, /dev/disk was not created. >> >>> I got it, eudev should be after util-linux, for libblkid >> >> It's not picking up util-linux from Chapter 5? If not, we'll need to >> adjust some flags. > In the last version I build with jhalfs, udevd not linked to libblkid.so OK, I see in my log I have checking for BLKID... no looking at the configure script, I think we need to add: PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/tools/lib/pkgconfig as a part of the ./configure line. A more straight forward way might be to add: BLKID_CFLAGS=-I/tools/include BLKID_LIBS=-L/tools/lib Do you want to test that for us? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] eudev has replaced systemd in LFS
William Harrington wrote: > > On Mar 7, 2014, at 12:36 PM, xinglp wrote: > >> In the last version I build with jhalfs, udevd not linked to >> libblkid.so > > i can't figure out why util-linux is so late in the build for LFS, but > yes, eudev will use pkg-config to find it's deps and eudev should be > after util-linux. There is a circular dependency between util-linux and udev/eudev. That's why I added util-linux to Chapter 5. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] grammo - lfs75 - ch9 reboot ?
akhiezer wrote: > ref: http://www.linuxfromscratch.org/lfs/view/7.5/chapter09/reboot.html > "Now that we have said that, lets move on to booting" > > s/lets/let's/ ? (let's == "let us"). > > (Noticed it while working with 7.4; and is still there in 7.5; seems to > be in several - didn't check 'em all - rels back to & incl at least 6.1 ). > > Or is that deemed to be not a typo/grammatical-err? Yes it is a grammar error. Use the svn blame command: $ svn blame chapter09/reboot.xml |grep lets 7228 manuel Now that we have said that, lets move ... That was done 12/18/05. It went back to rev 4648 (02/19/05) and that was brought over from the testing book we had at the time. Finding the testing branch, it looks like it was first added at rev 4451 (12/22/04). :) I'll fix it at next commit. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] eudev has replaced systemd in LFS
William Harrington wrote: > > On Mar 7, 2014, at 11:51 AM, xinglp wrote: > >> When use initrd, with /dev/disk/by-xxx present, I can use >> root=UUID=xxx instead of root=/dev/sdxx > > Your initrd should do that. You need to troubleshoot your initrd. What you really want to do is use gpt: http://www.linux-archive.org/gentoo-user/481167-mounting-root-partition-uuid-no-initrd-needed.html -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] grammo - lfs75 - ch9 reboot ?
akhiezer wrote: > ref: http://www.linuxfromscratch.org/lfs/view/7.5/chapter09/reboot.html > "Now that we have said that, lets move on to booting" > > s/lets/let's/ ? (let's == "let us"). > > (Noticed it while working with 7.4; and is still there in 7.5; seems to > be in several - didn't check 'em all - rels back to & incl at least 6.1 ). > > Or is that deemed to be not a typo/grammatical-err? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] eudev has replaced systemd in LFS
xinglp wrote: >> And most importantly, /dev/disk was not created. > I got it, eudev should be after util-linux, for libblkid It's not picking up util-linux from Chapter 5? If not, we'll need to adjust some flags. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] eudev has replaced systemd in LFS
xinglp wrote: > 2014-03-07 7:14 GMT+08:00 Bruce Dubbs : >> I've replaced systemd wuth eudev in LFS. Please have a look and test. >> Feedback welcomed. > > /etc/rc.d/init.d/udev line 52 > replace /lib/udev/udevd with /sbin/udevd Right. I did that when testing but forgot to update the boot scripts in the book. > And most importantly, /dev/disk was not created. Don't know right now. Is it needed? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] eudev has replaced systemd in LFS
Armin K. wrote: > On 03/07/2014 12:14 AM, Bruce Dubbs wrote: >> I've replaced systemd wuth eudev in LFS. Please have a look and test. >> Feedback welcomed. >> >> -- Bruce >> > > Title is a bit missleading. > > Maybe "eudev has replaced systemd-udev in LFS"? > > LFS never had systemd itself, only the "extracted-by-hand" udev from > systemd tree. In one sense you are right, but we did download and use the systemd tarball and that has been replaced by the eudev tarball. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] eudev has replaced systemd in LFS
I've replaced systemd wuth eudev in LFS. Please have a look and test. Feedback welcomed. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Creating dirs in chapter06
John Burrell wrote: > I just noticed this: > > x86_64) ln -sv lib /lib64 && > ln -sv lib /usr/lib64 && > > As far as I'm aware this is the first instance of && in LFS. > > Is this the thin end of a wedge or a slip? > > Personally, I would prefer you to remove it to leave LFS consistent in this > regard. OK. I don't think they are needed either. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] udev, eudev, mdev
Bruce Dubbs wrote: > Armin K. wrote: >> On 03/05/2014 10:58 PM, William Harrington wrote: >>> >>> On Mar 5, 2014, at 3:09 PM, Bruce Dubbs wrote: >>> >>>> FAIL: udev-test.pl >>>> PASS: rules-test.sh >>>> ... >>>> See test/test-suite.log >>> >>> Same as we have had in CLFS since migrating to eudev. >>> >>> Sincerely, >>> >>> William Harrington >>> >> >> Same test fails in systemd, too. I have simply disabled it with a sed. >> > yes: > > sed -i '/devnode substitution/ a exp_add_error => "yes",' \ >test/udev-test.pl > > Make the error expected. Found the error. The test has a rule where it hard codes /usr/bin/test. We don't have that. We have /bin/test as is should if we are going to support a split / -- /usr setup. In any case the sed should be: sed -r -i 's|/usr(/bin/test)|\1|' test/udev-test.pl -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] udev, eudev, mdev
Ken Moffat wrote:
> I built eudev in LFS-7.5 chroot like this:
Thanks for those instructions Ken. I took those and built in chroot
with these:
sed -i '/devnode substitution/ a exp_add_error => "yes",' test/udev-test.pl
sed -i '/struct ucred/i struct ucred;' src/libudev/util.h
./configure --prefix=/usr \
--sysconfdir=/etc \
--with-rootprefix= \
--libexecdir=/lib \
--enable-split-usr \
--enable-libkmod\
--libdir=/usr/lib \
--with-rootlibdir=/lib \
--sbindir=/sbin \
--bindir=/sbin \
--enable-rule_generator \
--disable-introspection \
--disable-keymap\
--disable-gudev \
--disable-gtk-doc-html \
--with-firmware-path=/lib/firmware
make
mkdir -pv /lib/{firmware,udev/devices/pts}
mkdir -pv /etc/udev/rules.d
mkdir -pv /lib/udev/rules.d
make check
install -dv $DEST/lib/firmware
make DESTDIR=$DEST install
--
The first sed sets the failing test to expected. I'll look into that
some more. With it, the check is clean.
The second sed cleans up some irritating warnings.
Almost everything is as it should be, except the man pages are not
installed. We will probably have to create a patch or tarball for
those. It would probably be easier as a patch.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
[lfs-dev] BLFS-7.5 is released
The Linux From Scratch community is pleased to announce the release of BLFS Version 7.5. This version includes approximately 750 packages beyond the base Linux From Scratch Version 7.5 book. The book has over 700 significant updates from the previous version as well as numerous text and formatting changes. You can read the book online[0], or download[1] to read locally. Please direct any comments about this release to the LFS development team at blfs-...@linuxfromscratch.org. Please note that registration for the blfs-dev mailing list is required to avoid junk email. [0] http://www.linuxfromscratch.org/blfs/view/7.5/ [1] http://www.linuxfromscratch.org/blfs/downloads/7.5/ -- Bruce Dubbs LFS -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] udev, eudev, mdev
Armin K. wrote: > On 03/05/2014 10:58 PM, William Harrington wrote: >> >> On Mar 5, 2014, at 3:09 PM, Bruce Dubbs wrote: >> >>> FAIL: udev-test.pl >>> PASS: rules-test.sh >>> ... >>> See test/test-suite.log >> >> Same as we have had in CLFS since migrating to eudev. >> >> Sincerely, >> >> William Harrington >> > > Same test fails in systemd, too. I have simply disabled it with a sed. > yes: sed -i '/devnode substitution/ a exp_add_error => "yes",' \ test/udev-test.pl Make the error expected. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Project contributor names
MENGUAL Jean-Philippe wrote: > Hi, > > Ok I'm not direct contributor to LFS and F can understand that > translation stuff isn't the priority of the upstream devs. However, I'd > like to tell you that with git, it became painful to translate > cross-lfs. We are now unable to release at the same time, synchronously, > because unable to understand the revisions, branches, and fuzzy commit > reports. Probably we sohuld learn git, but F've tried for years without > success. So spending again a while on this would be painful. All the > more as for BLFS, project very stressed due to its size, any freeze > would be somewhat a problem (disappoint the contrib, taking delay). For > translators, it would imply to update our utilities, mandatory to be > efficient with blfs given the size of the project. Again here, git will > be painful. > > Finally I think svn is suit to the lfs project and its current workflow. > But it's only my opinion. It could deal with a new branch such as > systemd without pain, and translating it will be possible as soon as a > contrib ask it. And if, someday, systemd becomes trunk, we'll translate > it (I don't know what's the state of this debate in lfs team because > writing the bootscripts was a big work for Bruce). > > That's why I'd really ask to be careful switching to git, and please > help us, because it's a pitty to change what works to something so > unsafe in project management matter. Unsafe not due to the tool, but to > the men who use it. I wouldn't call it unsafe. There are a lot of projects using git. I do think there is a non-trivial learning curve. That said, we will very carefully consider the proposal for using git. We will not change unless we see some specific advantages that out-weigh the disadvantages. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] udev, eudev, mdev
Ken Moffat wrote:
> On Tue, Mar 04, 2014 at 11:37:32AM -0600, William Harrington wrote:
>>
>> On Mar 4, 2014, at 10:43 AM, Bruce Dubbs wrote:
>>
>>> eudev wants gperf and gtk-doc. We could add gperf to LFS and probably
>>> do away with both gperf and the gudev build in BLFS. gtk-doc needs
>>> several other prerequisites and is not a candidate for LFS, but I
>>> don't
>>> think that's needed.
>>
>> In CLFS we use Eudev up to v 1.4 and that doesn't require gperf and
>> gtk-doc.
>>
>> http://dev.gentoo.org/~blueness/eudev/
>>
>> Grab the tarballs from there.
>>
>> Sincerely,
>>
>> William Harrington
>
> I've been using that version with LFS-7.5, so thanks for putting it
> in clfs - much easier to find the released version by looking in
> your book than by trying to find a working link from google ;-)
> Unfortunately, like many github projects, eudev doesn't go out of its
> way to point to released tarballs. Also, I think I now use your
> command switches.
>
> When systemd swallowed udev, I initially tried a separate
> stand-alone udev, but eudev seems to have gained a sufficient number
> of maintainers who are prepared to look at what is happening in
> systemd and decide whether or not to use any of each change. I
> don't always agree with their judgement (specifically, they took
> systemd's mysterious naming of the ethernet port), but it all seems
> to work well enough.
>
> There was a suggestion in the past few months that 'tree' was
> needed for the eudev testsuite, but it doesn't seem to add anything
> for me so I've now dropped it.
>
> I built eudev in LFS-7.5 chroot like this:
>
> 1. it doesn't seem to need the symlinks for the blkid and uuid
> headers, nor the library path.
>
> 2. create directories
> install -dv /lib/{firmware,udev/devices/pts}
>
> 3. configure
> ./configure --prefix=/usr --sysconfdir=/etc \
> --with-rootprefix="" --libdir=/usr/lib \
> --with-firmware-path=/usr/lib/firmware \
> --with-rootlibdir=/lib --exec-prefix="/" \
> --enable-split-usr --enable-libkmod --enable-rule-generator \
> --disable-static --disable-introspection \
> --disable-gudev --disable-keymap
>
> 4. make : it looks as if multiple make works, at least in LFS
> (I see that my rebuild in BLFS for gudev still has -j1, never got
> around to confirming that -jN works there).
>
> 5. create directories to allow the tests to work in an empty system:
> mkdir -pv /etc/udev/rules.d
> mkdir -pv /lib/udev/rules.d
>
> 6. the tests:
> make check
>
> This reports that both tests passed. I am uncertain if the first
> test actually does anything (its log is empty, even in BLFS - I found
> a suggestion that Python was needed, but that made no difference),
> unless python3 was what was meant (they are gentoo devs, so I guess
> that is a possibility) but the second test is the old perl script of
> 135 tests which date back to udev. Their detailed output is in
> test/udev-test.pl.log, I find it reassuring to save that file.
In the chroot environment I get one failure in the udev-test.pl script.
The make check says:
FAIL: udev-test.pl
PASS: rules-test.sh
...
See test/test-suite.log
Looking at the log, I see several items:
open /dev/null failed: No such file or directory
but there certainly is
crw-rw-rw- 1 root root 1, 3 Feb 28 17:24 /dev/null
in chroot. However that does not cause the test to fail.
What I do have is:
TEST 93: devnode substitution test
device
'/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda'
expecting node/link 'node'
open /dev/null failed: No such file or directory
add: error
remove: ok
I do have
/sys/devices/pci:00/:00:1f.2
but there is no host0 there. Searching, I also have:
/sys/devices/pci:00/:00:1f.2/ata1/host0/target0:0:0/0:0:0:0
I'm not sure if this is significant or not, but I get exactly the same
error in a full up system. tree gives:
test/dev
|-- block
| `-- 8:0 -> ../sda
|-- char
`-- sda
I'm don't know how to interpret that.
Does anyone have ideas about the test failure?
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Project contributor names
William Harrington wrote: > > On Mar 4, 2014, at 7:16 PM, Armin K. wrote: > >> Well, I guess if we decide to migrate to git, we'll have some sort of >> online browser like cgit or gitweb >> >> For example, freedesktop.org uses cgit, here's the mesa repository. >> >> http://cgit.freedesktop.org/mesa/mesa/ >> >> Just click on any of the commits below and you can easily see what's >> changed. >> >> I expect that lfs-book and blfs-book mailing lists should still be >> there, although mail format might be different than the current one. > > I moved from gitweb to cgit, and I'm liking cgit a lot. Gitweb > shouldn't be used. > > Also, it's much easier to view what is going on with cgit, than gitweb. > > The only problem is that a test repo needs to be created if the LFS > project goes to git. > > The devs will need to take some time to learn about git and making > sure they know how to use it properly. I certainly agree. > When we moved to git with CLFS, a guide was created for devs to read. > > http://trac.cross-lfs.org/wiki/Basic%20Git%20Usage Yes, we would need to update the developers guide. I've gone through a similar tutorial and have an O'Reilly book on git, but my concern is how to create and maintain the remote server. I know Armin is working on that. > Some things have changed long ago when that was created, but it'll help. > > As far as getting the initial git repository going and all of that, > you've done most of the work. It's all about deploying it now if the > community decides to go with git. > > There has to be a freeze to take the time to migrate svn to git, it > does take time because svn repo has been around for 10 years or so. > It'll take 12 hours or so for each repo (as you stated on your system). First commit for LFS was December 29, 2000. First commit for BLFS was May 29, 2002, but that was a conversion from CVS. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] udev, eudev, mdev
Ken Moffat wrote:
> On Tue, Mar 04, 2014 at 11:37:32AM -0600, William Harrington wrote:
>>
>> On Mar 4, 2014, at 10:43 AM, Bruce Dubbs wrote:
>>
>>> eudev wants gperf and gtk-doc. We could add gperf to LFS and probably
>>> do away with both gperf and the gudev build in BLFS. gtk-doc needs
>>> several other prerequisites and is not a candidate for LFS, but I
>>> don't
>>> think that's needed.
>>
>> In CLFS we use Eudev up to v 1.4 and that doesn't require gperf and
>> gtk-doc.
>>
>> http://dev.gentoo.org/~blueness/eudev/
>>
>> Grab the tarballs from there.
>>
>> Sincerely,
>>
>> William Harrington
>
> I've been using that version with LFS-7.5, so thanks for putting it
> in clfs - much easier to find the released version by looking in
> your book than by trying to find a working link from google ;-)
> Unfortunately, like many github projects, eudev doesn't go out of its
> way to point to released tarballs. Also, I think I now use your
> command switches.
>
> When systemd swallowed udev, I initially tried a separate
> stand-alone udev, but eudev seems to have gained a sufficient number
> of maintainers who are prepared to look at what is happening in
> systemd and decide whether or not to use any of each change. I
> don't always agree with their judgement (specifically, they took
> systemd's mysterious naming of the ethernet port), but it all seems
> to work well enough.
>
> There was a suggestion in the past few months that 'tree' was
> needed for the eudev testsuite, but it doesn't seem to add anything
> for me so I've now dropped it.
>
> I built eudev in LFS-7.5 chroot like this:
>
> 1. it doesn't seem to need the symlinks for the blkid and uuid
> headers, nor the library path.
>
> 2. create directories
> install -dv /lib/{firmware,udev/devices/pts}
>
> 3. configure
> ./configure --prefix=/usr --sysconfdir=/etc \
> --with-rootprefix="" --libdir=/usr/lib \
> --with-firmware-path=/usr/lib/firmware \
> --with-rootlibdir=/lib --exec-prefix="/" \
> --enable-split-usr --enable-libkmod --enable-rule-generator \
> --disable-static --disable-introspection \
> --disable-gudev --disable-keymap
>
> 4. make : it looks as if multiple make works, at least in LFS
> (I see that my rebuild in BLFS for gudev still has -j1, never got
> around to confirming that -jN works there).
>
> 5. create directories to allow the tests to work in an empty system:
> mkdir -pv /etc/udev/rules.d
> mkdir -pv /lib/udev/rules.d
>
> 6. the tests:
> make check
>
> This reports that both tests passed. I am uncertain if the first
> test actually does anything (its log is empty, even in BLFS - I found
> a suggestion that Python was needed, but that made no difference),
> unless python3 was what was meant (they are gentoo devs, so I guess
> that is a possibility) but the second test is the old perl script of
> 135 tests which date back to udev. Their detailed output is in
> test/udev-test.pl.log, I find it reassuring to save that file.
>
> 7. install, create a /sbin/udevd symlink for the LFS bootscripts,
> update the hardware db (I've still no idea what that is for) and in
> my case ensure that my wired nic is called eth0:
>
> make install
> ln -svf /sbin/udevd /lib/udev
> udevadm hwdb --update
> echo "# dummy, so that network is once again on eth0" \
> >/etc/udev/rules.d/80-net-name-slot.rules
>
> For BLFS, I rebuild it after Xorg on desktops to get gudev : gperf
> is already present, so I just omit --disable-gudev (I don't need
> keymap for a normal keyboard, nor introspection in my normal build -
> but I did remove --disable-introspection to build the gir stuff when
> I was building for gnome packages.
Thanks Ken. I'm building a eudev system now for testing. It may take a
couple of iterations to get all the details right, but it looks like the
way to go. The extraction I was doing was a PITA because of upstream's
mixing in non-udev stuff which kept making the task more and more
difficult.
I can change the boot script to point to the new location for udevd
easily enough. We'll need to update Section 7.4 also.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
