You are not logged in.

#26 2012-08-29 11:24:24

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

Thanks for all of that.

I should have mentioned that I'd already figured out a work around for syslog-ng along the lines you suggest. Only I did it the other way - I made the systemd version the default and then edited the config file in /etc/conf.d to read syslog.ng.conf.initscripts which is a copy of the original config file.

There's nothing about the alsa daemon I prefer. I'm not trying to run it at all. It's picking stuff up from rc.conf even though I've masked arch-daemons.target. However, masking has made some difference. It no longer reports alsa failed even though I booted with sound muted. However, it is still thinking alsa is enabled. For comparison, here's what it says about the status of alsa an svnserve. alsa is in rc.conf. svnserve is not.

$ systemctl status alsa
alsa.service - Legacy unit for alsa
          Loaded: loaded (/etc/rc.conf)
          Active: inactive (dead)
            Docs: man:arch-daemons(8)
          CGroup: name=systemd:/system/alsa.service

$ systemctl status svnserve
svnserve.service - Subversion protocol daemon
          Loaded: loaded (/usr/lib/systemd/system/svnserve.service; disabled)
          Active: inactive (dead)
          CGroup: name=systemd:/system/svnserve.service

I don't think the resume issue is systemd related - I can reproduce it with initscripts. It worked perfectly under both before I did pacman -Syu yesterday and got the latest kernel. But it happens even with the LTS. I have a separate thread on this, actually. I'm trying to figure out if it is a hardware issue or not. I'm going to try calling the local Lenovo service people and see if they can offer any insights in little bit, I think. (If I can find their phone number again...)

The main reason I don't want to switch to pure systemd right now is that the emergency shell isn't supported. I'm just waiting for the update to util-linux to filter through so that sulogin is available.


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#27 2012-08-29 11:48:00

progandy
Member
Registered: 2012-05-17
Posts: 5,180

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

The main reason I don't want to switch to pure systemd right now is that the emergency shell isn't supported. I'm just waiting for the update to util-linux to filter through so that sulogin is available.

There is an AUR package available for the missing tools called systemd-syvinit. I added it to the wiki.

Edit: One way to disable rc.conf parsing would be to delete usr/lib/systemd/system-generators/arch-daemons It's not pretty but does the job.

Edit: Or try to symlink /etc/systemd/system/multi-user.target.wants/arch-daemons.target  to /dev/null
If my suspicions are correct, then /usr/lib/systemd/system/multi-user.target.wants/arch-daemons.target is a relative symlink to /etc/systemd/system/arch-daemons.target. Therefore masking the whole target in etc has no effect. you'll have to mask the specific entry for multi-user.target

Last edited by progandy (2012-08-29 11:55:50)


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#28 2012-08-29 15:00:53

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

@progandy - Thanks for posting that package, I'm going to check that out.  I think that cfr already attempted to mask the package by symlinking it to /dev/null, both by manually linking, and by using the 'mask' feature of systemctl.  So it is a true mystery why it still seems to parse the rc.conf daemons line.

I think progandy's idea of deleting the damn service file altogether, is woth a shot.  I mean, it should like you are attempting to do away with its functionality altogether anyway.  Maybe just move it somewhere else in the filesystem even.

I'm sorry to hear that it is seeming like the sleep issue may be hw related.  On the one hand, it would be nice if it could just be fixed for you, but on the other, it in never cool to have broken hardware.  My experience with Lenovo support has been pretty good though.  I kind of doubt they will be able to shed any light on your system if you are running Linux.  I called because my battery was being crazy, so they wanted to log into my computer with recue123.com which is a logmein service.  That would have been fine with me, but the first step to setting it up was installing rescue123.exe... it took them a while to understand why that was not possible.  After explaining it though, they just said "oh, well since you run Linux, we'll just send you a new battery."  BTW, it tunred out the be the cmos needing resetting, the battery was fine.

Offline

#29 2012-08-29 21:04:56

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

