You are not logged in.

#51 2012-09-02 03:28:51

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

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

About the shutdown: that wasn't me being asked for a password all the time but I did post in a thread where the OP was complaining it always asked for a password, I think.

I was really just experimenting with the delayed mounts. It seems to make about 4s difference at boot which is really not worth worrying about. And I really just did it to see what would happen, I think - curiosity more than anything. I thought it might stop some file systems which I don't always use being mounted but it doesn't, in fact. And there's no particular reason to do it that way.

I would like to be able to reboot, though. And I'd like to get the kdm thing sorted though I've an idea about that so I'll see if it works next time. I've rebooted enough for today...


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

#52 2012-09-02 03:47:33

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

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

Ahh, yeah I guess I just remember seeing cfr within proximity to that descripbed problem.  It would be nice if it would reboot though.  Does it actually poweroff or does it halt?  Either way kinda sucks if the desired response is a reboot.  I wonder, did it ever reboot normally after fully transitioning to systemd?  And what about when you had a mixed system?  Makes me wonder if there is something amiss with your reboot.target, which I am not sure hwy it would not be configured correctly if it is freshly installed.

I guess the reason I too was messing with the delayed mounts was purely experimental.  But ideally, with a *nix based system, one shouldn't have to reboot all that often.  I usually reboot in order to achieve something, or I just use kexec to skip the post and bootloader, which is kind of nice.  But I guess, since my bootloader is now the kernel, it would only be skipping post.  Speaking of kexec, does it do the same thing if you do $ systemctl kexec ? I would imagine it actually does the same thing as a systemctl reboot, since it actually takes you through post and all.  But just wondering.  Maybe for another day....

Offline

#53 2012-09-02 13:56:18

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

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

I think it has rebooted normally with systemd but I'm not sure. At least once, I got a kernel panic - but it did reboot rather than poweroff.

I'm not really familiar with the difference between halt and poweroff but as I understand it, halt stops the system without turning off the computer? In that case, it powers off rather than halting - the effect is just like using shutdown with -P with sysvinit.

I seem to be rebooting (or trying to reboot) a lot lately but that's mainly because of messing around with systemd... It isn't a huge practical problem but it is nice to feel things are working correctly. There is definitely something screwy with my suspend set up but that's probably conflicts between acpid, kde and whatever else.

I've never tried kexec. For some reason, it makes me nervous.

I suspect I reboot more often than I really need to...


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

#54 2012-09-02 15:21:33

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 would have to agree that it is a nice feeling to have things set up ina working manner.  Your understanding of the difference between halt/poweroff is correct.  I was just curious because if it was simply halting, that might mean a lower level hardware issue (like preventing it from making the transition from power to no power).  So it is probably good that it least it powers off correctly.

I too have been rebooting a lot w/ systemd.  I think trying to implement the stub loader, I rebooted more in a period of two days than with the rest of the time I had my computer combined.  Fortunately, it doesn't take my computer very long to reboot  Speaking of reboot time, I read in the systemd startup times that your's is getting slower and slower.  I have to say that the clamd service looks pretty awful.  Also I am really unsure why the wicd would be taking so damn long.  When I enable wicd rather than netcfg, it loads (longer than the others) but at a pretty comparable time to the other daemons. 

I assume that your computer, being a ThinkPad, has  WWAN slot, so do you use WWAN?  If not, does your model of comptuer accept an mSATA device in that slot if not using cellular service?  I ask because I think that was the single greatest upgrade I have ever done on a laptop... ever.  My regular HDD is a Momentus XT, which is pretty amazingly fast for a primarily rotational HDD.  But experencing <1ms latency was definitely noticeable upon starting to boot from the mSATA.

About kexec, I think it is kind of funky too, but only if you execute it from within X.  It doesn't seem to like that and more or less considers it a hard reset w/o POST.  So it has to recover the journal and everything.  If I sync first, it seems to be a tad faster, but it still have to verify.  So it doens't seem like the most elegant solution.  But systemd includes a kexec option w/ systemctl which appears to be just another method of rebooting (or another command to achieve the same thing).  At least I think it is the same thing since it actually shuts down properly and then takes you through POST... so I was wondering what happens when you run systemctl kexec instead of systemctl reboot?

You mention you use powersaving scripts, namely laptop mode tools.  I wonder, if you disable those and reboot, do these problems persist?  I know it is not the ideal way to run your computer, but for the sake of diagnostics, it might be worth a try. 

I also remember you indicating that you use acpid for laptop mode tools.  It actually lists it as an "optional dep" though I think that it is optional in that if you want it to do anything differently at all between battery and ac, you need it.  But I came across this thread the other day and thought it might be of interest.  I don't know if you would be willing to retool or customize your LMT to suit this, but it is regarding a way to use udev rule to run scripts in the event of a power state change.

https://bbs.archlinux.org/viewtopic.php?id=148210

Offline

#55 2012-09-02 22:10:59

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

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

WonderWoofy wrote:

So it is probably good that it least it powers off correctly.

