Re: Q: 'df' reports partition is full but 'du' shows not full partition -- how to find where the problem
On 04/07/2015 05:47 PM, Snow Leopard wrote: Hello, what would be a best approach for the following situation: You have a web server and monitoring system reports that you short on disk space. You login into web server computer and command 'df' indeed shows that some partition is almost full. How would you resolve the issue if 'du' does not confirm that disk is full. You 'du' all directories in the root of the partition but sum does not adds up to match 'Use%' reported by 'df'. For such situation I would assume that some process holds huge open file which was deleted (for example your web server was compromised). Question: how would you find the process which holds 'deleted' file? Greetings, I normally start looking for those deleted files by doing this: $ lsof | grep -i deleted Pass the partition into lsof to narrow the scope. Hope that helps! ~Stack~ signature.asc Description: OpenPGP digital signature
Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
On 04/01/2015 11:45 PM, David Wright wrote: Quoting ~Stack~ (i.am.st...@gmail.com): On 04/01/2015 03:27 PM, David Wright wrote: I don't recall seeing you post what you actually put into /etc/crypttab to test PARTUUID, only the erroneous earlier versions where you were still using swap's UUID. Fair enough. Completely plausible I did something wrong as I haven't used PARTUUID's in my /etc/crypttab before. # blkid | grep sda3 /dev/sda3: PARTUUID=0003efe2-03 # grep swap /etc/crypttab # swap works. #sda3_crypt /dev/disk/by-id/ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3 /dev/urandom cipher=aes-xts-plain64,size=256,swap # swap doesn't work. sda3_crypt PARTUUID=0003efe2-03 /dev/urandom cipher=aes-xts-plain64,size=256,swap How about trying sda3_crypt /dev/disk/by-partuuid/0003efe2-03 /dev/urandom cipher=aes-xts-plain64,size=256,swap Same thing. Systemd.fsck runs on boot and takes ~2 minutes before timing out. Swap is not mounted. :-/ Thanks for the suggestion! signature.asc Description: OpenPGP digital signature
Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
On 04/01/2015 03:27 PM, David Wright wrote: I don't recall seeing you post what you actually put into /etc/crypttab to test PARTUUID, only the erroneous earlier versions where you were still using swap's UUID. Fair enough. Completely plausible I did something wrong as I haven't used PARTUUID's in my /etc/crypttab before. # blkid | grep sda3 /dev/sda3: PARTUUID=0003efe2-03 # grep swap /etc/crypttab # swap works. #sda3_crypt /dev/disk/by-id/ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3 /dev/urandom cipher=aes-xts-plain64,size=256,swap # swap doesn't work. sda3_crypt PARTUUID=0003efe2-03 /dev/urandom cipher=aes-xts-plain64,size=256,swap signature.asc Description: OpenPGP digital signature
Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
On 03/29/2015 07:06 AM, Sven Hartge wrote: ~Stack~ i.am.st...@gmail.com wrote: One more question if you don't mind: I understand why the encrypted partition UUID is going to change every time, but the physical partition UUID for my /dev/sda3 shouldn't change though. If they are the same systemd.fsck shouldn't have a problem with the physical partition UUID of /dev/sda3, but yet it does (at least for me). So what is the difference between the UUID pointing to /dev/sda3 and the /dev/disk/by-id pointing to /dev/sda3? Please provide an example of such an UUID and the way you obtained it. Greetings Sven, So something odd has happened... # blkid |grep sda3 /dev/sda3: PARTUUID=0003efe2-03 /dev/mapper/sda3_crypt: UUID=f4aad427-3462-4dcf-a40d-617e90a7b1cb TYPE=swap # grep sda3 /etc/crypttab sda3_crypt /dev/disk/by-id/ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3 /dev/urandom cipher=aes-xts-plain64,size=256,swap That PARTUUID is odd because it used to be a UUID...huh...really not sure what happened...but I have a guess (below)... But on my not-yet-updated-to-an-OS-with-systemd boxes they are either configured for keys or use the UUID from blkid and that UUID is what is in /etc/crypttab. In my first email this UUID=ef2496cd-ca4d-43aa-8c90-dba084029f6e was taken from blkid. Clearly that is no longer the case and would explain why UUID doesn't work. :-) So off I went to read about UUID vs PARTUUID. Short notes: UUID == filesystem PARTUUID == partition Thus, I would want to point to the partition PARTUUID because (as you pointed out to me earlier) the swap filesystem is going to change every time due to urandom and thus the UUID should be changing on every boot...blkid is probably seeing that this is a ever changing swap partition and just returning the PARTUUID for me. But putting that PARTUUID in my /etc/crypttab didn't work and I ended up with the systemd.fsck timing out and not mounting swap. Hrm. Well, I guess the disk-by-id works so I will just use that for now. Thanks again! I have learned a ton about cryptab, swap, UUID/PARTUUID, and the boot process. :-) ~Stack~ signature.asc Description: OpenPGP digital signature
Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
On 03/28/2015 02:15 PM, David Wright wrote: Quoting ~Stack~ (i.am.st...@gmail.com): [snip] $ grep swap /etc/crypttab # causes systemd to fsck swap #sda3_crypt UUID=ef2496cd-ca4d-43aa-8c90-dba084029f6e /dev/urandom cipher=aes-xts-plain64,size=256,swap # systemd doesn't fsck swap sda3_crypt /dev/sda3 /dev/urandom cipher=aes-xts-plain64,size=256,swap That cure looks retrograde to me because it throws away the uniqueness of UUIDs. What if /dev/sda3 changes, for whatever reason. A systemd 216 man page for crypttab says: WARNING: Using the swap option will destroy the contents of the named partition during every boot, so make sure the underlying block device is specified correctly. Could you not try using a /dev/disk/by-foo/... entry instead and see if that works? (I don't recognise the particular one Sven uses.) OGood catch! That completely blitzed my mind. I knew there was a reason for the UUID's! :-) In my /dev/disk/by-id/ directory I have both dm-name-sda3_crypt and dm-uuid-CRYPT-PLAIN-sda3_crypt which point to ../../dm-1. I can not use either of those in my /etc/crypttab because then I get the systemd.fsck problem again. Maybe that was the problem with the UUID?? However, I also have ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3 and wwn-0x10001354922489237504x-part3 that point to ../../sda3. Both of those will boot correctly and mount swap. Here is my update that works: sda3_crypt /dev/disk/by-id/ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3 /dev/urandom cipher=aes-xts-plain64,size=256,swap So my guess, if I understand this correctly, is that if I use the encrypted container, systemd.fsck freaks out, tries to and fails to mount, then just ignores swap altogether. However, if I tell LUKS to encrypt the actual partition, that somehow means systemd.fsck is happy with it. So bizarre. Thanks for pointing that out David! ~Stack~ signature.asc Description: OpenPGP digital signature
Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
On 03/28/2015 03:37 PM, Sven Hartge wrote: ~Stack~ i.am.st...@gmail.com wrote: [snip] In my /dev/disk/by-id/ directory I have both dm-name-sda3_crypt and dm-uuid-CRYPT-PLAIN-sda3_crypt which point to ../../dm-1. I can not use either of those in my /etc/crypttab because then I get the systemd.fsck problem again. Those device nodes only appear _after_ /etc/crypttab has been parsed. By using them inside the crypttab, you create a chicken-and-egg problem. Oh. Then yeah, that does explain some things...quite a bit actually. Maybe that was the problem with the UUID?? I guess, you used the UUID of the swap inside the crypted device. But this UUID changes on every boot, so it is of no use. Huh. More thoughts on that below. However, I also have ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3 and wwn-0x10001354922489237504x-part3 that point to ../../sda3. Both of those will boot correctly and mount swap. Here is my update that works: sda3_crypt /dev/disk/by-id/ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3 /dev/urandom cipher=aes-xts-plain64,size=256,swap Of course. /etc/crypttab needs the device on which to create the crypted device mapping. So my guess, if I understand this correctly, is that if I use the encrypted container, systemd.fsck freaks out, tries to and fails to mount, then just ignores swap altogether. However, if I tell LUKS to encrypt the actual partition, that somehow means systemd.fsck is happy with it. So bizarre. No, not bizzare at all, quite logic if one thinks about what layer is put on top of what other layer. You have /dev/disk/by-id/ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3 at the bottom. On top of that, you get /dev/mapper/sda3_crypt. And on top of that you get your swap-space. OK. So that actually does explain a lot. In another post on this thread you asked where I got that UUID from. That question fits in well here so I am just going to dump it all here. :-) I just checked a number of my systems with blkid and the UUID's I am using are indeed the physical /dev/sdx# UUID's.. All of the bizarre behavior totally make sense in those layers you described if the LUKS swap UUID is auto generated and different every boot. On the older Wheezy systems I also show a UUID for the LUKS swap device but I am not using that one. I rebooted a host and it did change. I have finally joined two previously disconnected thoughts in my brain and learned something today! :-) But at the same time, I am still not sure as to why systemd.fsck has issues with the UUID of the partition but is OK with the /dev/disk/by-id/pointer. Is this the correct way of doing it? (EG: have I been doing it wrong this whole time by using the physical partitions UUID? Should I update my other not-yet-updated-to-Jessie hosts to use /dev/disk/by-id?) Thanks for clarifying this! I do appreciate it. ~Stack~ signature.asc Description: OpenPGP digital signature
Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
On 03/28/2015 06:45 PM, Sven Hartge wrote: ~Stack~ i.am.st...@gmail.com wrote: In another post on this thread you asked where I got that UUID from. That question fits in well here so I am just going to dump it all here. :-) I just checked a number of my systems with blkid and the UUID's I am using are indeed the physical /dev/sdx# UUID's.. All of the bizarre behavior totally make sense in those layers you described if the LUKS swap UUID is auto generated and different every boot. If you use a static key and not /dev/urandom you can reuse the swap-space that is already present. But that defeats the purpose of encrypting the swap-space; you _want_ to forget the key and recreate the encryption layer on every boot so that there is no chance of any information leak from previous runs. But at the same time, I am still not sure as to why systemd.fsck has issues with the UUID of the partition but is OK with the /dev/disk/by-id/pointer. UUID=... uses the UUID of the filesystem or swap-space on a partition, _not_ the ID of the partition itself. That is totally different ID. Note that you have /dev/disk/by-id (which is the physical ID of the device, partition, device map or md-RAID-set) while /dev/disk/by-uuid is the UUID of whatever filesystem is on any device. You can only use the physical ones in /etc/crypttab. I guess by using the wrong (UU)ID the automatic dependency solvers of systemd create a deadlock while trying to activate the correct units in the correct order to do what you told it. This then turns into a fine demonstration of computer sciences GIGO principle: Garbage In - Garbage Out. Of course, systemd could be a bit nicer and tell you if there is something totally wrong, but maybe none of the authors has yet stumbled upon this problem because they _know_ it does not work and hence never tried it and never built any safe-guards into systemd to fail in a nicer way. Thanks for the explanation. I now understand the results of a lot of my experiments today. It makes a lot more sense and I understand they garbage aspect of pointing to the swap file system (which changes) instead of the physical partition for swap. One more question if you don't mind: I understand why the encrypted partition UUID is going to change every time, but the physical partition UUID for my /dev/sda3 shouldn't change though. If they are the same systemd.fsck shouldn't have a problem with the physical partition UUID of /dev/sda3, but yet it does (at least for me). So what is the difference between the UUID pointing to /dev/sda3 and the /dev/disk/by-id pointing to /dev/sda3? Thanks Sven! You have been a great help in me understanding this better! signature.asc Description: OpenPGP digital signature
Re: [solved] What is the correct way to set encrypted swap with systemd?
On 03/28/2015 08:32 AM, Sven Hartge wrote: ~Stack~ i.am.st...@gmail.com wrote: Remember back a few months ago when systemd wouldn't stop fsck'ing my swap partition? Why would systemd fsck the swap? swap does not need fscking. I have no idea. But, if I disable the swap partition the system boots just fine. If I enable it, fsck tries to run and the partition is complains about is the swap partition. I have no idea why systemd.fsck does this. :-/ [snip] I have the same setup on Debian Sid with systemd, just like you: ,[ /etc/crypttab | # target name source device key file options | cswap /dev/disk/by-id/md-uuid-a805edd5:bcfd4c98:ce747c2c:77d42131 /dev/urandomswap,cipher=aes-cbc-essiv:sha256,size=256 ` Thank you!! I think I just found out what my note systemd.fsck doesn't like UUID's meant! I was assuming it was in the /etc/fstab or somewhere, but when I noticed you have the /dev location of your disk and I have a UUID in the /etc/crypttab I decided to give it a try. $ grep swap /etc/crypttab # causes systemd to fsck swap #sda3_crypt UUID=ef2496cd-ca4d-43aa-8c90-dba084029f6e /dev/urandom cipher=aes-xts-plain64,size=256,swap # systemd doesn't fsck swap sda3_crypt /dev/sda3 /dev/urandom cipher=aes-xts-plain64,size=256,swap I reverted all of my changes that I took notes on and bada-bing-bada-boom! It works now! Out of curiosity (and because I have a sacrificial VM with various snapshots I can easily reset to), I setup a encrypted swap on a Ubuntu 15.04 alpha (pre-systemd) with my previous method. Swap worked perfectly. I 'apt-get update'd 15.04 and installed the systemd package (and a lot of dependencies o_O). On the first boot systemd.fsck had issues with swap and didn't mount it. I changed it to the disk instead of UUID and rebooted. Works!! So it isn't just systemd in Debian either. At least I now know in the future not to use UUID for swap in /etc/crypttab! Sometimes it seems that the most painful and frustrating problems have the most trivial solutions. :-D Thanks! ~Stack~ signature.asc Description: OpenPGP digital signature
What is the correct way to set encrypted swap with systemd?
Greetings, TL;DR - See Subject. :-) I have been testing Debian Jessie on my spare test laptop and with it being a test box and all, I tested something that didn't go the way I wanted it to and broke a lot of stuff. :-) I wiped my test laptop and reinstalled. Now I have the exact same problem as before and to make matters worse, I have gone through _all_ my notes and I can't replicate the fix now. Remember back a few months ago when systemd wouldn't stop fsck'ing my swap partition? https://www.mail-archive.com/debian-user@lists.debian.org/msg680287.html Yup. Systemd is ignoring me again and fscks on every boot. I have done everything I can think of and I am back to not being able to stop systemd from fsck'ing *every* time. I have done everything in that thread plus all of the notes I took and didn't post. I can't get it to stop. If I have to go through this pain on every new install going forward, it is going to really suck. So, maybe I am approaching this wrong? Maybe there is a new systemd-encrypt-swap service I am supposed to use? Is there a systemd-luks or something? I know it has to do with encrypted swap partitions. I proved that last time and I can prove it this time too. The method I have been using for a _very_ long time and has _always_ worked pre-systemd is this: $ grep swap /etc/crypttab sda3_crypt UUID=ef2496cd-ca4d-43aa-8c90-dba084029f6e /dev/urandom cipher=aes-xts-plain64,size=256,swap $ grep swap /etc/fstab /dev/mapper/sda3_crypt noneswap sw 0 0 Although, I did ensure I was using the path and not UUID as systemd had issues with that last time. So what happens? Well systemd has at least improved to the point of actually putting something in journalctl! Hooray! I am very pleased to see there has been good forward progress on this front. $ journalctl [snip] Mar 27 17:05:41 Senta kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-3.19.0-10-generic root=UUID=1fc1e143-2347-4d86-928e-f29d154891fb ro quiet splash fsck.mode=skip vt.handoff=7 [snip] Mar 27 17:07:10 Senta systemd[1]: Job dev-disk-by\x2duuid-ef2496cd\x2dca4d\x2d43aa\x2d8c90\x2ddba084029f6e.device/start timed out. Mar 27 17:07:10 Senta systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-ef2496cd\x2dca4d\x2d43aa\x2d8c90\x2ddba084029f6e.device. Mar 27 17:07:10 Senta systemd[1]: Dependency failed for Cryptography Setup for sda3_crypt. Mar 27 17:07:10 Senta systemd[1]: Dependency failed for Encrypted Volumes. Mar 27 17:07:10 Senta systemd[1]: Job cryptsetup.target/start failed with result 'dependency'. Mar 27 17:07:10 Senta systemd[1]: Dependency failed for dev-mapper-sda3_crypt.device. Mar 27 17:07:10 Senta systemd[1]: Job dev-mapper-sda3_crypt.device/start failed with result 'dependency'. Mar 27 17:07:10 Senta systemd[1]: Job systemd-cryptsetup@sda3_crypt.service/start failed with result 'dependency'. Mar 27 17:07:10 Senta systemd[1]: Job dev-disk-by\x2duuid-ef2496cd\x2dca4d\x2d43aa\x2d8c90\x2ddba084029f6e.device/start failed with result 'timeout'. How nice of it to record and ignore my fsck.mode=skip (and every other place I told it to stop doing a fsck)...Also, swap is not enabled at this time. I have to manually start it. It clearly doesn't like my encrypted swap and it is clearly ignoring me telling it to not fsck. Thus, how should I change my encryption to work with systemd? I have searched for this topic and I have not found anything that directly relates. I found an article from early last year saying to do what I already did but I haven't found anything in the last 6 months that has helped. Any thoughts or suggestions on this problem? Thanks! ~Stack~ signature.asc Description: OpenPGP digital signature
Re: What is the correct way to set encrypted swap with systemd?
On 03/27/2015 07:35 PM, Michael Biebl wrote: Am 27.03.2015 um 23:44 schrieb ~Stack~: Yup. Systemd is ignoring me again and fscks on every boot. I have done everything I can think of and I am back to not being able to stop systemd from fsck'ing *every* time. I have done everything in that thread plus all of the notes I took and didn't post. I can't get it to stop. Any thoughts or suggestions on this problem? Regarding this specific issue: Do you use localtime or UTC? If the former, you might be affected by [1] If you add a file /etc/e2fsck.conf containing: [options] broken_system_clock=1 Does that stop the fsck on every boot? [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767040 No. I am afraid it does not. There was a theory about it being the NTP last time around so I already double checked that the clock in the BIOS is pretty close to what NTP pulls. But I added this too just to see if it helped. No difference I am sad to say. Thanks for the suggestion! ~Stack~ signature.asc Description: OpenPGP digital signature
Re: Please stop systemd-fsck on _every_ boot!
Greetings, On 01/07/2015 11:06 AM, Rob Owens wrote: I suppose it's possible that the bios battery is no good, and the clock is getting reset after each shutdown. Then the last time fsck'd would be in the future, and I expect the system might fsck your disk as a precaution. You might never notice the clock issue if ntp or ntpdate is running and corrects the clock after the network is up. Thanks for the suggestion. I did check that and the clock was off a bit, but even after correcting it there was no change. ~Stack~ signature.asc Description: OpenPGP digital signature
Re: Please stop systemd-fsck on _every_ boot!
On 01/07/2015 08:16 AM, The Wanderer wrote: On 01/07/2015 at 08:39 AM, ~Stack~ wrote: [snip] However, I *have* read the man page and the man page for fstab says If the sixth field is not present or zero, a value of zero is returned and fsck will assume that the filesystem does not need to be checked. Therefore, I am explicitly telling systemd-fsck to buggeroff and not check. I as the owner of the device have acknowledged and assumed all the risk for not running fsck on my drive. The fact that it is /still/ doing it against my wishes is what annoys me. According to my understanding, this field is not in fact a global boot-time-fsck override, which you seem to be expecting it to be. There are actually (at least) two ways in which fsck can be triggered at boot time: by the automatic iterate-through-the-fstab is-a-fsck-needed procedure, which reads and respects this field (because it's iterating through fstab anyway), and in response to a failed mount attempt, which I believe ignores this field (because the fsck was invoked in a way which has nothing to do with fstab - just as would happen if you invoked fsck manually). Hrm. Ok. I learned something today. :-) I don't know why, but I really thought that meant that fsck wouldn't check at all if the sixth field was 0. Thanks! ~Stack~ signature.asc Description: OpenPGP digital signature
Re: Please stop systemd-fsck on _every_ boot!
On 01/07/2015 01:45 PM, Bob Proulx wrote: The Wanderer wrote: To my eye, based on what you've reported, it does look as if the reason your system is running fsck on every boot is that something about a mount attempt is failing. However, aside from probably to do with the swap partition, I have no clue what that something is - or how to figure out more, beyond what you already seem to know to try. I would also be concerned that on shutdown the disks aren't being marked as cleanly unmounted and shutdown. Causing them to need to be checked at boot time. I don't see anything in the log files saying otherwise. Then again, if it is on unmount then it wouldn't necessarily wouldn't be able to write the log files out... I did make some pretty big progress earlier today, unfortunately I am not sure the exact thing I did. I got in and started mucking about with the starting and stopping of systemd services and what not and now that kernel boot skip parameter works! So at least that is working now. :-) Though I think I might be ok with an every boot fsck that takes 2 seconds... Thanks! ~Stack~ signature.asc Description: OpenPGP digital signature
Re: Please stop systemd-fsck on _every_ boot!
On 01/07/2015 03:10 AM, Ric Moore wrote: On 01/06/2015 07:23 PM, ~Stack~ wrote: I keep seeing all of these posts online saying how easy it is to disable systemd from runing fsck because it honors the '0' in the sixth field of /etc/fstab. Well that's just pure bull$h1t... That was one of the first things I tried some time ago. As far as I can tell on neither of my Jessie machines (one physical one virtual) does systemd honor the fstab in terms of doing a fsck. All of the partitions are set to 0 in /etc/fstab. That doesn't make it bullshit, it means that in your instance it doesn't help. Instead, just maybe your system is trying to tell you something when it continually forces fsck. Read the man page. You are right in that there is something probably wrong with my instance and it might be trying to tell me something. However, I *have* read the man page and the man page for fstab says If the sixth field is not present or zero, a value of zero is returned and fsck will assume that the filesystem does not need to be checked. Therefore, I am explicitly telling systemd-fsck to buggeroff and not check. I as the owner of the device have acknowledged and assumed all the risk for not running fsck on my drive. The fact that it is /still/ doing it against my wishes is what annoys me. The trick is to get your poor stupid dumb machine to tell it's human where it hurts and how to fix it. It's like dealing with a puppy that whines. I will not deny that this laptop is more than a little weird. It's almost 10 years old and has seen its share of hardship in life. But as a secondary laptop I can haul around with me and not worry about it, it's a fantastic system. OK, your next message reveals that you are encrypting your drives, including swap?? Insert encrypted hard drive fsck into your search bar. Lately, others report problems. I did look for that. Obviously not in the right places, but even typing that exact string into my search bar returns results for people who have errors to work with and search against. I don't. All my messages say that fsck returned clean with the exception of the one that goes by too fast and says something about a timeout. Another thought would be to disable swap, if you have enough memory to see if that helps at all. man swapoff Well, since I figured out that systemd-fsck goes really quickly when I have /dev/sda3 instead of the UUID for the swap partition, it works just fine. I don't see how turning off swap all together will suddenly make systemd-fsck start listening to the boot parameter and fstab telling it not to run fsck at all. Since it was encrypted no telling what this would do: man swapoff swapoff-f, --fixpgsz Reinitialize (exec /sbin/mkswap) the swap space if its page size does not match that of the current running kernel. mkswap(2) initializes the whole device and does not check for bad blocks. --- # swapoff -a # swapon --fixpgsz /dev/dm-1 # swapon -a # swapon -s Filename Type Size Used Priority /dev/sda3 partition 585724 0 -1 No errors or anything, so I assume that is good... At any rate all the fsck'ing is telling you something is broken. That is what it is supposed to do. Not when I have told systemd-fsck to stop trying. Then it is supposed to not do it. Also, I have yet to see a report that says something other than clean. Using the information I have, I am leaning toward that something broken being systemd-fsck...I have run out of ideas on how to tell it to stop... If you are running luks check this: http://serverfault.com/tags/luks/hot Happy hunting troubleshooting with a shotgun. :) Ric Thanks! I do appreciate the help! ~Stack~ signature.asc Description: OpenPGP digital signature
Re: Please stop systemd-fsck on _every_ boot!
On 01/07/2015 05:21 AM, Martin Steigerwald wrote: Am Dienstag, 6. Januar 2015, 22:13:26 schrieb ~Stack~: In summary: * I have systemd-fsck disabled just about every damn place I can find to do so, yet it still runs on boot every time. I see it on the screen and in the log messages. * I still can't find where the hell systemd stores the same information it displays on the boot screen. nothing shown by journalctl? I did look there as well. I can see where it runs fsck but it says the partitions are clean. There are other error messages about it not liking my controller and what not, but no errors I see related to the fsck nor the timeout. I tried filming the message as it went by the boot, but the video just came out blurry...guess my camera isn't good enough. :-) ~Stack~ signature.asc Description: OpenPGP digital signature
Please stop systemd-fsck on _every_ boot!
Greetings, This problem has been a minor annoyance for a while but only recently have I started to use Jessie more and it is has finally peeved me off. I have been trying everything I can find for the last two hours and I still can't get systemd to STOP doing a fsck on _every_ boot! It tells me with a nice count down that it will take 1:45 minutes to run. It always runs longer and it always hangs on the swap partition. Immediately after it finishes there is a /super/ quick message about a timeout on the swap partition (that I can *not* find in the log files anywhere) followed by another message I can't read nor find in the log files. I see where it runs fsck in both the daemon and syslog, but _every_ partition is clean. There are no errors or timeouts that I can find in the logs. I keep seeing all of these posts online saying how easy it is to disable systemd from runing fsck because it honors the '0' in the sixth field of /etc/fstab. Well that's just pure bull$h1t... That was one of the first things I tried some time ago. As far as I can tell on neither of my Jessie machines (one physical one virtual) does systemd honor the fstab in terms of doing a fsck. All of the partitions are set to 0 in /etc/fstab. I found a post saying to disable it in /etc/fstab as a mount option 'x-systemd.automount'. That doesn't work either. $ sed -e '/^#/d' /etc/fstab /dev/mapper/sda2_crypt / ext4 errors=remount-ro 0 0 UUID=af9e4bfa-5591-4b9a-a855-3444b2562493 /boot ext4 defaults 0 0 /dev/mapper/sda3_crypt none swap,x-systemd.automount sw 0 0 /dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/mapper/sda4_crypt /home ext4 defaults 0 0 I tried disabling the systemd-fsck service. That didn't work either. Finally, I just tried fsck.mode=skip on the kernel command line...guess what? That doesn't work either. I thought maybe there was an issue with me interupting grub manually to add that line, so I also added it to /etc/default/grub's GRUB_CMDLINE_LINUX_DEFAULT and ran update-grub. After rebooting WITH a fsck being run, I can see it in my /proc/cmdline and when I look through my last boot log I can *see* it there too! Still doesn't work and systemd-fsck still runs on _every_ boot. $ cat cmdline BOOT_IMAGE=/vmlinuz-3.16.0-4-686-pae root=UUID=99d5a78e-7e8d-4426-83b2-33c06d630587 ro quiet init=/bin/systemd fsck.mode=skip At this point I don't even care anymore if my disks never run fsck again. I just want systemd-fsck to STOP running on EVERY boot. Thanks! ~Stack~ signature.asc Description: OpenPGP digital signature
Re: Please stop systemd-fsck on _every_ boot!
Greetings, On 01/06/2015 07:56 PM, Patrick Bartek wrote: Have you tried tune2fs on each partition? http://crashmag.net/disable-filesystem-check-fsck-at-boot-time I did and that didn't help either. After I sent my plea for help, I took a break to grab some dinner and chill. When I returned I started hacking on it again. I started with the fact that it always complained about the swap partition. I also noticed that it /wasn't/ using the swap partition anymore (it was very recently). Hrm. Well maybe that x-systemd.automount in fstab was working in that swap wasn't being automounted, but systemd-fsck was just ignoring the don't fsck this drive field. So I removed the automount statement. I also had my swap encrypted...could that have been playing a part in all of this? So I disabled the swap in crypttab and rebooted. It *still* ran a fsck, but instead of several minutes, it was 2-3 seconds. Swap also loaded properly. Hrm. So I added the swap line back into crypttab and presto, the long fsck boot came back. To cram about 45min of trial and error into a summary: systemd-fsck _really_ does not like having the UUID for swap in /etc/crypttab but it does seem to do ok with /dev/sda3 as the device instead. *shrug* In summary: * I have systemd-fsck disabled just about every damn place I can find to do so, yet it still runs on boot every time. I see it on the screen and in the log messages. * I still can't find where the hell systemd stores the same information it displays on the boot screen. * As far as I am concerned (granted with my very small sample size of 2) systemd flat out ignores the 6th field of fstab. * systemd-fsck apparently really hates UUID's for crypttab BUT! It now takes 2-3 seconds every time it says it is running a fsck during boot versus the 2-3 minutes it used to take. So I think I am just going to call it a win for now and go to sleep. :-) ~Stack~ signature.asc Description: OpenPGP digital signature
k9copy-reloaded?
Greetings, I prefer to have a digital backup copy of the movies I have legally purchased. Mainly because I am too lazy to get up and go to the DVD shelf whenever I want to watch something. :-) My preference for years has been to have an ISO file because disk is cheap and if I need to trans-code for $portable_device_of_the_moment going from near-original to $format_of_the_moment is trivial and not nearly as messy as going from $yesterdays_preferred_format to $format_of_the_moment. Thus, I have really liked k9copy. It is trivial to set up, yank out the previews and silly unskippable banners/warnings/messages, and get a raw ISO file. For those who don't know, the lead dev of k9copy decided he was done back in 2012. And Debian yanked the package shortly after (for obvious good reasons). I still have my old Debian Lenny box that I boot up, rip my latest purchase w/ K9copy, and shutdown. (VM's have been flaky for me trying to rip to k9copy; so an old box is what I use) It seems that someone is taking up the flag for k9copy and actively updating it. See here: k9copy-reloaded.sourceforge.net I just found out and for me, this is exciting news! I am hoping to hack on it during some time off next week to see if I can get it to run on a updated system. So the question for the Debian list is: * Has anyone tried the compile out yet? I am tempted to use my current Wheezy box simply because it is my dev machine and I have most everything ready to test on, but I worry about some of those newer library files required (note: I haven't looked at all of them in depth yet). Then again, I have a Jessie machine that I have been testing on for the past few months that I don't care if I break. It would have the newer libraries and is in freeze so there shouldn't be much volatility...Just curious if anyone has any experience they would like to share before I dig in and hit the same issues someone else has already solved. :-) * Anyone else use K9copy? Curious if there are any fans out there still. * Anyone have a better solution to K9copy? I know there are some really good alternatives for trans-coding purposes (eg: handbrake) but I don't know of any that will do ISO while keeping the important bits and stripping out the junk. Thanks! ~Stack~ signature.asc Description: OpenPGP digital signature
Re: Problem with systemd-sleep in Jessie
On 10/24/2014 10:23 AM, Michael Biebl wrote:
I extracted the lid state switch into a small test program.
Can you compile the attach test program (make switch). I hard-coded the
lid switch button to /dev/input/input1. You'll need to change that if
that's different on your system (check with evtest). You need to run
that binary as root.
What do you get if your that program when your lid is closed/opened?
It should return 0 if the lid is open and 1 if closed.
I can confirm this. I ran:
$(for i in {0..100}; do ./a.out; sleep 1; done)
I get 0 when the laptop lid is open and 1 when it is closed.
signature.asc
Description: OpenPGP digital signature
Re: Problem with systemd-sleep in Jessie
On 10/24/2014 10:55 AM, Michael Biebl wrote:
Am 24.10.2014 um 17:23 schrieb Michael Biebl:
What do you get if your that program when your lid is closed/opened?
The output of
$ cat /proc/acpi/button/lid/LID/state
when lid is closed / open would be helpful as well.
If you don't have an external monitor, you can run
sleep 30 cat /proc/acpi/button/lid/LID/state
and then quickly close your lid.
Greetings,
I ran:
$(for i in {0..100}; do cat /proc/acpi/button/lid/LID/state ; sleep 1; done)
I get state: open when the lid is open and state: closed when closed.
signature.asc
Description: OpenPGP digital signature
Re: Problem with systemd-sleep in Jessie
On 10/25/2014 04:01 PM, ~Stack~ wrote:
On 10/24/2014 10:55 AM, Michael Biebl wrote:
Am 24.10.2014 um 17:23 schrieb Michael Biebl:
What do you get if your that program when your lid is closed/opened?
The output of
$ cat /proc/acpi/button/lid/LID/state
when lid is closed / open would be helpful as well.
If you don't have an external monitor, you can run
sleep 30 cat /proc/acpi/button/lid/LID/state
and then quickly close your lid.
Greetings,
I ran:
$(for i in {0..100}; do cat /proc/acpi/button/lid/LID/state ; sleep 1; done)
I get state: open when the lid is open and state: closed when closed.
Eureka!! I think I have a lead!
So when I do a fresh reboot and have _not_ closed the lid but run the
code you send and cat'ing the state, it seems to think the lid is
closed. When I close the lid the state remains as a closed lid. When I
open the lid, it finally triggers as being open.
So now the question is, why does it think my laptop lid is closed on a
fresh boot?
Thanks!
signature.asc
Description: OpenPGP digital signature
Re: Problem with systemd-sleep in Jessie
On 10/23/2014 10:25 PM, Michael Biebl wrote: Am 24.10.2014 um 04:58 schrieb Michael Biebl: Am 24.10.2014 um 04:19 schrieb Michael Biebl: For some reason, you seem to be getting acpi events which trigger the suspend request in logind. This might be a buggy ACPI implementation like in [1]. To further debug this, you might install the evtest package and run the evtest binary as root. Another thing you can try is the following (run as root): $ systemctl stop systemd-logind.service $ /lib/systemd/systemd-logind This will show you, which input devices logind will monitor and which events it receives. # /lib/systemd/systemd-logind New seat seat0 Watching system buttons on /dev/input/event5 (Power Button) Watching system buttons on /dev/input/event1 (Video Bus) Watching system buttons on /dev/input/event4 (Power Button) Watching system buttons on /dev/input/event2 (Lid Switch) Watching system buttons on /dev/input/event3 (Sleep Button) New session c1 of user lightdm New session 1 of user root. Suspending... Power key pressed. Operation finished. As soon as I ran the command, that is what happened. The Power key pressing was me waking it back up. Thanks! signature.asc Description: OpenPGP digital signature
Re: Problem with systemd-sleep in Jessie
On 10/23/2014 11:19 PM, Ric Moore wrote: To the OP: Stack. THANK YOU for starting an intelligent systemd QA. I have voiced my systemd concerns before. At this time, I am simply tying to figure out what is wrong with my laptop. Should systemd be the default/only init system when Jessie releases, I would rather have all these weird quirks fixed /before/ the release. Thus, I am trying to learn about systemd and understand what is going on vs starting yet another flamewar (there is enough of those at the moment...I really don't want to add another). One feature I read about is that systemd will shut down under various conditions that would also prevent exhausting the battery on a laptop. A good thought. The battery on this 8yr old laptop is long dead. I only keep it in the laptop because it balances the weight (and there is an awkward gap in the back without it). A new battery for this laptop is 90$. Not worth it for this laptop. In any case, I removed the battery and I still have the issue. I don't suppose there is anyway to install fresh to get rid of old cruft?? I am sure I could, but it isn't easy as this laptop doesn't support USB boot and the CD-ROM is long dead too. I have to PXE boot the network image for the Debian install... Besides, I would rather see if I can find what is wrong vs just blowing it away and potentially losing whatever caused the problem. If I lose that, then we can't file a bug report to have it fixed which in turn means others might have this same issue in the future. If at all possible, I would like to find a proper fix. I'm of no help as I am just starting to learn it, but I am learning from your experience, so that you again. bows deeply Ric I'm learning too. :-) Thanks for the input. signature.asc Description: OpenPGP digital signature
Re: Problem with systemd-sleep in Jessie
On 10/23/2014 11:06 PM, Michael Biebl wrote: That looks all fine. Can you remove the settings again from logind.conf and restart systemd-logind while monitoring what evtest logs and and also what systemd-logind logs. For the latter, you can either run systemd-logind in the foreground (as I described) or use Joey's method to filter journal entries via journalctl -u systemd-logind -f I did as you asked. I had the F1 terminal set to start systemd-login, F2 terminal was watching journalctl, F3 was watching evtest for input 4 (I also retested with the others, but similar results). The /only/ thing that journalctl prints out is Suspending Everything else is related to when I press the button to wake it back up. As for the evtest, I get this message over and over again: Event: time timestamp, type 1 (EV_KEY), code 116 (KEY_POWER), value 1 Thanks for helping me on this! signature.asc Description: OpenPGP digital signature
Re: Problem with systemd-sleep in Jessie
On 10/23/2014 09:36 PM, ~Stack~ wrote: On 10/23/2014 08:29 PM, Don Armstrong wrote: You can also change /etc/systemd/logind.conf, and change the HandlePowerKey=, HandleSuspendKey=, HandleHibernateKey=, HandleLidSwitch= all to ignore temporarily. Done. That seems to work! The laptop isn't sleeping incessantly. :-) Just because I was curious, I decided to test out which one of these is actually the culprit. Thus, I edited logind.conf and commented out the ignore line on all but one at a time. Then 'systemctl stop systemd-logind.service' and then 'systemctl start systemd-logind.service' (yeah, I could have probably done a restart, but I wanted to ensure a full stop). Every time the laptop would instantly go to sleep on start. Except for HandleLidSwitch. That is the one causing problems. Leaving that one set to ignore stops the constant sleep cycle. Maybe the smarter people have already figured that out, but for me it was nice to know the exact one being a pain. :-) Thanks! signature.asc Description: OpenPGP digital signature
Problem with systemd-sleep in Jessie
Greetings, I have been running Jessie i386 on a spare laptop just so I can see how all the big changes that are coming will impact me. For the last few months, nothing too big has really hit me (at least none that don't have a bug filed already). Well, that is until now. I think I last booted/updated this laptop last weekend. I booted it up tonight to mess around on it and the first thing, as always, was to run updates. A bunch of systemd stuff updated. Now the laptop is dang near unusable. It boots and it will sit at the log in screen for quite some time like everything is good and happy. If I log in either via GUI (LXDE) or via command line, the laptop goes to sleep anywhere between 2 and 15 seconds later. I have to hit the power button (no other button on the laptop is responsive) and it will wake up again but promptly go back to sleep 2-15 seconds later. And repeat. It took me over a minute simply trying to log in via the CLI just run a 'tail -f /var/log/syslog' because for whatever reason it really just wants to go to sleep. The only thing that I really see is a line that reads: time hostname systemd-sleep: suspending session Nothing before it of any consequence, and after is just logs about the system going into sleep mode. So I have been digging around trying to figure out what is going on and I can't seem to stop it. Here is what I know: * There is nothing in the /etc/systemd/sleep.conf file. * It is technically going into a suspend. * I have no idea what dictates how long it will last before going back to sleep. * I tried to reinstall systemd with no luck (that took forever...when it takes 3-5 seconds for NetworkManger to bring up the wireless connection and the window for activity is 2-15 seconds...well I am kinda surprised I didn't jack up the install when it went to sleep in the middle of the install...twice!). * Unless I have something specific to search for, the system logs are worthless because they are _flooded_ with the information about going-to/waking-up-from sleep. I haven't really figured out systemd yet but I am not making much progress with online searching at the moment. Can anyone help me figure out how to stop systemd from trying to go to sleep all the time? This is quite annoying... Thank you! ~Stack~ signature.asc Description: OpenPGP digital signature
Re: Problem with systemd-sleep in Jessie
On 10/23/2014 08:32 PM, Joel Rees wrote: 2014/10/24 9:57 ~Stack~ i.am.st...@gmail.com mailto:i.am.st...@gmail.com: snip It boots and it will sit at the log in screen for quite some time like everything is good and happy. If I log in either via GUI (LXDE) or via command line, the laptop goes to sleep anywhere between 2 and 15 seconds later. CLI? From a virtual (CTRL-ALT-fN) terminal? That is correct. I'd suspect something in power management, maybe, but who knows? Is sshd running so you could try logging in from the network? If it doesn't go to sleep when logged in from the network, that would be a data point. And, assuming the translating from binary to text didn't get in the way, it would allow you to do a looped tail on the log files to try to watch while you logged in from the keyboard. Of course, having another user logged in might trigger the Can't log off while other users are logged. condition, but that would be yet another data point. It does go to sleep when logged in remotely. Or have you tried booting a live image on an external device so you can read the logs at better leisure, grep, etc.? Unfortunately, there are a number of reason why this is a test laptop. The CD-ROM being busted is one...not booting from USB is another...To install Jessie I rigged a PXE boot menu to launch the contents for a network install. Thanks! signature.asc Description: OpenPGP digital signature
Re: Problem with systemd-sleep in Jessie
On 10/23/2014 08:29 PM, Don Armstrong wrote: On Thu, 23 Oct 2014, ~Stack~ wrote: It boots and it will sit at the log in screen for quite some time like everything is good and happy. If I log in either via GUI (LXDE) or via command line, the laptop goes to sleep anywhere between 2 and 15 seconds later. I have to hit the power button (no other button on the laptop is responsive) and it will wake up again but promptly go back to sleep 2-15 seconds later. And repeat. For starters, if you append systemd.unit=rescue.target to the kernel command line, you'll get a rescue shell that you can use to interrogate the system. Thanks! That does appear to work well to get me in un-interrupted. I'm suspecting that you have some sort of contest between pm-utils or similar trying to suspend the laptop, but I'm not certain. You should be able to examine the logs and use journalctl to see precisely what systemd is trying to do at that point. Errr...fraid this is all rather new to me but at the moment I am not getting much of anything out of journalctl. Let me bust out my search-foo and see if I can get something useful. You can also change /etc/systemd/logind.conf, and change the HandlePowerKey=, HandleSuspendKey=, HandleHibernateKey=, HandleLidSwitch= all to ignore temporarily. Done. That seems to work! The laptop isn't sleeping incessantly. :-) So while I was waiting on a response, I copied off the syslog to another box to examine it (in only 3 tries! :-). There is a re-occuring theme and it does look like I may have just missed the info previous to the systemd-sleep. See snippet below. The CTRL-EVENT-SCAN-STARTED /always*/ starts the problem and the nm-dispatcher /always*/ ends. *Where always == every time I have found it in my logs so far. :-) There are usually several seconds between CTRL-EVENT-SCAN-STARTED and whatever happened in the log before it. After this, the pattern is almost identical every time and takes about the same amount of time. sysctl snippet: Oct 23 19:15:37 Senta wpa_supplicant[877]: wlan0: CTRL-EVENT-SCAN-STARTED Oct 23 19:15:38 Senta NetworkManager[582]: info sleep requested (sleeping: no enabled: yes) Oct 23 19:15:38 Senta NetworkManager[582]: info sleeping... Oct 23 19:15:38 Senta NetworkManager[582]: info (wlan0): device state change: activated - unmanaged (reason 'sleeping') [100 10 37] Oct 23 19:15:38 Senta NetworkManager[582]: info (wlan0): deactivating device (reason 'sleeping') [37] Oct 23 19:15:38 Senta NetworkManager[582]: info (wlan0): canceled DHCP transaction, DHCP client pid 2400 Oct 23 19:15:38 Senta kernel: [ 394.584207] wlan0: deauthenticating from 00:16:01:2d:98:ae by local choice (Reason: 3=DEAUTH_LEAVING) Oct 23 19:15:38 Senta wpa_supplicant[877]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:16:01:2d:98:ae reason=3 locally_generated=1 Oct 23 19:15:38 Senta systemd-udevd[197]: Network interface NamePolicy= disabled on kernel commandline, ignoring. Oct 23 19:15:38 Senta kernel: [ 394.610725] cfg80211: Calling CRDA to update world regulatory domain Oct 23 19:15:38 Senta kernel: [ 394.685745] cfg80211: World regulatory domain updated: Oct 23 19:15:38 Senta kernel: [ 394.685754] cfg80211: DFS Master region: unset Oct 23 19:15:38 Senta kernel: [ 394.685758] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) Oct 23 19:15:38 Senta kernel: [ 394.685765] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) Oct 23 19:15:38 Senta kernel: [ 394.685771] cfg80211: (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) Oct 23 19:15:38 Senta kernel: [ 394.685777] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 mBm), (N/A) Oct 23 19:15:38 Senta kernel: [ 394.685782] cfg80211: (517 KHz - 525 KHz @ 16 KHz), (N/A, 2000 mBm), (N/A) Oct 23 19:15:38 Senta kernel: [ 394.685788] cfg80211: (525 KHz - 533 KHz @ 16 KHz), (N/A, 2000 mBm), (0 s) Oct 23 19:15:38 Senta kernel: [ 394.685794] cfg80211: (549 KHz - 573 KHz @ 16 KHz), (N/A, 2000 mBm), (0 s) Oct 23 19:15:38 Senta kernel: [ 394.685799] cfg80211: (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 2000 mBm), (N/A) Oct 23 19:15:38 Senta kernel: [ 394.685804] cfg80211: (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 0 mBm), (N/A) Oct 23 19:15:38 Senta dbus[586]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' Oct 23 19:15:38 Senta systemd-sleep[2471]: Suspending system... Oct 23 19:15:38 Senta dbus[586]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Oct 23 19:15:38 Senta nm-dispatcher: Dispatching action 'down' for wlan0 One other thing that is very odd is that I see a lot of these messages below. They are usually very-tightly grouped and again there is usually a few seconds gap surrounding these messages. Should I be worried about this? Oct 23 19:15:19 Senta
Re: Problem with systemd-sleep in Jessie
On 10/23/2014 09:19 PM, Michael Biebl wrote: Hi, Am 24.10.2014 um 02:40 schrieb ~Stack~: I think I last booted/updated this laptop last weekend. I booted it up tonight to mess around on it and the first thing, as always, was to run updates. A bunch of systemd stuff updated. Now the laptop is dang near unusable. Could you please check, from which version you updated, so we know which version did not exhibit this behaviour and which version does. See /var/log/dpkg. It looks like I went from 204-14 to 215-5+b1 if I am reading this correctly. Which version do you currently run? 215-5+b1 It boots and it will sit at the log in screen for quite some time like everything is good and happy. If I log in either via GUI (LXDE) or via command line, the laptop goes to sleep anywhere between 2 and 15 seconds later. I have to hit the power button (no other button on the laptop is responsive) and it will wake up again but promptly go back to sleep 2-15 seconds later. And repeat. It took me over a minute simply trying to log in via the CLI just run a 'tail -f /var/log/syslog' because for whatever reason it really just wants to go to sleep. The only thing that I really see is a line that reads: time hostname systemd-sleep: suspending session Nothing before it of any consequence, and after is just logs about the system going into sleep mode. So I have been digging around trying to figure out what is going on and I can't seem to stop it. Once you're logged in, run systemd-inhibit --what=sleep /bin/sleep 3600 [1]. This should block any suspend requests for one hour. Thanks. I made the temp modifications from Don Armstrong's suggestion which seems to have given me relief. Or for a permanent change, you can edit /etc/systemd/logind.conf and set HandleSuspendKey and HandleLidSwitch to ignore. Yup. That's the suggestion. :-) Could you describe your hardware in more detail. What type of computer, which graphics card and driver, monitor setup etc. Sure, here is the laptop: http://linuxcertified.com/linux-laptop-lc2100dc.html It has run a flavor of Linux for...geez...like 8 years...and I have never had an issue with any Linux distro running on it (the reason why I bought it :-). For some reason, you seem to be getting acpi events which trigger the suspend request in logind. This might be a buggy ACPI implementation like in [1]. Michael [1] https://wiki.archlinux.org/index.php/Acer_Aspire_One#Suspend_on_lid.2C_shutdown_on_power_button [1] http://www.freedesktop.org/software/systemd/man/systemd-inhibit.html Thanks! signature.asc Description: OpenPGP digital signature
Re: Problem with systemd-sleep in Jessie
On 10/23/2014 10:01 PM, Michael Biebl wrote: Am 24.10.2014 um 04:36 schrieb ~Stack~: So while I was waiting on a response, I copied off the syslog to another box to examine it (in only 3 tries! :-). There is a re-occuring theme and it does look like I may have just missed the info previous to the systemd-sleep. See snippet below. The CTRL-EVENT-SCAN-STARTED /always*/ starts the problem and the nm-dispatcher /always*/ ends. *Where always == every time I have found it in my logs so far. :-) That's a red herring. NM simply listens to the logind sleep requests and disables the network interface on sleep and re-enables it on resume. That's why those events coincide. It's not the cause for it, but a reaction. Rats. I was afraid of that. Just hoping that it would be simple. ;-) Thanks. signature.asc Description: OpenPGP digital signature
Re: Problem with systemd-sleep in Jessie
On 10/23/2014 09:58 PM, Michael Biebl wrote: Am 24.10.2014 um 04:19 schrieb Michael Biebl: For some reason, you seem to be getting acpi events which trigger the suspend request in logind. This might be a buggy ACPI implementation like in [1]. To further debug this, you might install the evtest package and run the evtest binary as root. Please post the shown list You might get an entry like /dev/input/event1: Lid Switch I do have this. If you select that event number (1), do you get any lid switch events event though the lid is not closed or when the lid switch is closed? Do you have other input devices which generate the SW_LID event? You can try them one by one. Sure. I am not familiar with this tool so I am not sure what I am looking at currently. Thus, here is what I did: * I tested the Lid Switch by closing and opening the lid; the screen turns off then back on again. * I tested the Sleep Button; nothing happened * I tested Power Button 3; nothing happened * I tested Power Button 4; result below. Do I need to remove those entries I put in /etc/systemd/logind.conf? I worry if I do remove them, then I won't get a good test... root@Senta:~# evtest No device specified, trying to scan all of /dev/input/event* Available devices: /dev/input/event0: AT Translated Set 2 keyboard /dev/input/event1: Lid Switch /dev/input/event2: Sleep Button /dev/input/event3: Power Button /dev/input/event4: Power Button /dev/input/event5: Video Bus /dev/input/event6: PC Speaker /dev/input/event7: HDA Digital PCBeep /dev/input/event8: SynPS/2 Synaptics TouchPad Select the device event number [0-8]: 1 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x0 product 0x5 version 0x0 Input device name: Lid Switch Supported events: Event type 0 (EV_SYN) Event type 5 (EV_SW) Event code 0 (SW_LID) Properties: Testing ... (interrupt to exit) Event: time 1414121647.010196, type 5 (EV_SW), code 0 (SW_LID), value 0 Event: time 1414121647.010196, -- EV_SYN ^C root@Senta:~# evtest No device specified, trying to scan all of /dev/input/event* Available devices: /dev/input/event0: AT Translated Set 2 keyboard /dev/input/event1: Lid Switch /dev/input/event2: Sleep Button /dev/input/event3: Power Button /dev/input/event4: Power Button /dev/input/event5: Video Bus /dev/input/event6: PC Speaker /dev/input/event7: HDA Digital PCBeep /dev/input/event8: SynPS/2 Synaptics TouchPad Select the device event number [0-8]: 2 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x0 product 0x3 version 0x0 Input device name: Sleep Button Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 142 (KEY_SLEEP) Properties: Testing ... (interrupt to exit) ^C root@Senta:~# evtest No device specified, trying to scan all of /dev/input/event* Available devices: /dev/input/event0: AT Translated Set 2 keyboard /dev/input/event1: Lid Switch /dev/input/event2: Sleep Button /dev/input/event3: Power Button /dev/input/event4: Power Button /dev/input/event5: Video Bus /dev/input/event6: PC Speaker /dev/input/event7: HDA Digital PCBeep /dev/input/event8: SynPS/2 Synaptics TouchPad Select the device event number [0-8]: 3 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x0 product 0x1 version 0x0 Input device name: Power Button Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 116 (KEY_POWER) Properties: Testing ... (interrupt to exit) ^C root@Senta:~# evtest No device specified, trying to scan all of /dev/input/event* Available devices: /dev/input/event0: AT Translated Set 2 keyboard /dev/input/event1: Lid Switch /dev/input/event2: Sleep Button /dev/input/event3: Power Button /dev/input/event4: Power Button /dev/input/event5: Video Bus /dev/input/event6: PC Speaker /dev/input/event7: HDA Digital PCBeep /dev/input/event8: SynPS/2 Synaptics TouchPad Select the device event number [0-8]: 4 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x0 product 0x1 version 0x0 Input device name: Power Button Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 116 (KEY_POWER) Properties: Testing ... (interrupt to exit) Event: time 1414121702.744549, type 1 (EV_KEY), code 116 (KEY_POWER), value 1 Event: time 1414121702.744549, -- EV_SYN Event: time 1414121702.744566, type 1 (EV_KEY), code 116 (KEY_POWER), value 0 Event: time 1414121702.744566, -- EV_SYN ^C root@Senta:~# Thanks! signature.asc Description: OpenPGP digital signature
Re: debian-advocacy?
won't care about in the very near future. Heck, I may not care about it after the 7.1 release in which there are a dozen other things of higher priority (to us) I am hoping are fixed... Maybe I am wrong, but my personal opinion is this: I don't think most people really understand this battle and they won't until they start running systemd and see it first hand. Plenty of people will not care or notice at all. When Jessie releases, that is when I expect to see real, honest reviews of systemd in Debian. Where does it work? Where does it fail? Are people switching to Jessie, or is there sudden surge over at distro watch for a new distro call Debian Jessie without systemd? What init system will people /actually/ be running? What will be reported back via the apt stats? The Gnome 3 battle gave the community (IMO, the terrible...) Gnome 3, Unity (which was anything but unifying), MATE, Cinnamon, LXDE, and it seems like there are a dozen other desktops I haven't even tried that sprung up. Will there be the same kind of splintering/support with systemd? I don't know, but I am going to be watching quite closely. I am trying to give systemd a chance, but it is very much on the fence for me and I don't feel I can give a properly educated reason for one side or the other. Thus I have no real reason being vocal for either side. When I do make that decision, my actions will reflect my vote. Jessie may need to be widely considered the Vista of Debian releases before a majority of DDs are willing to revisit the init default. Gah, I hope it doesn't get that far. At this time, I don't care which side it falls on, but a vista release is the last thing I want. Still, it does worry me ever so slightly if for no other reason than because of how worked up people are over this fight in /every/ community I am in. From the Debian list, to /., to reddit, to the local LUG, to even a very excited debate at Texas Linux Fest that ended when both sides agreed to disagree and leave. (It wasn't anything bad, but both sides were rather passionate and getting riled up when they decided it wasn't the time/place for it.) If there is enough backlash, then maybe it will be the vista release. But I honestly kind of doubt it. Many of the other Linux communities swallowed the pill without too much disruption... The is currently no means to garner meaningful data about Jessie's approval ratings, which likely means the release team will, as usual, just guess what will fly. They've had an enviable run, to be sure. Agreed. :-) ~Stack~ signature.asc Description: OpenPGP digital signature
Bash printf oddity; octal?
Greetings, I know this isn't explicitly a Debian problem, but I have seen many really smart Bash programmers on this list so I figured this was a good place to ask. :-) $ bash --version GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu $ cat /etc/debian_version 7.5 I have a Bash script I am working on where I am getting (supposedly) a two-digit number from the user. I handle all the logic to ensure I am getting two digits and not 2, letters, characters, ect in a different function. By the time I get to this code in my script, I am assuming it is a one or two digit number. Because I need a two digit number I am assuming that my user may have just input a single digit for the first nine numbers without a leading zero. I am doing this in my code like: verifiednum=`printf %02d $uservar` This works really well when they enter only a single digit or 01-07. However, on 08 or 09, this fails. $ cat test.sh #!/bin/bash - printf %02d 07 #This Works. echo printf %02d 8 #This Works. echo printf %02d 08 #This doesn't. echo printf %02d 9 #This Works. echo printf %02d 09 #This doesn't. echo $ ./test.sh 07 08 ./test.sh: line 6: printf: 08: invalid octal number 00 09 ./test.sh: line 10: printf: 09: invalid octal number 00 I almost want to think that this is a bug, but because it seems to be thinking it is an octal number (which technically it is I suppose :). I am guessing that it just doesn't like what I am doing with printf but I am a bit baffled as to why it only croaks on 08 and 09. 1) Does anyone know what is wrong here? 2) Is there a better way of solving this issue? Thanks! ~Stack~ signature.asc Description: OpenPGP digital signature
Re: Bash printf oddity; octal?
On 05/04/2014 03:42 PM, Asif Iqbal wrote: On Sun, May 4, 2014 at 4:32 PM, ~Stack~ wrote: [snip] verifiednum=`printf %02d $uservar` This works really well when they enter only a single digit or 01-07. However, on 08 or 09, this fails. [snip] 1) Does anyone know what is wrong here? leading zero is interpreted as octal. You need to prepend the number with 10# to convert it to decimal first That makes sense. But why does it only fail on 08 and 09? Shouldn't it also fail on 01-06? 2) Is there a better way of solving this issue? so try this instead printf %02d $(( 10#08 )) Yup! That worked! Thank you very much! ~Stack~ signature.asc Description: OpenPGP digital signature
Re: Bash printf oddity; octal?
On 05/04/2014 03:57 PM, Asif Iqbal wrote: On Sun, May 4, 2014 at 4:54 PM, ~Stack~ i.am.st...@gmail.com mailto:i.am.st...@gmail.com wrote: That makes sense. But why does it only fail on 08 and 09? Shouldn't it also fail on 01-06? Isn't that obvious? Unless in your world, octal 6 is different than decimal 6 :-) Oh duh. Yes. Yes it is obvious. :-[ I was so focused on this one tiny little error causing so many problems that I didn't actually stop and think about the problem as a whole. Derp. Thanks for the help, insight, and the laugh-out-loud-duh-moment. :-) ~Stack~ signature.asc Description: OpenPGP digital signature
Re: AppArmor or SELinux?
Hello Claudius, I don't have a ton of experience with SELinux on Debian. However, a specific work project requires a deployment of Red Hat systems all with SELinux and I have been very impressed with how easy it is to setup and administer. I have been impressed for a while now, actually. We are using it for specific services but I don't see why it would be any different setting up pidgin or opera. I have only deployed SELinux to a single Debian system and that was under Lenny. I don't recall it being problematic or anything. We set it up and ( just like most of my Debian systems ) let the server run its course without much effort outside of basic updates/maintenance. I played with AppArmor on Ubuntu a few months ago and I can see how it can be an alternative to SELinux, but I think my experience at work has given me a bias as I got frustrated with it and eventually gave up. I think SELinux is good project and worth knowing and deploying. Just my 2 cents. Good luck! ~Stack~ signature.asc Description: OpenPGP digital signature
Off topic question about grep
Hello everyone! I ran into a strange issue with grep and I was hoping someone could explain what I feel is an oddity. I was trying to match a word that starts with either a _ or a letter followed by any number of _, letters, or numbers. (eg: Good = Asdf1, _aSD1. Bad: 9_asD ). My test text file is just those three examples, each on a new line. I first tested with this: [_a-zA-Z][_a-zA-Z0-9] But that would match against 9_asD which begins with a number (not what I wanted). So I tried: [_a-zA-Z][_a-zA-Z0-9]* I realize that the expression won't do what I mistakenly thought I wanted it to do. What is puzzling to me is that my hard disk usage peaked, my cpu jumped, and grep took almost two minutes to return an exit code of 1 (no match). :-/ At first I thought it may be an issue with Debian Squeeze (current box) so I tried it on Debian Lenny with similar results. Same for an Ubuntu Lucid and Fedora 10. So I am pretty sure it is something with grep and not just the version of grep. I was hoping someone might know why grep behaves so oddly with that expression. If it was a monster file or something I could understand the system utilization peak, but it is just three lines in a text file. Just so you know, I have a working solution. In my case, every instance is on a new line so I have a working expression using: ^[_a-zA-Z][_a-zA-Z0-9]*$ I am just curious about the odd behavior. Thanks! signature.asc Description: OpenPGP digital signature
Re: Off topic question about grep
On 11/09/2010 12:26 PM, Bob McGowan wrote: On 11/09/2010 06:00 AM, Jochen Schulz wrote: ... What was your exact command line? Did you quote the regular expression? My guess is that the shell interpreted the '*' character for you and you ended up with a command line like this: $ grep [_a-zA-Z][_a-zA-Z0-9]file1 file2 file3 ... The shell will expand the above into space separated values, based on matches to the glob pattern. The first match will become the pattern used by grep, searched for in the remaining file names. Try this: echo grep [_a-zA-Z][_a-zA-Z0-9]* to see what the shell does in any particular case. Yeah. I feel really silly now. I was so focused on getting the regular expression right that I completely forgot to consider the shell interpreting things on my behalf. Couldn't see the forest because of the tree in my way I guess. Thanks! I do appreciate it. signature.asc Description: OpenPGP digital signature
Question about CVE-2010-3081
Hey guys, I am running the 64bit version of Squeeze. I am sure you guys have heard about the issues surrounding CVE-2010-3081 as it has made all kinds of news this past weekend. I have done some reading on it and while I am not paranoid enough to yank the connection from the wall, I must admit that with almost every one of my tech news sources freaking out about it these past few days I am being tempted by all the fear-mongering media outlets... When I first saw the Debian advisory[1] I just brushed it off and thought nothing of it. It seemed to have already been patched so I would simply update the next time I saw that there was a kernel update. However, the tracker[2] is still showing it to be vulnerable in Squeeze. [1] http://www.debian.org/security/2010/dsa-2110 [2] http://security-tracker.debian.org/tracker/CVE-2010-3081 Ksplice seems to be toting a patch as well as a scanner[3], but one look at the scanner code and I am not entirely sure I want to run it. Any code this obfuscated gives me the creeps. I have to side with /. on this one[4]. I checked around and was unable to find anything about chkrootkit being able to detect this one yet. [3] https://www.ksplice.com/uptrack/cve-2010-3081.ssi.xhtml [4] http://linux.slashdot.org/comments.pl?sid=1792608cid=33632118 I thought I would check in with the list before I go too crazy. Anyone know when the patch is going to be pushed out to Squeeze? Anyone know when/if there will be a vulnerability scanner for this that doesn't look so scary? Have I missed something that makes all this pointless? :-P Thanks! ~Stack~ signature.asc Description: OpenPGP digital signature
Re: Theoretical drive swapidge.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 jeremy jozwik wrote: what i am hoping for however is to more or less mirror the current drive / instillation over to the larger drive that will be installed. i would rather not have to re-install debian and all its configurations to the larger drive. It has been a while since I have had the need to do this, but I have done this successfully using a live CD. I created the partitions exactly how I wanted them with Gparted and then used partimage to copy the partitions over. The reason I used partimage over something like dd is because dd would resize the partition as it was making an exact copy. Using partimage I just told it to copy over the data and expand to the larger partition on the new drive. I was told partimage uses dd in the background so it obviously knows the right flags that I don't. Either way, it is a nice interface to the whole process. Two words of my own personal advice (take or leave as you see fit). 1) Use something like BleachBit (It is in Squeeze don't think it is in Lenny) to wipe free disk space. I have found that a drive that has been well used takes a LONG time to copy over, but when you zero out all the 'empty' space and only copy over the retained data you actually want, it goes much faster. You may prefer to not risk this and wait out the time. When I did this I went from a bunch of 300GB drives to 1TB drives, the drives that I zeroed out the /scratch partition that held temp files (~80% of the drive) were done so much faster then the one I did the whole drive without zeroing. It makes sense though. Copy 50GB vs 300GB. You only have an 80GB drive so you may just want to wait it out. Up to you. 2) Practice the methods on a drive with data you don't care about losing first. Dig out some old 10GB drives from the back of the computer bin or something, test it out, and keep good notes. It is really just a test to make sure you don't make a silly mistake that zero's out your whole hard drive or try to copy the wrong partition to the wrong place and lose data. You *should* have a backup before you start, but restoring can be a bother so this is just an extra step to help ensure you don't mess something up when it is time to do the real thing. They say practice makes perfect, right? ok, does it help if i have another machine where i can mount both the old laptop drive and the newer laptop drive and then do a copy everything from old to new and still retain a working machine? If your laptop can hold both drives at the same time then you don't have to have another system. Also, if you don't mind USB speeds, there are plenty of adapters you could use to have both online. However, if you have a spare system ready to go that requires no modification then might as well use it. If you don't have an adapter and your laptop can't use both at the same time, it would be recommended to have another system. Hope this helps! ~Stack~ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkui/b0ACgkQ4OKTk6qYr2S3gACghmO26b8EJAlQRYnrhwxQZh/f SHAAoJ04o5dMo3TDTR6z0novT0WWSVXs =4PjI -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ba2fdbd.2030...@gmail.com