I took it to them to have a look today but of course it then performed perfectly. (Described at https://bbs.archlinux.org/viewtopic.php … p1153343.)

I think the problem is that it is *not* a symlink to /etc/... but to the directory above:

/usr/lib/systemd/system/multi-user.target.wants/arch-daemons.target -> ../arch-daemons.target

Something is screwy with the way this works. I haven't altered anything since rebooting (several times for Lenovo's benefit but always perfectly since a technician was watching me trying to demonstrate the issue I have, of course) and yet:

$ systemctl status arch-daemons.target
arch-daemons.target
          Loaded: masked (/dev/null)
          Active: inactive (dead)


Warning: Unit file changed on disk, 'systemctl --system daemon-reload' recommended.

But it surely shouldn't be necessary to do this on every boot? In any case, it rather defeats the point of masking it.

Thanks for telling me about the AUR package. Something to consider if util-linux is delayed for long.


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#30 2012-08-29 22:59:20

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

A slightly different question (I can't try to diagnose a problem which won't currently manifest itself - hope it stays that way unless something is really wrong in which case, I hope that's obvious before the warranty is up!):

Is there an easy way to discover why a particular unit is started up? I tried generating a dot graph to show order and dependency info but the thing is enormous and so entangled that it doesn't tell me much of anything. What I'd like is just simple tree-like output on the console. A bit like systemd-cgls but showing dependencies which would explain why, say, colord-sane.service is running even though not explicitly enabled.


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#31 2012-08-29 23:49:28

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

Yeah, I tried to do the same thing with the dot graph... at first I thought it had errored and given me nothing, but then I realized that I was zoomed in some billion percent.  So I thought "great I'll zoom out and get useful information!"  God how wrong I was... I couldn't make heads or tails of what was going on there.  I think even if it were a reasonable size, just the insanity of how it lays out its depedecy tree is horrendous.  I am sure there has to be a better way of doing that.  In the mean time I have not figured out another easy way to do it (though I just kind of gave up after seeing the dot graph since I really didn't ahve any issues or anything).

Offline

#32 2012-08-29 23:58:05

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

I even installed graphviz to get it working and then had exactly the same experience - I thought it had utterly failed and then realised it was just zoomed way out. Again, no problem. Zoom in. I agree that size isn't the only problem with it. I have no idea why it is laid out like that or what one is supposed to make of the tangle. It looks like some horrendous "maze" that a small child would create and then present me with to "solve"!

Yet it seems to me that something much simpler - akin to pstree etc. - would work far better. I don't really understand why it is even part of systemd itself. Shouldn't systemd just supply the information and other applications then be used to filter and present it? Graph creation is obviously not this boot loader's strong point!

Last edited by cfr (2012-08-30 00:23:50)


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#33 2012-08-30 01:40:45

progandy
Member
Registered: 2012-05-17
Posts: 5,180

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

cfr wrote:

I don't really understand why it is even part of systemd itself. Shouldn't systemd just supply the information and other applications then be used to filter and present it? Graph creation is obviously not this boot loader's strong point!

That's exactly what systemd is doing. The output is simple textdata, each line describes one dependency, only it uses colors instead of dependency types. You can filter it as you like.
unit -> other_unit [dependency_type]
e.g.:

# polkit.service requires basic.target
	"polkit.service"->"basic.target" [color="black"];
# polkit.service conflicts shutdown.target
	"polkit.service"->"shutdown.target" [color="red"];
# polkit.service runs after systemd-journald.socket
	"polkit.service"->"systemd-journald.socket" [color="green"];
# local-fs.target wants tmp.mount
	"local-fs.target"->"tmp.mount" [color="grey66"];

| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#34 2012-08-31 01:15:26

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

No. It is outputting it in a format designed for a particular program. It shouldn't be specifying colours, for example. It would be easier to parse and post-process if it just output the keyword for the relationship. Easy enough then to colour it if you want. I realise you can undo it but that's backwards. It would be different if there were an alternative more basic way of getting the info but, if so, I have not yet found it.

I still can't figure out why particular services or targets are being started:

