Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide
On Mon, Feb 01, 2016 at 11:11:14AM -0600, Doug Newgard wrote: > On Mon, 01 Feb 2016 22:27:01 +0530 > Jayesh Badwaikwrote: > > > Hi, > > > > I have read the dangers of mounting efivars as writable recently, and I > > think > > there should be an entry in the archlinux installation guide and beginner's > > guide which should say exactly what is said in the warning in [1], and then > > link to [1] for further instructions. > > > > The "dangers" are only if you do something dumb and your firmware is equally > dumb. Even then, hopefully the kernel will take care of it. > https://gist.github.com/mjg59/8d9d494da56fbe6d8992 Since when does "do something dumb" and "potentially hard brick your motherboard" become synonymous when speaking in terms of computers? There's doing something dumb (by accident or otherwise) and then there's bricking your motherboard, people make accidents all the time but since modern day computers are quite nice and rugged, the only losses are data losses. I might shed a few tears over the loss of some not-backed up data, but I would be quite a bit more pissed off if I lost a valuable and expensive piece of hardware (granted, it would have to have a misconfigured and shitty EFI, but since when is "being misconfigured and shitty" a rare occurance?). The newbies this change is aimed for are exactly the sorts of people who might unwittingly rm -rf /. -- Tomasz Kramkowski | GPG: 40B037BA0A5B8680 | Web: https://the-tk.com/ signature.asc Description: PGP signature
Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide
On February 1, 2016 11:57:01 AM EST, Jayesh Badwaikwrote: >Hi, > >I have read the dangers of mounting efivars as writable recently, and I >think >there should be an entry in the archlinux installation guide and >beginner's >guide which should say exactly what is said in the warning in [1], and >then >link to [1] for further instructions. Well, that's why it's a wiki. Make an account, then go ahead and make that change. --Sean
Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide
On Mon, 01 Feb 2016 22:27:01 +0530 Jayesh Badwaikwrote: > Hi, > > I have read the dangers of mounting efivars as writable recently, and I think > there should be an entry in the archlinux installation guide and beginner's > guide which should say exactly what is said in the warning in [1], and then > link to [1] for further instructions. > The "dangers" are only if you do something dumb and your firmware is equally dumb. Even then, hopefully the kernel will take care of it. https://gist.github.com/mjg59/8d9d494da56fbe6d8992
Re: [arch-general] pacman and hooks
Bruno Pagani writes: > Le 01/02/2016 23:05, Magnus Therning a écrit : >> I just noticed an email in this list mentioning that with pacman 5.0 we >> know have support for hooks. I proceeded to look at the man pages for >> /pacman/, /makepkg/, and /PKGBUILD/ but only found one mention of a >> /hookdir/. >> >> Is there more information about this feature available somewhere? >> >> /M > > They are some bits here: > https://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks > > I’m very interested in this feature, maybe I will be able to automate > very nicely the job of localepurge. Yes, I found that one. It just lacks an air of officialty about it ;) I'm hoping it can be used to limit the re-building of the documentation index for Haskell packages. /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay signature.asc Description: PGP signature
[arch-general] pacman and hooks
I just noticed an email in this list mentioning that with pacman 5.0 we know have support for hooks. I proceeded to look at the man pages for /pacman/, /makepkg/, and /PKGBUILD/ but only found one mention of a /hookdir/. Is there more information about this feature available somewhere? /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Do not meddle in the affairs of Wizards, for they are subtle and quick to anger. -- J.R.R Tolkien signature.asc Description: PGP signature
Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide
Am 01.02.2016 um 20:35 schrieb Tomasz Kramkowski: > The newbies this change is aimed for are exactly the sorts of people who > might unwittingly rm -rf /. Arch Linux is not aimed at newbies. There's been lots of panic over this issue, yet it took several years of UEFI being in the field for someone to actually trigger it. I guess it will be fixed in the kernel very soon. Until then we can calm down and start panicking - every local privilege escalation bug is worse than this stuff. signature.asc Description: OpenPGP digital signature
[arch-general] btrfs/snapper hook for pacman 5.0?
Hi all, now with hooks newly introduced to pacman, are there already some useful btrfs and/or snapper hooks available? At least a quick look-around in the forums and with Google hasn't revealed anything yet. Maybe I'm getting something wrong here, but in my understanding it should be doable and probably is even a cool feature that other distros / package managers already provide. Basically all we have to do is to create a snapshot before and after each pacman invocation. However, after having a look at the alpm-hooks(5) man page I'm not too sure what kind of trigger would make the most sense here. With the "recommended" btrfs / snapper subvolume layout, one could add triggers for paths that should be backed up (e.g. /, /var/, etc.). On the other hand the man page tells us that using the root directory as trigger path is not recommended. So has anyone already looked into this and has some thoughts on this? Best regards, Karol Babioch signature.asc Description: OpenPGP digital signature
Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide
Tomasz Kramkowski wrote: > Since when does "do something dumb" and "potentially hard brick your > motherboard" become synonymous when speaking in terms of computers? > > There's doing something dumb (by accident or otherwise) and then there's > bricking your motherboard, people make accidents all the time but since > modern day computers are quite nice and rugged, the only losses are data > losses. You would think that a modern day machine is nice and rugged, but with EFI/UEFI, it isn't. There are way too many moving gears involved. The preboot environment has one primary task: find a bootable medium and boot it. Ideally, you should be able to configure it to tell it which medium to boot from. In the absence of a bootable medium, it should throw an error. Simple! This is how things worked before EFI. Sure, getting an OS to load was a magic trick in the early days ("pulling oneself up by one's bootstraps"), but today it is a finely honed procedure. There is nothing broken with this procedure. (After all, it boots!) Enter EFI and UEFI. From my (somewhat limited) experience with EFI, it seems like whoever designed it attempted to solve some fringe problem while creating 5 more problems in its place. Why do OSes need to modify the boot order entries? Why do some motherboards refuse to fallback to legacy BIOS? To make things worse, many hardware implementations are buggy and cannot be fixed (because there are already thousands/millions of units in production). So, if you want a modern day computer to be rugged: * Use legacy BIOS. There is nothing wrong with it. * Mount efivars (and related stuff) as ro by default. I read the systemd bug [0], but I still don't understand why so many tools need to write to it. How often do you need to change motherboard parameters after you get an OS set up? At that point, POST should be "find a device and boot it". > I might shed a few tears over the loss of some not-backed up data, but I > would be quite a bit more pissed off if I lost a valuable and expensive > piece of hardware (granted, it would have to have a misconfigured and > shitty EFI, but since when is "being misconfigured and shitty" a rare > occurance?). I wish I could answer the philosophical question of whether rm should be able to brick hardware. I suggest someone mail Brian Kernighan, Robert Pike, or Ken Thompson. I would be really curious to hear what they think about this efivars thing. --Kyle [0]: https://github.com/systemd/systemd/issues/2402 signature.asc Description: OpenPGP digital signature
Re: [arch-general] pacman and hooks
On 01.02.2016 23:05, Magnus Therning wrote: > Is there more information about this feature available somewhere? $ man 5 alpm-hooks S
Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide
Maarten de Vries wrote: > On 1 February 2016 at 23:29, Leonid Isaev> wrote: > >> >> Also, how can you brick a machine by simply zeroing the harddrive? >> >> > You can't (well, someone can probably think of a contrived situation where > you could, there's always someone, but generally speaking). The problem is > with removing certain UEFI variables in buggy UEFI implementations (which > are all too common). But in this case (with buggy UEFI implementation) a > simple rm -rf of the wrong directory can brick your motherboard. > > -- Maarten Interesting sidenote: In Android, all the system-level stuff is segregated to /system, which is mounted as ro by default. This is just another layer of security. --Kyle signature.asc Description: OpenPGP digital signature
Re: [arch-general] pacman and hooks
Le 01/02/2016 23:05, Magnus Therning a écrit : > I just noticed an email in this list mentioning that with pacman 5.0 we > know have support for hooks. I proceeded to look at the man pages for > /pacman/, /makepkg/, and /PKGBUILD/ but only found one mention of a > /hookdir/. > > Is there more information about this feature available somewhere? > > /M They are some bits here: https://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks I’m very interested in this feature, maybe I will be able to automate very nicely the job of localepurge. Bruno signature.asc Description: OpenPGP digital signature
Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide
Sebastiaan Lokhorst wrote: > 2016-02-01 23:29 GMT+01:00 Leonid Isaev: > >> On Mon, Feb 01, 2016 at 01:40:54PM -0800, Kyle Terrien wrote: >>> Tomasz Kramkowski wrote: >>> * Use legacy BIOS. There is nothing wrong with it. >> Exactly, I really don't understand this interest to UEFI (and don't mention >> secureboot). >> > > Many new (OEM) machines do not support legacy BIOS. And this is what is so obnoxious/stupid about the whole situation. In their infinite wisdom, hardware manufacturers are writing broken implementations of an over-engineered system with no way to fallback to the tried/true system that has been around for decades. And when problems are discovered, it is too late. The systems are in production, and it is much easier to blame the consumer for uninstalling Windows than to admit there are millions of buggy boards in the wild. I really hope some sanity will return to the world of pre-boot. --Kyle signature.asc Description: OpenPGP digital signature
Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide
2016-02-01 23:29 GMT+01:00 Leonid Isaev: > On Mon, Feb 01, 2016 at 01:40:54PM -0800, Kyle Terrien wrote: > > Tomasz Kramkowski wrote: > > * Use legacy BIOS. There is nothing wrong with it. > Exactly, I really don't understand this interest to UEFI (and don't mention > secureboot). > Many new (OEM) machines do not support legacy BIOS.
Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide
On Mon, Feb 01, 2016 at 01:40:54PM -0800, Kyle Terrien wrote: > Tomasz Kramkowski wrote: > > Since when does "do something dumb" and "potentially hard brick your > > motherboard" become synonymous when speaking in terms of computers? > > > > There's doing something dumb (by accident or otherwise) and then there's > > bricking your motherboard, people make accidents all the time but since > > modern day computers are quite nice and rugged, the only losses are data > > losses. > * Use legacy BIOS. There is nothing wrong with it. Exactly, I really don't understand this interest to UEFI (and don't mention secureboot). Also, how can you brick a machine by simply zeroing the harddrive? Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Re: [arch-general] btrfs/snapper hook for pacman 5.0?
On Mon, Feb 01, 2016 at 10:21:04PM +0100, Karol Babioch wrote: > Hi all, > > now with hooks newly introduced to pacman, are there already some useful > btrfs and/or snapper hooks available? At least a quick look-around in > the forums and with Google hasn't revealed anything yet. What is the goal here? Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide
On 1 February 2016 at 23:29, Leonid Isaevwrote: > > Also, how can you brick a machine by simply zeroing the harddrive? > > You can't (well, someone can probably think of a contrived situation where you could, there's always someone, but generally speaking). The problem is with removing certain UEFI variables in buggy UEFI implementations (which are all too common). But in this case (with buggy UEFI implementation) a simple rm -rf of the wrong directory can brick your motherboard. -- Maarten
Re: [arch-general] btrfs/snapper hook for pacman 5.0?
Hi, Am 01.02.2016 um 23:30 schrieb Leonid Isaev: > On Mon, Feb 01, 2016 at 10:21:04PM +0100, Karol Babioch wrote: >> Hi all, >> >> now with hooks newly introduced to pacman, are there already some useful >> btrfs and/or snapper hooks available? At least a quick look-around in >> the forums and with Google hasn't revealed anything yet. > > What is the goal here? To have snapshots before and after pacman did any changes to the filesystem (i.e. upgraded packages), so one can easily rollback to a known good state in case of an error, and/or look at the difference between two snapshots to figure out what might cause an issue. You can find more information on snapper here [1]. There are appropriate hooks for aptitude and YaST, so I'm now looking into getting this functionality with Arch. Best regards, Karol Babioch [1]: http://snapper.io/ signature.asc Description: OpenPGP digital signature
Re: [arch-general] btrfs/snapper hook for pacman 5.0?
On 02/02/16 at 12:16am, Karol Babioch wrote: > Hi, > > Am 01.02.2016 um 23:30 schrieb Leonid Isaev: > > On Mon, Feb 01, 2016 at 10:21:04PM +0100, Karol Babioch wrote: > >> Hi all, > >> > >> now with hooks newly introduced to pacman, are there already some useful > >> btrfs and/or snapper hooks available? At least a quick look-around in > >> the forums and with Google hasn't revealed anything yet. > > > > What is the goal here? > > To have snapshots before and after pacman did any changes to the > filesystem (i.e. upgraded packages), so one can easily rollback to a > known good state in case of an error, and/or look at the difference > between two snapshots to figure out what might cause an issue. > > You can find more information on snapper here [1]. There are appropriate > hooks for aptitude and YaST, so I'm now looking into getting this > functionality with Arch. > > Best regards, > Karol Babioch > > [1]: http://snapper.io/ https://github.com/andrewgregory/pachooks apg
Re: [arch-general] opinion request about Firefox add-ons
On 01/31/2016 01:32 PM, Sebastiaan Lokhorst wrote: > I think everyone is missing the point: the firefox-adblock-plus package[1] > is broken since it does not work with the latest version of Firefox. > It should probably be dropped from the repositories. I've opened a bug > report.[1] > > [1] https://bugs.archlinux.org/task/47970 > See: https://bugs.archlinux.org/task/47395#comment143383 The current package is downloading the extension from the wrong location. -- Eli Schwartz
Re: [arch-general] opinion request about Firefox add-ons
On 01/31/2016 11:52 AM, Jonathan Roemer wrote: > On Sun, 2016-01-31 at 11:45 -0500, Francis Gerund wrote: >> is there a better idea? >> Any opinions? > > uBlock Origin > https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/ > Way to go on not answering the question in any way, shape, or form... -- Eli Schwartz
Re: [arch-general] opinion request about Firefox add-ons
Mon, 1 Feb 2016 09:46:33 -0500 Jonathan Roemer: > On Mon, Feb 01, 2016 at 01:52:03AM -0500, Eli Schwartz wrote: > > Way to go on not answering the question in any way, shape, or form... > > uBlock Origin [blurp] Again, this thread is not a discussion about add-ons, but what to do about Mozilla's new policy of enforcing signing and how it affects seperately packaged add-ons. I won't collect all the relevant links again. --byte pgpb2Z9FMBmFm.pgp Description: Digitale Signatur von OpenPGP
[arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide
Hi, I have read the dangers of mounting efivars as writable recently, and I think there should be an entry in the archlinux installation guide and beginner's guide which should say exactly what is said in the warning in [1], and then link to [1] for further instructions. -- Cheers Jayesh Badwaik [1] https://wiki.archlinux.org/index.php/ Unified_Extensible_Firmware_Interface#Mount_efivarfs
Re: [arch-general] Chromium Favorites Bar Partially Inoperative
On 2016-01-31 18:11:24, Dutch Ingraham wrote: > (...) confirm chrome on awesome "right" (or 2ndary) monitor problems: This is an awesome + multi-monitor + chromium problem, not your graphics driver. folders in the bookmark bar do not track "pressed" status or track the mouse at all. I believe it's more of awesome + some dirty stuff chromium does that it gets away in most other window managers because those aren't as awesome as awesome is awesome. I have observed this for at least half a year now, on different machines, always chromium (or google-chrome) + awesome + multimonitor setup + using the "secondary" monitor. Another thing is that chrome likes to draw itself a couple pixes left and right of where it actually is so at times snaps into the wrong screen in awesome. Less awesome WMs will probably cover this chromium bug as well. Just like the scum browser at times wants to draw its own window decoration or implement its own window movement (drag the title bar) ignoring the WM. It's not surprising chromium gets it wrong, these devs are out of their native area of expertise when doing WM-level stuff and I hope one day they'll learn to leave their fingers off it. Regards, -Martin
Re: [arch-general] opinion request about Firefox add-ons
On Mon, Feb 01, 2016 at 01:52:03AM -0500, Eli Schwartz wrote: > Way to go on not answering the question in any way, shape, or form... uBlock Origin is a less resource intensive, more thorough solution than Adblock Plus. The relevant performance statistics are below. https://github.com/gorhill/uBlock#performance https://github.com/gorhill/uBlock/wiki/uBlock-vs.-ABP:-efficiency-compared Additionally, it contains none of the "acceptable ads" whitelisting that Adblock Plus has added, and provides more privacy-protecting features, if those are important. As the user's current Adblock Plus solution is broken, and they specifically asked for other opinions or options, I figured I would offer them an objectively better adblocking experience within Firefox. Both a release and developer version of uBlock Origin are signed and available on the Firefox addons site.
Re: [arch-general] opinion request about Firefox add-ons
On 02/01/2016 09:46 AM, Jonathan Roemer wrote: > On Mon, Feb 01, 2016 at 01:52:03AM -0500, Eli Schwartz wrote: >> Way to go on not answering the question in any way, shape, or form... > > uBlock Origin [random screed follows] > > As the user's current Adblock Plus solution is broken, and they > specifically asked for other opinions or options, I figured I would > offer them an objectively better adblocking experience within Firefox. > Both a release and developer version of uBlock Origin are signed and > available on the Firefox addons site. > So I guess you really didn't read the user's post after all. Or you would have noticed the part where he explicitly stated that Adblock Plus works fine. In fact, Adblock Plus too has both Release and Developer versions signed and available on the Firefox addons site. What the user was talking about, is the firefox-adblock-plus package from the Arch Linux community repos. Which doesn't work, on account of not being from the Firefox addons site and thus not being signed. A problem which is already reported on the Arch Linux bugtracker (with a fix). Thus answering the user's question of "should I use the Arch Linux package or simply install Adblock Plus from the Firefox addons website". Thank you for your recommendation to install the firefox-ublock-origin package as a replacement (or interim solution), unfortunately, I ran into some trouble doing so, as there is no such thing... -- Eli Schwartz
Re: [arch-general] btrfs/snapper hook for pacman 5.0?
Hi, On Tue, Feb 02, 2016 at 12:16:53AM +0100, Karol Babioch wrote: > > What is the goal here? > > To have snapshots before and after pacman did any changes to the > filesystem (i.e. upgraded packages), so one can easily rollback to a > known good state in case of an error, and/or look at the difference > between two snapshots to figure out what might cause an issue. > > You can find more information on snapper here [1]. There are appropriate > hooks for aptitude and YaST, so I'm now looking into getting this > functionality with Arch. Thanks. But /boot can not be snapshot with this, right? Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide
On Mon, 1 Feb 2016 19:35:35 + Tomasz Kramkowskiwrote: > On Mon, Feb 01, 2016 at 11:11:14AM -0600, Doug Newgard wrote: > > On Mon, 01 Feb 2016 22:27:01 +0530 > > Jayesh Badwaik wrote: > > > > > Hi, > > > > > > I have read the dangers of mounting efivars as writable recently, and I > > > think > > > there should be an entry in the archlinux installation guide and > > > beginner's > > > guide which should say exactly what is said in the warning in [1], and > > > then > > > link to [1] for further instructions. > > > > > > > The "dangers" are only if you do something dumb and your firmware is equally > > dumb. Even then, hopefully the kernel will take care of it. > > https://gist.github.com/mjg59/8d9d494da56fbe6d8992 > > Since when does "do something dumb" and "potentially hard brick your > motherboard" become synonymous when speaking in terms of computers? I never said it shouldn't be dealt with, I'm just saying all of the coverage is really overblown. It's a very obscure set of circumstances that leads to this, and it appears will be handled in the kernel. Let's move on now.
Re: [arch-general] Chromium Favorites Bar Partially Inoperative
On Mon, Feb 01, 2016 at 11:34:37AM +0100, Martin S. Weber wrote: > On 2016-01-31 18:11:24, Dutch Ingraham wrote: > > (...) > > confirm chrome on awesome "right" (or 2ndary) monitor problems: This is > an awesome + multi-monitor + chromium problem, not your graphics driver. > > folders in the bookmark bar do not track "pressed" status or track the > mouse at all. > > I believe it's more of awesome + some dirty stuff chromium does that it > gets away in most other window managers because those aren't as awesome > as awesome is awesome. > Thanks, Martin, for the confirmation. I now also now agree that the source of the problem is likely not the driver but "an awesome + multi-monitor + chromium problem." I've had the chance to set up a similar situation on a different computer running OpenBSD, which uses a different driver and the problem exists there as well.