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. > >> </sarcasm> >> >> Error: tag </sarcasm> 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