$ systemctl dot | grep colord
        "shutdown.target"->"colord.service" [color="red"];
        "shutdown.target"->"colord-sane.service" [color="red"];
        "shutdown.target"->"colord.service" [color="green"];
        "shutdown.target"->"colord-sane.service" [color="green"];
   Color legend: black     = Requires
                 dark blue = Requisite
                 dark grey = Wants
                 red       = Conflicts
                 green     = After
        "colord.service"->"systemd-journald.socket" [color="black"];
        "colord.service"->"dbus.socket" [color="black"];
        "colord.service"->"basic.target" [color="black"];
        "colord.service"->"shutdown.target" [color="red"];
        "colord.service"->"systemd-journald.socket" [color="green"];
        "colord.service"->"dbus.socket" [color="green"];
        "colord.service"->"basic.target" [color="green"];
        "colord-sane.service"->"systemd-journald.socket" [color="black"];
        "colord-sane.service"->"dbus.socket" [color="black"];
        "colord-sane.service"->"basic.target" [color="black"];
        "colord-sane.service"->"shutdown.target" [color="red"];
        "colord-sane.service"->"systemd-journald.socket" [color="green"];
        "colord-sane.service"->"dbus.socket" [color="green"];
        "colord-sane.service"->"basic.target" [color="green"];

If I'm reading this correctly, this means that nothing wanted or required colord.service or colord-sane.service. Moreover, these are not explicitly enabled. So why are they started on boot?


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#35 2012-08-31 02:08:10

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

Slightly different question: does sysctl.conf not work with systemd? I ask because I have ipv6 disabled using

net.ipv6.conf.all.disable_ipv6 = 1

but systemd's output shows that ipv6 seems to be being started:

dhcpcd[1216]: wlan0: sending IPv6 Router Solicitation
Aug 31 00:21:53  dhcpcd[1216]: wlan0: sendmsg: Network is unreachable
Aug 31 00:21:53  kernel: IN=wlan0 OUT= MAC= SRC=10.0.1.3 DST=224.0.0.251 LEN=86 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=
Aug 31 00:21:57  dhcpcd[1216]: wlan0: sending IPv6 Router Solicitation
Aug 31 00:21:57  dhcpcd[1216]: wlan0: sendmsg: Network is unreachable
Aug 31 00:21:57  dhcpcd[1216]: wlan0: no IPv6 Routers available

and so on...

If this is right, I have to find a way of stopping it or revert to initscripts. My university network does not support machines with ipv6 enabled. The non-support takes the form of completely screwing up all network connectivity.


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#36 2012-09-01 00:22:37

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

I've also just discovered I'm having bluetooth issues. From the journal:

kernel: thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is blocked

rfkill listed bluetooth as both hard and soft blocked. I can soft unblock it but not hard unblock it.

This is especially annoying as I had this problem early on with this laptop but it was all magically fixed by a BIOS update. I'm not sure why it should be different with systemd...


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#37 2012-09-01 02:11:18

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

I haven't a clue about the hard block of your bluetooth, but I do know that with systemd there is a sysctl.d that is able to handle the funcitonality of sysctl.  Now I am not sure if sysctl.conf is no longer parsed or what, as I have not noticed any differences.  But anything new, I have just started putting into /etc/sysctl.d and it seems to handle it nicely.  The format seems to be the same, abliet w/o the spaces between the equals sign and parameter/value.  Pretty simple, and I think if necessary, moving everything from sysctl.conf would be a breeze as well.


Edit: a bit off topic here... just yesterday, or maybe two days ago, I spent quite a while struggling to get Arch to boot with UEFI.  Or rather, I spent quite some time struggling to get Arch to boot with UEFI in the way that I wanted (EFI Stub Loader).  During my quest, I discovered your thread regarding your UEFI/Lenovo issues.  Out of curiosity, are you still using Grub2 UEFI, and did set that up (ultimately in FAT16) before your bios update mentioned above.

Last edited by WonderWoofy (2012-09-01 02:16:19)

Offline

#38 2012-09-01 02:19:07

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