It is actually quite difficult to tell with this laptop but the ThinkPad LED goes off (at least, I'm pretty sure it did) so I assumed it was off.

Speaking of reboot time, I read in the systemd startup times that your's is getting slower and slower.

Yes. It seems to be slower in "pure" mode for some reason.

I have to say that the clamd service looks pretty awful.  Also I am really unsure why the wicd would be taking so damn long.  When I enable wicd rather than netcfg, it loads (longer than the others) but at a pretty comparable time to the other daemons.

Different config? Enabled in a different order? It is annoying that is slows boot since it would be fine by me if it started later. (But I don't really want to mess with starting it later by hand.)  I thought maybe netcfg would be quicker but from what you say, that seems unlikely.

I assume that your computer, being a ThinkPad, has  WWAN slot, so do you use WWAN?

Yes, it does and no, I don't.

If not, does your model of comptuer accept an mSATA device in that slot if not using cellular service?

No idea. I tried to find out but have so far failed abjectly to do so. I even tried shopping for one on Lenovo's site in the hope it would tell me which models I could use with it but they don't seem to be selling them at all. I also have an sd card slot but I understand Linux support is patchy at best and that it is, in any case, no faster and maybe slower. Obviously an SSD would improve my boot times but I won't be going that route for now, at least.

But systemd includes a kexec option w/ systemctl which appears to be just another method of rebooting (or another command to achieve the same thing).  At least I think it is the same thing since it actually shuts down properly and then takes you through POST... so I was wondering what happens when you run systemctl kexec instead of systemctl reboot?

Interesting. I wonder why it is called that if it is equivalent to reboot.

You mention you use powersaving scripts, namely laptop mode tools.  I wonder, if you disable those and reboot, do these problems persist?  I know it is not the ideal way to run your computer, but for the sake of diagnostics, it might be worth a try.

I'll give this a shot once I've got a sufficiently stable set up to make the comparison worth while. Right now, I'm still tweaking things a little.

I also remember you indicating that you use acpid for laptop mode tools.  It actually lists it as an "optional dep" though I think that it is optional in that if you want it to do anything differently at all between battery and ac, you need it.  But I came across this thread the other day and thought it might be of interest.  I don't know if you would be willing to retool or customize your LMT to suit this, but it is regarding a way to use udev rule to run scripts in the event of a power state change.

https://bbs.archlinux.org/viewtopic.php?id=148210

I'll have a look. I think the "optional dependencies" for laptop-mode-tools are optional just because you might want to use some functions but not others. So if you had none of them, I'm guessing the functionality would be pretty limited. And I change quite a lot of stuff on switch to and from battery using laptop mode tools. I doubt that would all work without acpid. (Except, maybe, if I can get something to replace it e.g. udev. I've never tangled with udev rules but I'll certainly take a look.)

Thanks again for all the suggestions!


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

#56 2012-09-02 23:37:46

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

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

Well I got KDM's graphical interface to shutdown the system properly. Admittedly, I wanted it to reboot and it didn't do that but I can't really blame KDM for that since it doesn't work at the command line either. The trick is apparently not to use quotation marks around the command line specified in kdmrc.

But I still don't know why reboot isn't rebooting and this is worrying me given my recent suspicions about my hardware. (i.e. has it just switched from stuttering to not even trying? Though I think systemd is more likely involved than not... At least, I failed to reboot with Finnix the other day but I think that's happened before and I just haven't bothered to learn the trick. Or else it is not designed to reboot which is far from impossible.)

I've still got pm-utils installed although I assume it isn't doing anything. I'm not currently sure what acpid is doing, either. I'm assuming acpid is distinct from acpi i.e. acpid is just the user interface to the functions made available by the relevant kernel modules which latch onto the acpi stuff provided by the hardware/firmware/something-ware.

More later...

EDIT:
Closed laptop lid -> computer slept.
Opened lid -> computer stuttered but this time only once. Then nothing. ThinkPad light on but otherwise entirely unresponsive. Hard shutdown.
Reboot -> Finnix -> read the man page -> reboot cleanly.
Boot back into systemd:
-> bluetooth is hard blocked again.
-> using the sleep button now causes it to sleep; wake up wakes it up and then sleeps it and finally wakes it up and locks the screen.
-> closing the lid slept the machine; opening it again woke it cleanly.

I'd be tempted to go back to initscripts but that's hardly sustainable and I suspect it is likely to be no better by the time Arch makes it default.

I'm getting rather suspicious of the bluetooth stuff - somebody else mentioned consistent crashes with the btusb module. One difference between my current boot and the previous one is that because bluetooth is hard blocked, the bluetooth kernel stuff isn't loaded and that includes btusb.

This is driving me nuts. Every time I think I've fixed one problem, it shifts or a new one develops and the, as I work on that one, lo and behold, the original one rears its ugly head again.

I've been reading the wiki on power saving again and none of it seems to address doing it with systemd.

According to the logs, pm powersaving scripts are still being attempted by something. So I've got: acpid, systemd, laptop-mode-tools, KDE and maybe pm-utils and who knows what else all trying to compete for this stuff. And right now I can't work any of it out.

</rant>

Last edited by cfr (2012-09-03 00:23:40)


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

#57 2012-09-03 00:25: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

cfr wrote:

I've still got pm-utils installed although I assume it isn't doing anything. I'm not currently sure what acpid is doing, either. I'm assuming acpid is distinct from acpi i.e. acpid is just the user interface to the functions made available by the relevant kernel modules which latch onto the acpi stuff provided by the hardware/firmware/something-ware.

Since I rather like having the pm-utils sleep.d and power.d scripts as references while I sort out all my own systemd quirks, I too have left it on my computer.  What I have done though is put one liner scripts in /usr/local/bin... I have pm-suspend calls suspend normally (with systemd-sysvcompat, it just calls systemd's suspend) and pm-hibernate which calls systemctl hibernate.  Since /usr/local/bin is fist in the PATH, those get called before the real pm-utils commands. 

I have also long suspected that acpid is actually only for user interaction with the events it tracks.  I first thought this because in the handler.sh the ac_adapter actually has examples that start and stop laptop-mode.  They are commented out, but they are there.  So it makes me think that you could possibly simply achieve the same thing with the udev rules.

SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="0", RUN+="/etc/laptop-mode/laptop-mode start"
SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="1", RUN+="/etc/laptop-mode/laptop-mode stop"

Again just a suggestion, but I always feel as though running less services is always an advantage if you can get away with it without losing functionality.

Regarding the wicd, I seem to recall you indicating that you use Eduroam and that you could not figure out how to get that configured... does this work?  It is for the University of Waterloo, o you will obviously have to change some elements... so I guess what I am asking is, do you know what your schools network uses for all these variables?

CONNECTION='wireless'
INTERFACE=wlan0
SECURITY='wpa-configsection'
ESSID='eduroam'
IP='dhcp'
DHCP_TIMEOUT=40
CONFIGSECTION='
    ssid="eduroam"
    scan_ssid="0"
    proto=RSN
    key_mgmt=WPA-EAP
    group=CCMP
    eap=PEAP
    identity="USERID@uwaterloo.ca"
    password="PASSWORD"
    ca_cert="/usr/share/ca-certificates/mozilla/GlobalSign_Root_CA.crt"
    phase2="auth=MSCHAPV2"

I have to say that I much of a fan as I was of wicd (still am), for its sheer simplicity, netcfg is simply amazing.  Its only disadvantage is that you don't have a supported GUI little icon thing.  But there is the netcfggui which I think is in qt, which would certainly suit a KDE user like yourself.  The simplicity of the script is really just incredible and it really is just a shell script, so you can take a look at what the hell it is doing if it is giving you problems.

About the reboot thing... how long have you had your computer?  Did you get the extended warranty with it?  I think that resolving the hardware related issues should be something you should really do your best to try and resolve before that runs out.  You say that you think the no reboot prolem also occurs from Finnix?  I wonder what would ahppen if you were to try from the Arch installer running initscripts?  Maybe then you might be able to determine if it is a hw or sw problem as well as an initscripts or systemd problem all at the same time.

Anyway, just a few thoughts... maybe some of the mass crap I continue to throw your way will lead you in a solution bound direction.

Offline

#58 2012-09-03 00:48:14

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

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

No. I was wrong. I can reboot fine from Finnix.

I didn't purchase the extended warranty - not yet, anyhow - but it is still within the standard year's cover. However, I can't reproduce the issue for Lenovo and they just offer to restore it to factory settings (i.e. Windows). Also, I'm beginning to suspect software again. The stuff with bluetooth strikes me as rather suspicious.

My university used to provide instructions for NetworkManager but now they just say to use generic information to configure Linux. (http://www.cardiff.ac.uk/insrv/it/netwo … ml#Generic) I'm not quite sure how they map on to what you've got. The wicd encryption template is of some use but I'm not sure how some of the entries are related to those in your config above. Is that a profile for netcfg?


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

#59 2012-09-03 01:23:05

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 found the config from a student at the University of Waterloo site for his fellow Arch linux users who wanted to use netcfg w/ Eduroam.  Looking over your school's generic settings and the setting found in that config I am not sure of a few things either.  Though I am pretty unfamiliar with more advanced networking security (like Eduroam) as I have never had to use it before.  But looking at netcfg's wireless-wpa-configsection example I was still a bit confused but a tad less, though maybe things might make more sense for you... though I am unsure if it would be worth the trouble to figure it out.

% cat wireless-wpa-configsection
CONNECTION='wireless'
INTERFACE=wlan0
SECURITY='wpa-configsection'
# Uncomment this if your ssid is hidden
#HIDDEN=yes
IP='dhcp'
CONFIGSECTION='
    ssid="University"
    key_mgmt=WPA-EAP
    eap=TTLS
    group=TKIP
    pairwise=TKIP CCMP
    anonymous_identity="anonymous"
    identity="myusername"
    password="mypassword"
    priority=1
    phase2="auth=PAP"'

Regarding the warranty, I have to admit that even though Lenovo doesn't seem to know sh*t about Linux, at least they are willing to support Linux machines still.  I have heard some horror stories of other companies refusing to even look at a machine w/o Windows on it.  Seems pretty terrible that we live in a world where you are forced to support a company upon purchase of a machine, and then if you want the warranty that is gauranteed upon purchase, we are forced to actually *use* said company's software to recieve support.  That is precisely why I have taken a liking to referring to then as the Microsoft Cartel... they just bully people into submission.

I think that the bluetooth thing is definitely suspicious... it might be worth a bit of in depth googling to see if other users of your machine experience the same problems.  Because if so, then at least you know that it is a common bios issue that an update can fix, rather than a problem specific to your bios.

Offline

#60 2012-09-03 01:33:48

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

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

Thanks. That makes a little more sense. I think maybe wicd and netcfg put things in different places. And the anonymous bit sounds right - that's why my university has a special script to get it to work on Tiger (OS X 10.4.* but you probably know that) because Tiger doesn't have an easy way to configure advanced security for eduroam. (IT didn't know why the central people bothered with a script until I came back with the instructions they'd given me complaining that there was no way to map the OS X instructions they'd given me onto the interface I'd got in Tiger.)

I think I'm going to ignore netcfg for now. wicd has the enormous advantage of being one of the very few things which is "just working" right now. Right now, that's worth a log more than a few extra booting seconds - if it wanted 5 minutes, I'd be inclined to just make a cup of tea. (Right now, lots of cups of tea smile.)

I'm actually suspicious about the bluetooth stuff in Linux's kernel, too. I don't really trust the bluetooth stack in Linux - I've seen it cause some very nasty issues.

I think my priority right now is to try to rationalise my powersaving strategies and, especially, to figure out what on earth is going on with suspend (lid/button), reboot, shutdown, poweroff...


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

#61 2012-09-03 01:45:41

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

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

Yes, I have to admit that is probably the most important area of your problems at the moment.  I remember briefly discussing your lid/button issue, but I don't recall you ever indicating that you tried anything to resolve it.  Have you tried putting "HandleLidSwitch=always" in /etc/logind.conf?  I looked at your previous post and you indicated that you were able to sleep on lid close when using the acpid handler.sh... if you have acpid running anyways, why not just use that and stick with it?  Is there some reason that is sub-optimal?

Offline

#62 2012-09-03 22:13:13

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

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

Regarding the lid, part of the issue was that initially it had no effect under systemd. So I enabled it under acpid rather than counting on KDE and that seemed to work. Later, though, I started getting two suspends. The advice in the systemd wiki says not to use systemd if you are using gnome etc. I assume this applies to KDE. I've disabled the switch in acpid again and now I think KDE is handling it.

The remaining problem is that it sometimes stutters on resume from suspend if the lid is involved, at least. I can't reproduce this reliably - I don't think it is a straightforward case of using one thing or another to suspend. I suspect it is more complicated.

What I can't find out is how, exactly, KDE suspends, hibernates etc. I know how it tries to reboot and shutdown but I can't find info on how it sleeps or hibernates. (I haven't tried the latter with systemd - it is really much less of a priority for me.)

However, I then found I was getting two suspends with the sleep button. Under initscripts, acpid handled this and it worked fine. I've now disabled this function in acpid and now I just get one suspend. This is great but I really wish I knew what was causing it to sleep now because as far as I can tell, nothing should be doing so. In logind.conf, I've set:

#HandlePowerKey=no-session
#HandleSleepKey=tty-session
#HandleLidSwitch=off
HandleLidSwitch=tty-session

I figured there was no reason to leave the lid switch at "off" though I'm not sure if this is correct or not. The idea is that, following the wiki, KDM/KDE (somehow) handles the lid  when running. Not following anything at all, some unknown something handles the sleep button at least in a desktop session - I haven't actually tried in tty-session. I don't know yet how stable this is.

Bluetooth is, however, driving me slowly nuts. It *should* be possible to unblock it, I think, but the radio function key on my laptop doesn't seem to work. (That is, under Linux. I assume there's nothing actually wrong with it.)

On the other hand, I suspect the bluetooth Linux stuff of causing havoc with power and systemd and although I can't prove this and don't have any real evidence, maybe systemd is not currently compatible with bluetooth with some hardware/configurations.

I want to understand more about what's going on with suspend etc. and why I can't reboot with systemd. I can reboot fine from Finnix with initscripts so I'm pretty sure this issue, at least, isn't hardware. (I'm beginning to suspect that it is ALL software, in fact. Or maybe BIOS + software. But I'm not, of course, at all certain...)


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

#63 2012-09-04 02:59:57

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 have to say that you are probably right on the all software assumption from the sound of things ... with the exception of possibly the bluetooth.  But even that I think could certainly be sofware related.  Does Finnix provide modules and software for bluetooth, and have you tried those out?  It does make sense that the radio key shouldn't work for a soft block.  In fact, with my system, it actually makes the device disappear altogether when I use that key to block my wifi.  I don't have a bluetooth switch, so wifi is the closest thing I have. 

So how is it that KDE controls shutdown and reboot?  Does it then control the power button as well?  If so it seems very odd that it's settings would be separate from the sleep button. 

With all these problems you are having, I am kind of wondering if you should maybe try a fresh install on a usb key or a sdcard, install systemd and see what issues it has under absolute newness.  I find that the install process is pretty simple now with the chroot and con totally be done from your existing system.  So it is kind of nice that I can say "I want to install another Arch to this partition..." and not even have to reboot.  It reminds me a lot of the Gentoo/Funtoo install where you simply download a tarball and expand it in the root of your desired parition.  Only you are instead using pacman to download a package at a time and expand it into a filesystem.  I like the transparency of the install method rather than clicking a button and gettting near zero info until it tells you it is done.

I assume you are a student at university if you connect to Eduroam, do you start school soon or already started?  If so I hope you can figure some of these things out before school gets into full swing.

Offline

#64 2012-09-04 22:34:05

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

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

Some of the function keys on my laptop don't work - at least under linux. (No idea about windows.)

Finnix is a pretty minimal rescue system. I haven't checked but I rather doubt it includes bluetooth. (Though maybe it would for keyboards... hmm... Will have to check.)

KDM controls shutdown and reboot via commands set in the config file, /usr/share/config/kdm/kdmrc. I switched these to systemctl commands. KDE has a GUI for setting various power-related options so e.g. you can tell it to do something when the lid is closed or the power button pressed. There are no visible options for specifying the command and I'm not sure where these are configured. I assume it picks up shutdown/reboot from KDM but I'm not sure what it uses for sleep. There's also no obvious reason it should do anything with the sleep button but if it is not KDE, I don't know what it is. I also don't know why KDE should suddenly handle the sleep button now that systemd is installed when I needed acpid for that before.

Do you literally just give pacman a different root for the USB key? Or did you use the pacstrap magic from the latest isos?

I'm not really a student. I sort of teach. I know some of what I'm doing this year - a little - but the rest is rather hazy. Very much wish they would make up their minds whether they want to employ me or not... The class I know I'm teaching starts 1st October provided I get enough students... (They have just put the fees up yet again so I'm not sure this is very likely.)


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

#65 2012-09-05 01:11:41

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

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

Hmm... I thought maybe the idea of making a fresh install wasn't bad. I don't have an SD card so I used a USB key. I've now realised I have no idea how to make the thing boot. I don't think, somehow, that I should have tried to make it quite so similar to my regular install. I can't figure out how to make a USB key which will boot in EFI mode but isn't made from the live .iso image... Maybe this isn't meant to be possible but I have a suspicion that I've actually done something like this before and forgotten how. (Forgotten how for me means forgotten where I found the instructions.)


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

#66 2012-09-05 03:16:42

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 think all you would have to do to make an efi booting usb key would be to first of all, add the usb hook to mkinitcpio so that the necessary usb modules are baked into the initramfs.  Since you use grub, I would think that you simply need to create a new entry in the grub.cfg (whether manually, or by using os-prober), and then boot from the same drive as you usually do, just pointing it in the right direction.  So I would think that if you are making this key as similar to your regular install as you can, I think that you simply have to change root= in the bootloader command line parameters.  But I have never actually made an efi based usb key.  Since you can set up both bios and efi w/o them conflicting with each other, amybe you should just start with bios and see if things work under that.  I think (speculate rather) that if using grub an efi, it works just like bios where it is loaded (abliet from the efi sys part rather than the first 440bytes) and then references the grub.cfg.  So I have to imaging that setting grub up to boot multiple os's couldn't be horribly different.  Think about how many lost noobs you'd have if they did that. 

cfr wrote:

Do you literally just give pacman a different root for the USB key? Or did you use the pacstrap magic from the latest isos?

Yeah, it is simple really, I think pacstrap is just a wrapper around pacman that sets up the necessary directories in /var if required, and then installs while specifying the root (which the user specifies) and the cache directory.  Assuming that you mounted your system on /mnt/root, all you have to do is this:

# pacman -S <package> -r /mnt/arch --cachedir /mnt/var/cache/pacman/pkg 

I would think that Finnix would need to have to have bluetooth simply for the keyboard/mouse setups that are so common today, just as you speculated.  You have to figure that it needs to support as many hw configs as possible and, for instance, Arch's kernle package is only 60MB installed which seems to support anything I can throw at it.

Offline

#67 2012-09-05 22:25:37

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

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

Thanks. I was actually trying to make the USB key independently bootable but I'm not sure how possible that is.

I installed pacstrap and friends and used them to do the install. I figured I might as well practise a little with them. pacstrap is just a wrapper for pacman but it is rather convenient since it creates necessary directories, copies any available mirrorlist and pacman key etc. It does some other things whose purpose I'm not quite clear about but the basic set up is as you say.

I can't set up both bios and efi to boot this machine, I don't think. Unless it is actually on the key - that works. Because I never could get gpt + bios to work on this laptop. (mbr + bios works or gpt + efi.)


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

#68 2012-09-06 00:17:52

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

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

Ah yes, I do recall now skimming over stuff about your gpt/bios issues in your super uefi thread.  That is rather interesting... I didn't read that whole thread in its entirety, but out of curiosity, were you trying only grub, or did you try other bootloaders as well?  In any case, I think that if you set up the usb key to be mbr+uefi, I think it will still serve the same purpose of testing your hardware.  I think that if it proves functional, then at least you know that you are not dealing with a hw issue.  I guess that would still leave you questioning whether it is an uefi issue, but I think that would only apply to the bluetooth.  From what you have told me, I think that the issues with systemd should be able to be tested independent of the booting method. 

cfr wrote:

I installed pacstrap and friends and used them to do the install.

Interestingly, I never even thought to try and find the package with those tools.  I just used pkgfile and realised that they are in arch-install-scripts.  At one point I had simply searched w/ pacman for pacstrap, came up empty and moved on.  I guess those would be a handy tool to have.  I have been trying to find an suitable distro to put beside my arch install, so I installed Funtoo.  After compiling the kernel, I realised again why I had moved away from it in the first place. I do really like the USE variable, but I think that I can really achieve the same thing with ABS and some planning.  Also, I have read time and again that with x86_64, machine optimized software does not provide the same advantage as it used to.  Besides, with a i5 2.5ghz w/ 3.1ghz "turbo power" or whatever you call it, my system is pretty speedy.  The only thing I can think that I would really like about Funtoo/Gentoo is having an up to date pacman in Portage.  But then, really i can install pacman on whatever distro manually.  I ahve to do a bit more searching, but I keep thinking I am going to fail and simply install another arch next to my arch (probably with a different setup like maybe a full DE).

cfr wrote:

I was actually trying to make the USB key independently bootable but I'm not sure how possible that is.

About that part, I think that is where the uefi shell would really come in handy.  Assuming that your existing efi system partition would show up as the first, it would be labeled FS0:, and then the efi system partition on your usb key would be FS1: and from there it is kind of like a dos shell.  So you navigate to the directory housing the *.efi and launch it appended by any kernel command like params you would like.  Otherwise I think it would be as simple as putting an efibootmgr entry in specifying the disk and part as your usb drive.  I know that there are reports everywhere that udev likes to randomly assign identifiers to your hardware (like my first drive as sda and second as sdb), but i have actually never seen my machine do this.  Still I use UUID's, but presumably it couild throw a wrench in creating an efibootgmr entry if your disk is /dev/sdb or whatever.

Offline

#69 2012-09-07 01:02:41

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

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

Update: I'm now unable to reproduce the non-rebooting issue. At least, I just rebooted OK. Then tested the latest version of finnix which also has bluetooth disabled. (I assume hard blocked but rfkill isn't included so I don't know for sure.)

Reset BIOS, rendered machine unbootable. Reconfigured BIOS, rebooted with Arch media, rendered machine bootable...

When bluetooth is available, I get this from lsusb:

Bus 001 Device 003: ID <id> Broadcom Corp. Bluetooth Controller

Is the ID really sensitive? Or is it generic? Why doesn't it surprise me that something from Broadcom would cause trouble? (I was pretty sure it was Broadcom but wasn't sure how to check before.)

I guess it is generic and I could have left it, judging by the output from lsusb (I assume the serial is the sensitive bit) but just in case:

Bus 001 Device 003: ID 0a5c:217f Broadcom Corp. Bluetooth Controller
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          224 Wireless
  bDeviceSubClass         1 Radio Frequency
  bDeviceProtocol         1 Bluetooth
  bMaxPacketSize0        64
  idVendor           <id> Broadcom Corp.
  idProduct          <id> Bluetooth Controller
  bcdDevice            7.48
  iManufacturer           1 Broadcom Corp
  iProduct                2 Broadcom Bluetooth Device
  iSerial                 3 <serial number>
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          216
    bNumInterfaces          4
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       224 Wireless
      bInterfaceSubClass      1 Radio Frequency
      bInterfaceProtocol      1 Bluetooth
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       224 Wireless
      bInterfaceSubClass      1 Radio Frequency
      bInterfaceProtocol      1 Bluetooth
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0000  1x 0 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0000  1x 0 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       1
      bNumEndpoints           2
      bInterfaceClass       224 Wireless
      bInterfaceSubClass      1 Radio Frequency
      bInterfaceProtocol      1 Bluetooth
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0009  1x 9 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0009  1x 9 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       2
      bNumEndpoints           2
      bInterfaceClass       224 Wireless
      bInterfaceSubClass      1 Radio Frequency
      bInterfaceProtocol      1 Bluetooth
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0011  1x 17 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0011  1x 17 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       3
      bNumEndpoints           2
      bInterfaceClass       224 Wireless
      bInterfaceSubClass      1 Radio Frequency
      bInterfaceProtocol      1 Bluetooth
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       4
      bNumEndpoints           2
      bInterfaceClass       224 Wireless
      bInterfaceSubClass      1 Radio Frequency
      bInterfaceProtocol      1 Bluetooth
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       5
      bNumEndpoints           2
      bInterfaceClass       224 Wireless
      bInterfaceSubClass      1 Radio Frequency
      bInterfaceProtocol      1 Bluetooth
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        3
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       254 Application Specific Interface
      bInterfaceSubClass      1 Device Firmware Update
      bInterfaceProtocol      1 
      iInterface              0 
      Device Firmware Upgrade Interface Descriptor:
        bLength                             7
        bDescriptorType                    33
        bmAttributes                        7
          Will Not Detach
          Manifestation Tolerant
          Upload Supported
          Download Supported
        wDetachTimeout                   5000 milliseconds
        wTransferSize                      64 bytes
Device Status:     0x0001
  Self Powered

I'm wondering if reenabling it will mean I start to see issues again... The bluetooth seems really buggy in linux or this machine or both... (I had trouble with bluetooth under linux on my last laptop - kernel panics on boot.)

WonderWoofy wrote:

Ah yes, I do recall now skimming over stuff about your gpt/bios issues in your super uefi thread.  That is rather interesting... I didn't read that whole thread in its entirety, but out of curiosity, were you trying only grub, or did you try other bootloaders as well?

Just grub.

In any case, I think that if you set up the usb key to be mbr+uefi, I think it will still serve the same purpose of testing your hardware.  I think that if it proves functional, then at least you know that you are not dealing with a hw issue.  I guess that would still leave you questioning whether it is an uefi issue, but I think that would only apply to the bluetooth.  From what you have told me, I think that the issues with systemd should be able to be tested independent of the booting method.

Maybe I'll have another go. I probably need to redo the install to do this, though...

Interestingly, I never even thought to try and find the package with those tools.  I just used pkgfile and realised that they are in arch-install-scripts.  At one point I had simply searched w/ pacman for pacstrap, came up empty and moved on.  I guess those would be a handy tool to have.

They seem useful. Saved remembering and typing the string of commands for chrooting which I usually need to reenable booting after reenabling bluetooth on the machine, for example!

Besides, with a i5 2.5ghz w/ 3.1ghz "turbo power" or whatever you call it, my system is pretty speedy.

Lucky you. IT just gave my i3 work machine to my new office mate and have found me a core duo somebody else is chucking out. Hardly ever used the i3 mind and they will let me put linux on the older one so it will be infinitely more useful. They also gave my monitor to the same person, gave me another discard, then came back and gave me a different discard which is identical to my previous monitor. Still, I suppose I'm lucky to have a computer at all... (And I'm definitely lucky to have been told I can put linux on the thing. Normally they are a standard Windows XP image - sometimes with admin rights, often not.)

The only thing I can think that I would really like about Funtoo/Gentoo is having an up to date pacman in Portage.  But then, really i can install pacman on whatever distro manually.  I ahve to do a bit more searching, but I keep thinking I am going to fail and simply install another arch next to my arch (probably with a different setup like maybe a full DE).

Would be interested to know what you find. I have been meaning to put a second OS on this machine. I've been wondering, too, about doing the opposite i.e. arch + a minimal set up! What's the advantage of having pacman installed on another distro, though?

About that part, I think that is where the uefi shell would really come in handy.

I've thought for some time this would be handy but how do you launch it? According to the wiki my firmware is supposed to include a shell already which I assume means I shouldn't need to install anything. And it suggests launching it with, I think. F1/F6 or F11 but F1 is BIOS setup, F6 makes no difference and I'm pretty sure I've tried F11 with the same results.


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

#70 2012-09-08 03:25:38

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 have to admit, that I am thoroughly unsuprised by the fact that your troubled peice of hardware turned out to be broadcom.  I had to get my broadcom wifi card working on an old macbook, and it was probably one of the worserest things I have ever had to do.  That is intended to be somehow a third level of worst... It was some time ago, and from what I have read, things have improved, but I still loathe anything broadcom.  Unfortunately, I have not had any real experience with broadcom bluetooth, nor bluetooth in general really.  I am able to get mine working, but I rarely use it if ever (I havne't connected my computer's bt to anything except to test it), but ran into no problems so I really don't even know where to tell you to look next.  It is interesting that it was also blocked in FInnix though and that a reset of the bios actually rendered it fixed (though i guess you aready knew this was so.

I certinaly hope that your computer continues to reboot in a normal fashion.  Is this also a result of your bios reset, or did you experience this before you proceeded with that?  I have to say that when reading your last post I was a bit stunned for a second when you said that it rendered your comptuer unbootable, until I read the next sentence and realized that you were referring to the steps that were fully expected after a bios reset.

Now that you ahve sorted out (hopefully) the real issues of your system, namely the reboot, I don't know that there is a real reason to go about getting an install on a usb or flash card working.  If everything works as it should now, I don't know that you can actually use a test like that as a comparison. 

Regarding the work computer, I am very suprised that they are allowing you to install Linux on your system.  In my mind, if an employee is more comfortable (and proficient) with a given operating system, supported or not, it makes sense to let them use it.  But alas, most companies are not willing to potentially relinquish such control to their employees, and I think that some even feel threatened by someone who uses Linux, fearing that they will then be hacked!  It makes me laugh and cry at the same time. 

I assume though that you still have your Thinkpad, and teh Core Duo is simply a work only machine.  I would certainly hope they would not take away an awesome laptop and give you a mediocre desktop to replace it.  I would take that core duo in a heartbeat though if it meant that I could install Linux over windows though.  You are going to have to go i686 then?  From my Mac days I recall the core duo being 32 bit and it wasn't until the core2 duo that the processors were 64 bit. 

About the second distro thing, I am still looking.  I like the whole idea behind Gentoo/Funtoo, but I really would like a binary option.  I don't mind installing some things from source, but there are a few things that I would hate having to recompile on every update.  For instance one of the bloated web browsers liek firefox or chromium... god forbid I have both installed.  I guess right now I am using dwb which compiles in no time since it is so tiny.  But I find that it doesn't do some things correctly, so have to have a backup "common" browser just in case.  I also like how vanilla Slackware is, but again the source based thing gets me and the lack of dependency management I could do, but I don't particularly like it.  I actually think that FreeBSD would fit my needs since their ports system is source based, but also includes some binary packages in repositories.  But upon reseraching, I found that my new wireless card does not work with freebsd (yet?).  It is an Intel card, so presumably it should be fixed soon.

The reason I would like pacman installed on any secondary system I have is so that I can easily do maintenance on my main Arch install from my secondary install.  If I end up using Gentoo, I would also probably put portage/emerge on my Arch install as well.  I was thinking about putting a small emergency distro on my system, like your Finnix, but if I could simply have to full distros with their respective package managers on each other, it would make things very easy indeed.  Gentoo's portage actually has pacman in its repositories, and I just checked and we have gentoo's portage in AUR. 

I was actually thinking that if I end up doing dual Arch, I might give kde a try.  I tried it once before when the lastest (4.x?) was pretty new, and I really did not enjoy it.  But I have heard good things about the progress of kde since then.  I will admit though that at that time I was a gnome user and gnome3 was pretty horrible as well.  I think at least with kde I was able to change the ui a bit to make things a bit better.  I guess that is ultimately why I ended up just using a simple wm though.

So my machine ships with the pheonix bios as well.  I was unable to find any reference to an included shell on this system though.  I googled like mad and searched through the bios itself, but found nothing.  So that is why I installed the shell myself.  I launch it the same way I would launch Arch if it weren't the first in my boot order.  I hit f12 to get to the boot menu and there I created an entry with efibootmgr for it.  So when you reset your bios, you would ahve the same issue of having to recreate the entries, but for times when you want to launch straight from the efi system partition (like with a usb stick), it makes it super easy.  I think that if there were an included shell, you would see an option to get to it included in that boot menu by default.  And so far I have not found that option listed under any circumstances.  My initial assumption was that when I installed Linux and formatted the drive, I also did away with the included shell.  But I got recovery discs and restored the system to its original state because I was bored one day, and I still didn't find it.  That is actually part of the reason I have a bunch of space to dedicate to a secondary distro.

Wow, that was a lot longer than anticipated....

Offline

#71 2012-09-09 00:50:14

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

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

Fortunately, they can't take my laptop away because I own it personally. I agree about Linux + older hardware being preferable - for me, it is just much more _useful_. I, too, am extremely surprised they are letting me install anything on it - never mind Linux.

There are some odd things, though. Officially, Windows is supported, Macs are kind of a little bit supported for certain things e.g. network access but, well, not beyond that. (And certainly nobody in my school can opt to have a Mac unless it is their personal property.) Linux is "best effort" and recently network access support consists of "you're welcome to configure it to access the network using the generic information provided" (whereas they used to provide instructions for Ubuntu, at least).

On the other hand, if you have a laptop (at least your own), officially, you aren't entitled to use the wired network. But if it does not run Windows, I've found you can persuade somebody to approve it - they think you are much less likely to infect the network if you are running OS X or Linux. This is actually quite handy. But letting me install Linux on their machine - yes, that's a further step and quite surprising.

I've been told it supports 64 bit so maybe it is really core2 duo or something. I don't really know much about intel chips in between the i486 and the i3 as everything I had in between was PPC! Gentoo etc. are out. I need something which I can maintain relatively easily and quickly for this machine. I don't want to have to think about it too much else I'll never actually get any work done!

I don't know about Chromium but I don't use Arch's build of Firefox - I get it straight from Mozilla. The binaries work fine (almost always). I keep Arch's as a backup and would go back to it if it ever works properly but until then I use Mozilla's. Slightly more faff but it only needs to be unzipped in an appropriate place under /usr/local. (I got 15.0.1 in place before my Arch version was updated this time.)

Shame about the shell - I was hoping it might let me reboot without a key if I forget and wipe the BIOS entries without thinking. I've already done this once to fix bluetooth. Luckily, I had a key to hand but that was just luck.

I was going by this comment from the wiki

Systems with Phoenix SecureCore Tiano UEFI firmware are known to have embedded UEFI Shell which can be launched using either F6, F11 or F12 key.

All I can say is that if this is really true, they've certainly hidden it extremely well smile.

Last edited by cfr (2012-09-09 00:53:07)


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

#72 2012-09-09 05:44:33

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:

I was going by this comment from the wiki

Systems with Phoenix SecureCore Tiano UEFI firmware are known to have embedded UEFI Shell which can be launched using either F6, F11 or F12 key.

All I can say is that if this is really true, they've certainly hidden it extremely well smile.

I too came across this quote and tried repeatedly to get to this fabled shell.  I even went so far as to check and recheck to make sure I truly had a Pheonix SecureCore Tiano UEFI setup.  I knew it was UEFI and I knew it was Pheonix, but I brought up the informational boot screen several times to make sure I had read it correctly.

It is nice to hear that the system admins at your work understand that their support of ms only puts the at the greatest security risk.  It is even nicer to hear that because of this they think it no problem to let you access the network with any *nix based system.  When I was looking through the systemd boot times I noticed you were running clamd and it was super slow to boot.  But now I understand why you find it necessary to do this, as you run the risk of infecting the school's network if you don't.  I keep clamav installed to disinfect my family's machines, but I only run/refresh it in times of need.

So you have any idea what you want to put on your work system?  It sounds like (at the moment at least) it might be better for your overall productivity if you go with one of those simple, do everything for you, kind of distros.  I think Arch would have done well a few months back, but with all the recent changes, it just seems like it might take too much maintenance during this time of transformation.  Don't get me wrong, I wil never leave Arch, but I also do not use this machine for much more than tinkering, word processing, internet, etc.  You are right though that Gentoo/Funtoo would simply be too much to bear for a work computer I think.  Just the compiling alone during upgrades would be pretty terrible to deal with.

I have been doing some reading about opensuse though.  Apparently they have a new(ish?) repository called tumbleweed, and it basically turns an existing opensuse install into a rolling release.  From what I have read, their users willing to try it have had very good experiences with it.  I really cannot see myself going back to another 6-month release cycle, as I feel I have just been way too spoiled by Arch's rolling release.  So I was thinking about checking that out... maybe a project for a Sunday afternoon.  I will let you know how it goes if I get around to it.

As for the chromium thing, I actually don't use chromium or firefox.  I may have mentioned in the above post, but I am a dwb user.  For a bit I was trying to find as many programs with vim keybindings as possible and ended up with that.  I do keep a couple other browsers on my machine for emergencies or when other people need to look something up quickly.  I tried only having dwb and luakit on my computer, but when a friend wanted to check their email, I basically had to do it for them because they couldn't figure out how to do anything.

Offline

#73 2012-09-09 16:30:02

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

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

I've been wondering about Fedora with a KDE spin. Partly because I know it will have reasonably familiar systemd stuff (well reasonably familiar unfamiliar systemd stuff, really) and it's something I see mentioned on these forums which suggests people using Arch also use it. (But that's very impressionistic.) I might take a look at OpenSuse, though. I think IT use that to image the computers at work i.e. they use opensuse to install an XP image. I know this because if it goes wrong, I find computers left on all weekend stuck at error screens. If I get out of the screen, I'm dumped at an oddly familiar command line. (I was trying to shut them down and thought I'd have to tangle with dos but it turned out to be surprisingly straightforward!)

I don't actually have clamd scanning my computer. I just scan pretty much all downloads. Firefox can do this automatically which is handy. (Anything not got via pacman/aurget/makepkg/texlive etc.) Having antivirus installed and active is a requirement for being allowed access to the university network though I don't think it is really enforced for non-Windows. I've only ever found false positives though in the past I used to get a lot of viruses via email but they never got as far as being scanned as they never actually got downloaded onto my machine.

I'm not familiar with dwb at all. I mostly use Firefox which is moderately well supported on campus and is available in Welsh.

Weirdly, one of the things I miss most on Linux (apart from decent PDF support which is frankly abysmal) is alpine. Although I could use this, I can't figure out a way to make it use a centralised password system. Then again, centralised password system doesn't seem to be in play anyway. (I don't want to tie myself to KWallet or whatever it is called since I guess that's KDE specific.) I miss the Keychain Access app. from OS X. Alpine actually integrated with it beautifully. I don't really like graphical email programmes.

Last edited by cfr (2012-09-09 16:31:38)


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

Board footer

Powered by FluxBB