You know... my bios has the ability to turn on and off various i/o functions on my machine.  For instance, I block the camera becasue I don't have one, and also the UPEK fungerprint reader because it is a new model and not yet supported by Linux (if ever).  So maybe toggling the bluetooth on and off might reset it somehow?  Just a thought.  Also is your bluetooth one of the ones that is integrated into your wifi card?

Offline

#39 2012-09-01 02:38:06

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

WonderWoofy wrote:

I haven't a clue about the hard block of your bluetooth, but I do know that with systemd there is a sysctl.d that is able to handle the funcitonality of sysctl.  Now I am not sure if sysctl.conf is no longer parsed or what, as I have not noticed any differences.  But anything new, I have just started putting into /etc/sysctl.d and it seems to handle it nicely.  The format seems to be the same, abliet w/o the spaces between the equals sign and parameter/value.  Pretty simple, and I think if necessary, moving everything from sysctl.conf would be a breeze as well.

Ah. Maybe I'll try that. I looked at the service file for the sysctl service and it seems to use sysctl.conf (as well as?) the contents of a number of directories, including /etc/sysctl.d. It could also be a kernel change.

I discovered today that my wireless is working on campus in any case. At least, it keeps dropping but it always does that to everybody in my corridor.

Edit: a bit off topic here... just yesterday, or maybe two days ago, I spent quite a while struggling to get Arch to boot with UEFI.  Or rather, I spent quite some time struggling to get Arch to boot with UEFI in the way that I wanted (EFI Stub Loader).  During my quest, I discovered your thread regarding your UEFI/Lenovo issues.  Out of curiosity, are you still using Grub2 UEFI, and did set that up (ultimately in FAT16) before your bios update mentioned above.

Yes I am still using it and I had it set up before both that bios update and one I did earlier in the year. I don't think I actually needed to use fat 16, though. I haven't tested it, but I suspect it would have worked with fat 32 if the partition had been at least 512M. (The wiki now advises this but at the time the recommendation was 100-200M and mine is under 500M.) I haven't tried using the stub loader method, though. What was the problem?

You know... my bios has the ability to turn on and off various i/o functions on my machine.  For instance, I block the camera becasue I don't have one, and also the UPEK fungerprint reader because it is a new model and not yet supported by Linux (if ever).  So maybe toggling the bluetooth on and off might reset it somehow?  Just a thought.  Also is your bluetooth one of the ones that is integrated into your wifi card?

I have this. too. I actually tried that this time. I toggled bluetooth off, saved, rebooted, logged in, noted the complete lack of bluetooth. (It doesn't even show as blocked in this case.) Then I rebooted to BIOS, enabled and rebooted. Didn't help. So I had to do what seems to work but is a right pain: boot to BIOS, load default settings, save. Reboot to BIOS and reconfigure settings. Then I need an EFI capable USB key so I can boot, chroot and use efibootmgr to recreate the menu entry for grub. I certainly hope systemd isn't going to routinely screw with it!

It is also possible that the bluetooth issue was a side-effect of the kernel panic I had yesterday on boot with systemd or the complete existence failure of X I had today while booted with systemd. It certainly hasn't improved the stability of my system...


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#40 2012-09-01 03:28:01

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

cfr wrote:

Yes I am still using it and I had it set up before both that bios update and one I did earlier in the year. I don't think I actually needed to use fat 16, though. I haven't tested it, but I suspect it would have worked with fat 32 if the partition had been at least 512M. (The wiki now advises this but at the time the recommendation was 100-200M and mine is under 500M.) I haven't tried using the stub loader method, though. What was the problem?

I have been using gpt/bios, and I wanted to make use of the uefi my system offers.  But I figured if I was going to switch, i didn't want to go from a messy and comlicated bootloader to another one just like it.  Especially since I know that UEFI is not dependent on a 440(?) byte space to boot off of.  So I did some reading about the EFI stub loader and decided that was for me.  But unfortunately, it would not accept the command line parameters I passed to it with efibootmgr.  As much as I know that many users use a custom kernel, and I have in the past when using Gentoo (obviously), I just feel like with Arch's rolling release model, I didn't want to have to remember to recompile and check configs everytime, so compiling bootloader parameters into my kernel seemed like too much work.  In the end, it turned out that it didn't like having the initramfs in /EFI/arch, so when I moved it to the root of the ESP, it worked no problem.  I actually think that it had to do with the conversion from ascii to ucs-2 that efibootmgr requires. 

If you are up for making a change, I would definitely recommend trying out the stub loader function.  Now that I have it figured out, it is pretty great.  The only thing is that I cannot change cmdline parameters on the fly.  So I installed a UEFI shell, and use that to boot if I need to pass different parameters on boot.

cfr wrote:

So I had to do what seems to work but is a right pain: boot to BIOS, load default settings, save. Reboot to BIOS and reconfigure settings. Then I need an EFI capable USB key so I can boot, chroot and use efibootmgr to recreate the menu entry for grub. I certainly hope systemd isn't going to routinely screw with it!

Well, I am glad to hear that you were able to get it working, though that does sound like a royal pain the the ass.  I think though, that if it is fixed by a reset of the cmos/bios, then it is not something that is related to the operating system itself.   I think that if your bluetooth ever ends up like that again, maybe you should slap a live cd in to see if it registers as hard blocked there as well. 

I want to say that it shoudn't have anything to do with a kernel panic, but I have heard of computers doing weird things, and anything is possible.

Offline

#41 2012-09-01 14:13:49

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

I'm glad you got that sorted. When I set this up last November, EFI stub wasn't an option. To be honest, the only reason I used EFI was that I couldn't get GPT/BIOS to work with this firmware at all. MBR was easy but I wanted the advantages of GPT. Whether I booted EFI or BIOS was not really an issue for me - as far as I was concerned, they were both completely alien and every boot loader available was similarly unfamiliar. (I had been using Open Firmware with yaboot since I had a PPC Mac.)

I rather like having grub's menu at boot. It means that when things go wrong, it doesn't matter whether I can remember command line parameters - I just have entries for all the options I think I might need. That includes the LTS kernel and an installation of finnix. (But I could do with finding a replacement for the latter as it doesn't have tools for handling GPT partitions.) Moreover, I've never managed to get an EFI shell to work so I'd hesitate to rely on that for emergencies.

This model has issues with bluetooth. I have no idea why. Even with Windows although it seems worse with Linux. There was a firmware update which helped - it is now possible to get it reenabled by reinstalling the default BIOS settings, at least. But it doesn't seem to have solved the issue properly. I thought it was on my wifi card but maybe I'm wrong because I never have the same issues with wifi.


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#42 2012-09-01 15:18:00

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

Aaahhh, a ppc user.  I have to admit, I really did like my old G4.  Granted, finding operating systems and software ported to it was not quite as widespread, but it was a nice machine for sure. 

I do understand what you are saying about the ability to *edit* the command line parameters on the fly rather than remembering and cluding the command line parameters.  Really, doing this was just a project that seemed interesting... especially since the stub loader support thing is, as you mentioned, a new feature.  The only reason using the uefi shell works for me to edit the parameters is because I struggled so much with getting the stub loaer to work and made so many bootloader entries into my nvram, those command line parameters are seared into my brain.  What I ended up using are root=, ro, initrd=, quiet, resume=, and ipv6.disable=1... though I think I may go the route of sysctl instead.  I guess since, like every mbr user, I have always had to rely on a bootloader, the idea of *not* having to rely on a traditional bootloader was intriuging.  Also, with UEFI, the specification indicates that you are no longer limited to 440 bytes of bootcode, so I figured utilizing the features of UEFI seemed interesting as well.

I just noticed that you have your specs in your sig.  For some reason I had signatures set to not be displayed.  The Intel Centrino 1000 does not have bluetooth included.  I think that the models that are combo cards end with a 5, so my new card is an Intel Centrino Advanced-N 6235.  I never actually use bluetooth, but the card was the same price as the 6230, so I figued what the hell.  I bought this card specifically because the ebay seller indicated that it could be used with my machine.  So when I got it, I put it in, all excited, and it told me that I had an unauthorized card, doh!  But about a week later I was able to find another guy looking for a modified bios, and together we foudn teh ehlp we needed.

I don't know if you are still interested in loading a shell, but what did you try when you put it on there?  It was super simple for me (although from reports, I know that various uefi firmware can be super buggy), and all I had to do was copy it to the root of my efi system partition, and then use

# efibootmgr --create --disk /dev/sda --part 1 --label "UEFI Shell" --loader '\Shellx64.efi'

That one worked first try, and was what lead me to eventually try putting the arch kernel and initramd in the root of the partition as well.  It works out good though because I just set it up so that I now mount my efi system partition to /boot and so when there are kernel updates or whatever, it installs it in the right place for me.  Although I still did have to set up a systemd.path and systemd.service so that when and update occurs it is copied from /boot/vmlinuz-linux to /boot/vmlinuz-linux.efi... though I am unsure if my particualr firmware will work w/o the .efi or not.  Maybe I shoud try and see.

Offline

#43 2012-09-01 23:30:42

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

Re.: systemd:

I just discovered that the latest updates support the rescue shell so I've gone ahead and removed initscripts, installed systemd-sysvcompat etc. I've also switched fstab to the one I prepared earlier and edited kdmrc. I'm not sure about the latter. Nothing said to do that but it seems it might be necessary and although KDE initially shutdown fine with systemd, last time it didn't quite work out. (KDM exited nicely but I just dropped to console.)

I noticed when I rebooted that I have a "[FAILED]" appearing but I'm not sure what failed as it went by too quickly and I'm not sure if this would be recorded anywhere.

My boot is definitely still quite lengthy - I don't think it has made much difference for me on that score - but I'm not especially bothered about that.

What does it mean when units are "dead"? It sounds really serious but it can't be that fatal as I seem to have reams of them.

On EFI:

I seem to remember I tried two EFI shells and couldn't boot with either. It is probably recorded in the mammoth thread you found somewhere.

What are the advantages of having the shell available? I guess it still wouldn't work when I have to reenable bluetooth by resetting BIOS since it still relies on efibootmgr entries. And which shell did you install?

Coming from OS X, I *like* boot loaders! Seems fantastic that you can design a menu tailored with all the options you want to fit your specific needs. Much easier than remembering all the different key presses required to get a Mac to boot to anything other than the standard OS X login screen.


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#44 2012-09-01 23:50:32

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

systemd:

So I too have been dropped into a shell a couple of times... strangely since I have started using the stub loader (not sure if that has anything to do with it, as I also had a system upgrade around that time as well).   I just figured it was because I have been messing with things.

If you see a failed, you can simply run "systemctl" without any flags and it will give you info on every service that is being run.  I think that you can also use the "--list-units" to acheive the same thing.  Initially I had a couple services that would fail and then just googled each to figure out how to fix them.  I think that "dead" just means that it was a service that failed.  Because it indicates "dead" when using systemctl status and "failed" when using just systemctl.  It certainly does make it sound extra bad.

I am really not sure about the kdmrc either as I do not use KDE.  I am just a simple window manager kind of a user.  But what is it about your fstab that you had to change?  The only thing I can really think would be different is possibly adding systemd mount options to some partitions.  I had my rotating hdd set up to mount upon access, but I realized that just created a delay upon login rather than just having that much more delay at boot.

EFI:

I too come from the OS X world, and I do understand what you mean about the stupid alt/option + random keys to do various things.

I think the only advantage of having the shell would be so that you can boot with your own parameters.  Although since you seem to regularly try new kernels, systems, and whatnot, it might do you good to be able to just drop into a shell and manually boot from there.  You can also create bootloader entries from there, though I have yet to figure out how to pass command line parameters to that particular method.  Overall it seems like efibootmgr is a bit more powerful, but then you have to rely on being able to boot into a uefi system as you mentioned. 

I really just kind of skimmed that mammoth thread, trying to find relevant info, but I know that your problem was far different from what I was having so I didn't end up really reading much except the solution (which I was rather caught offgaurd by... FAT16 as a solution doesn't seem logical, but hey if it works...). 

I think it would be worth trying to install the shell again now that you have a working uefi.  I simply downloaded the ShellX64.efi (2.0), put it in the root of the efi system partition and then used the bare minimum of options with efibootmgr.  (ie # efibootmgr -c -d /dev/sda -p 1 -L "Shell" -l '\Shellx64.efi' )

But you are absolutely right that since Lenovo bios's don't give you a native option to boot the shell, everytime you reset the bios, you would ahve to still boot into your usb key to recreate the boot manager entries.  But as I stated above, it may be of use to you with your adventuring to other kernels and such.  I think if you take a few minutes to learn the necessary command line parameters to use with an initramfs, it is worth the time.


Edit: I like this idea of using "systemd:" and "uefi:" as it makes things a lot more readable.  I hope you don't mind this thread delving into non systemd territory...

Last edited by WonderWoofy (2012-09-01 23:51:44)

Offline

#45 2012-09-02 01:06:28

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

systemd:

I didn't actually get dropped into the shell. I noticed that sysvinit-tools now included sulogin. That's when I removed initscripts. Then I booted into the rescue shell just to check it worked as expected.

You can see failed services etc. using:

systemctl --failed

The problem is that the failure I'm seeing is on shutdown so by the time I get a chance to use systemctl, the failure is not longer remembered.

For fstab: when I installed systemd, I created two fstabs - fstab.interim and fstab.systemd. So I removed fstab and copied fstab.systemd to fstab (rather than fstab.interim). Basically, I had been ignoring a failure on boot with initscripts to do with listing a removable drive in fstab. However, systemd waits for ages so I needed to add noauto. Initially I tried the systemd automount option in combination with noauto but that didn't work so I had to remove it. I also added noauto and the systemd automounting comment to various of my regular partitions, including /home. (Basically everything bar /, /var and /boot/efi although I'm pretty sure I could include the last if I wanted.)

I don't really experiment with different kernels or systems. Or rather, only as a precaution rather than an adventure. So I have the LTS kernel, for example. Finnix is a tiny rescue distribution for emergencies. (But, as I said before, I need something which works better for GPT.) I do have partitions for a second "proper" OS but I haven't got around to installing anything there yet although I think there might be the remains of my failed Ubuntu install there. (This is the install I did to figure out how to get EFI boot working on this machine. I realise this was a round about way of doing it but I had run out of all other leads - all I knew was, it worked for somebody who let Ubuntu autopartition. I didn't let it do that but I did let it destroy my EFI partition. Well, I didn't "let" it and it should not have but I knew that it probably would anyway and it did. Unexpectedly rendered the machine unbootable because the install failed spectacularly but it told me what I needed to know.)

I might have another go with the shell, though. I don't see much use for it right now but it might come in handy...


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#46 2012-09-02 02:00:49

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

Yeah, I have to admit that I really don't have much use for the shell either.  But like you I have space for another operating system.  I did something similarly roundabout to get my UEFI working.  I figured since I have two drive, I backed up the rotational drive with media and stuff on it, and restored my machine to its factory state (ie Windoze).  I let it create the EFI system partitions and everything.   Interestingly, even though Microsoft recommends 512MB for a FAT32 partition of any kind, the Windows installer created a 100MB ESP, which is more than enough for my needs, but its just their inability to follow their own recommendations.

I have been thinking about putting a, more of less, maintenance free, small distro in a small space for emergency.  Then I could install pacman on it.  But I haven't gotten around to it.  I will take a look into Finnix.   I was thinking something like puppy linux since I would be likely using anything I put there with exclusively root access anyway.

Regarding the fstab, I too noticed how horribly long an inproper entry can take systemd.  Or even, reportedly, a proper fstab entry that it doesn't like.  Fortunately, the noauto is an easy temproary fix while you try to find a real solution.

With the failures on shutdown, I take it you cannot see what exactly is failing since it flies by so fast.  Have you configured your syslog-ng to listen to the journal.socket yet?  Or at least created /var/log/journal and then run journalctl --setup-keys to create a persistent journal?  I think it might not give you the nice easy results systemctl gives, but I am sure it would reveal at least some clues.  Especially since the new journal defaults are so incredibly verbose.

Offline

#47 2012-09-02 02:48:34

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

syslog-ng is configured to listen on the journal socket. I configured it to use a different config with initscripts anyway. I'll see if I can find something. I haven't created a persistent journal yet as I was a bit worried about it filling my drive...!

Do you happen to know how to get systemd to honour mount options if you use:

noauto,comment=systemd.automount

or is systemd.automount not correct for this? mount is listing all of the partitions marked this way in fstab *twice* - once with the standard options I have set in fstab and once with different options from systemd. I don't know what to make of it. Which are effective?


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#48 2012-09-02 02:56:43

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

This is from man 5 systemd.mount:

/ETC/FSTAB
       Mount units may either be configured via unit files, or via /etc/fstab (see fstab(5) for details). Mounts listed in /etc/fstab will be converted into native units dynamically at
       boot and when the configuration of the system manager is reloaded. See systemd-fstab-generator(8) for details about the conversion.

       When reading /etc/fstab a few special mount options are understood by systemd which influence how dependencies are created for mount points from /etc/fstab. systemd will create a
       dependency of type Wants from either local-fs.target or remote-fs.target, depending whether the file system is local or remote. If x-systemd.automount is set, an automount unit
       will be created for the file system. See systemd.automount(5) for details. If x-systemd.device-timeout= is specified it may be used to configure how long systemd should wait for a
       device to show up before giving up on an entry from /etc/fstab. Specify a time in seconds or explicitly specifiy a unit as s, min, h, ms.

       If a mount point is configured in both /etc/fstab and a unit file, the configuration in the latter takes precedence.

So it would appear that the option should be comment=x-systemd.automount, which is what I used and seemed to work.

Last edited by WonderWoofy (2012-09-02 02:57:51)

Offline

#49 2012-09-02 03:08:08

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

Shows what I get for reading the wiki smile.

Thanks. I may try that. For now, I've just switched everything back to regular mounting which works, at least. I did read the man page but every man page seemed to refer me to another until I started getting referred back to the first and I gave up.

Did you set it as comment=x-systemd.automount in fstab? The wiki seemed to suggest you needed to pass the options through a comment option but the man page doesn't seem to mention that.

Anyway, I also seem to have edited kdmrc wrong. When I finally persuaded the reboot to take it didn't. systemctl reboot seems to poweroff my machine rather than rebooting it. Not sure why yet.


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#50 2012-09-02 03:18:03

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

I seem to remember actually passing the option through a comment.  But it was a couple weeks ago, so I can't be entirely sure about that.  I do seem to remember having an abnormally long option when I set it though, which is why I kind of remember having that. 

It is strange you are having so many problems with the shutdown of the machine.  I remember you also saying that it would continually ask you for a password upon shutdown, which it is not supposed to do.  I actually came across this problem for a minute, but was able to fix it by enabling console-kit-daemon.service, which (re-)symlinked it to graphical-taget.wants.  Even though I start my window manager through the console via xinit (startx), I still set it to graphical because that is where the console kit daemon is linked.  It is the only thing enabled through the graphical.target, so I figure it doesn't hurt anything.

Why is it you want a delayed mount anyway?  It would seem that unless you have a pure data storage area, it is going to automount it as soon as you log in anyway.  For instance, my rotational hdd was set up that way.  But I symlinked anything I thought would be getting frequent writes to it, so my .zsh_history was linked there.  As soon as I logged in to my user it would access (I think) that history, and automount the filesystem.  Which would of course take a bit less than a second to fsck.  So I figured why not tack that fsck onto the initial boot since it really is only less than a second.  It is probably being parallelized that way anyway.

Offline

Board footer

Powered by FluxBB