Re: [arch-general] No login after update
On Fri, Aug 21, 2020 at 10:28:58PM +0200, Manuel Reimer wrote:
> On 21.08.20 22:23, Manuel Reimer wrote:
> > A diff between the actuall file and its ".pacnew":
> >
> >
> > $ diff -U 8 -p 00-dns.sh 00-dns.sh.pacnew
> > --- 00-dns.sh 2013-05-30 19:35:30.0 +0200
> > +++ 00-dns.sh.pacnew 2020-02-20 22:37:04.0 +0100
> > @@ -1,7 +1,11 @@
> > #!/bin/sh
> >
> > if [ "$USEPEERDNS" = "1" -a -f /etc/ppp/resolv.conf ]; then
> > - [ -e /etc/resolv.conf ] && mv /etc/resolv.conf
> > /etc/resolv.conf.backup.${IFNAME}
> > - mv /etc/ppp/resolv.conf /etc/resolv.conf
> > - chmod 644 /etc/resolv.conf
> > + if [ -x /usr/bin/resolvconf ]; then
> > + /usr/bin/resolvconf -a ${IFNAME} > + else
> > + [ -e /etc/resolv.conf ] && mv /etc/resolv.conf
> > /etc/resolv.conf.backup.${IFNAME}
> > + mv /etc/ppp/resolv.conf /etc/resolv.conf
> > + chmod 644 /etc/resolv.conf
> > + fi
> > fi
>
> And here the dates of the files:
>
>
> $ ls -lh
> total 8,0K
> -rwxr-xr-x 1 root root 229 30. Mai 2013 00-dns.sh
> -rwxr-xr-x 1 root root 344 20. Feb 2020 00-dns.sh.pacnew
>
>
> So when copying over from HDD to SSD I seem to have taken care of keeping
> the filestamps as I did not have my SSD in year 2013.
>
> If pacman had a bug in the past which did not properly move .pacnew into
> place (or maybe the "move into place feature" came some time later). Could a
> existing ".pacnew", created from older pacman versions, cause issues here?
>
> This is a pretty old Arch install. Never reinstalled. Always just updated.
> The oldest date I could find is August 2012.
>
> Manuel
This isn't a bug, it's however concerning that you haven't read the output of
pacman for 7 years and left .pacnew files unresolved.
https://github.com/archlinux/svntogit-packages/commit/c57cbb700c8b9e8ccfdc8c522e55ec1f80508462
As you can see, the files has been missing from the backup array thus pacman was
not aware of it. It does what it's suppose to do and preserves it's old file and
stores the new files as `.pacnew`.
This is documented in the manpage:
https://www.archlinux.org/pacman/pacman.8.html#_handling_config_files_a_id_hcf_a
--
Morten Linderud
PGP: 9C02FF419FECBE16
signature.asc
Description: PGP signature
Re: [arch-general] No login after update
On 21.08.20 22:23, Manuel Reimer wrote:
A diff between the actuall file and its ".pacnew":
$ diff -U 8 -p 00-dns.sh 00-dns.sh.pacnew
--- 00-dns.sh 2013-05-30 19:35:30.0 +0200
+++ 00-dns.sh.pacnew 2020-02-20 22:37:04.0 +0100
@@ -1,7 +1,11 @@
#!/bin/sh
if [ "$USEPEERDNS" = "1" -a -f /etc/ppp/resolv.conf ]; then
- [ -e /etc/resolv.conf ] && mv /etc/resolv.conf
/etc/resolv.conf.backup.${IFNAME}
- mv /etc/ppp/resolv.conf /etc/resolv.conf
- chmod 644 /etc/resolv.conf
+ if [ -x /usr/bin/resolvconf ]; then
+ /usr/bin/resolvconf -a ${IFNAME} + [ -e /etc/resolv.conf ] && mv /etc/resolv.conf
/etc/resolv.conf.backup.${IFNAME}
+ mv /etc/ppp/resolv.conf /etc/resolv.conf
+ chmod 644 /etc/resolv.conf
+ fi
fi
And here the dates of the files:
$ ls -lh
total 8,0K
-rwxr-xr-x 1 root root 229 30. Mai 2013 00-dns.sh
-rwxr-xr-x 1 root root 344 20. Feb 2020 00-dns.sh.pacnew
So when copying over from HDD to SSD I seem to have taken care of
keeping the filestamps as I did not have my SSD in year 2013.
If pacman had a bug in the past which did not properly move .pacnew into
place (or maybe the "move into place feature" came some time later).
Could a existing ".pacnew", created from older pacman versions, cause
issues here?
This is a pretty old Arch install. Never reinstalled. Always just
updated. The oldest date I could find is August 2012.
Manuel
Re: [arch-general] No login after update
On 21.08.20 22:09, Morten Linderud via arch-general wrote:
There are more ".pacnew" in my /etc. All for files that I never touched
myself.
That is concerning, but it is simply something touching those files you are
unaware of. It's however you system and it's expected that you are aware of what
does this.
I don't know what this could be. What exactly is compared? File
timestamps? Checksums? How to debug this?
For example I have a /etc/ppp/ip-up.d/00-dns.sh.pacnew
I for sure never edited this. I don't care about ppp at all. This
package came as dependency of something else (maybe NetworkManger).
A diff between the actuall file and its ".pacnew":
$ diff -U 8 -p 00-dns.sh 00-dns.sh.pacnew
--- 00-dns.sh 2013-05-30 19:35:30.0 +0200
+++ 00-dns.sh.pacnew2020-02-20 22:37:04.0 +0100
@@ -1,7 +1,11 @@
#!/bin/sh
if [ "$USEPEERDNS" = "1" -a -f /etc/ppp/resolv.conf ]; then
- [ -e /etc/resolv.conf ] && mv /etc/resolv.conf
/etc/resolv.conf.backup.${IFNAME}
- mv /etc/ppp/resolv.conf /etc/resolv.conf
- chmod 644 /etc/resolv.conf
+ if [ -x /usr/bin/resolvconf ]; then
+/usr/bin/resolvconf -a ${IFNAME} +[ -e /etc/resolv.conf ] && mv /etc/resolv.conf
/etc/resolv.conf.backup.${IFNAME}
+mv /etc/ppp/resolv.conf /etc/resolv.conf
+chmod 644 /etc/resolv.conf
+ fi
fi
I guess there is something wrong with the way how pacman decides when to move
".pacnew" into place directly.
There isn't. Peopel with `.pacnew` has modified their files, wittingly or not.
For sure not. I guess it somehow also depends on how they are compared.
At some point in the past I replaced my HDD with an SSD and as far as I
remember I copied over the system. Could this have caused the way how
pacman decides when to move ".pacnew" into place somehow?
I may also have deleted the whole /var/cache/pacman/pkg at some point in
the past to save space. Is this where pacman checks for "old files"?
Manuel
Re: [arch-general] No login after update
On Fri, Aug 21, 2020 at 10:01:50PM +0200, Manuel Reimer wrote: > There have to be edge cases where the replacement does not happen even if I > never touched a file myself. But I don't know how to debug this. No, you are mistaken. There are two issues, which is quite apparent if you do read the bugreports. 1) People modifying /etc/pam.d files and promptly forgetting it. Breaking their system as the new file is inserted as `/etc/pam.d/system-login.pacnew`. 2) Some change introduced into the new /etc/pam.d/system-login where auxillary files such as ~/.pam_environment can sometimes break your system. I have no clue how the latter works. > There are more ".pacnew" in my /etc. All for files that I never touched > myself. That is concerning, but it is simply something touching those files you are unaware of. It's however you system and it's expected that you are aware of what does this. > I guess there is something wrong with the way how pacman decides when to move > ".pacnew" into place directly. There isn't. Peopel with `.pacnew` has modified their files, wittingly or not. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-general] No login after update
There have to be edge cases where the replacement does not happen even if I never touched a file myself. But I don't know how to debug this. There are more ".pacnew" in my /etc. All for files that I never touched myself. And about the "system-login"-thing: I'm not the only one who had this problem: https://www.reddit.com/r/archlinux/comments/id6tem/cant_login_as_user_or_root_after_upgrade/ https://www.reddit.com/r/archlinux/comments/ie3i8d/super_weird_login_problem/ https://www.reddit.com/r/archlinux/comments/idjpw3/issues_with_pam_tally2_after_full_system_upgrade/ https://www.reddit.com/r/archlinux/comments/iczyr0/psa_be_careful_with_pacnew_when_updating/ https://www.reddit.com/r/archlinux/comments/id3dsu/unable_to_login_after_upgrade/ https://www.reddit.com/r/archlinux/comments/id6ce4/not_able_to_login_after_updating_pam_to_1403/ https://www.reddit.com/r/archlinux/comments/icnzrx/after_latest_update_my_computer_cant_login/ https://www.reddit.com/r/archlinux/comments/icr4sv/incorrect_login_with_correct_password_even_reset/ And maybe more. I guess there is something wrong with the way how pacman decides when to move ".pacnew" into place directly. And I'm wondering how many users actually got lost with this issue of not being able to log in after updating and just wiped Arch off their hard drive... :( IMHO something should be done to at least find out why pacman does not replace *non user modified* files in some cases... Manuel On 19.08.20 21:07, Josef Miegl wrote: This can only happen if you or another program modified the original file. Josef Miegl On August 19, 2020 9:02:12 PM GMT+02:00, Manuel Reimer wrote: Hello, I know that Arch is not for the "average user" and some background knowledge is expected, but this was the first time I needed a boot stick since I think at least one year. Some minutes ago I did a regular system update and after that decided to reboot. After reboot I was unable to log into my system. After fiddling a bit I rebooted to an Arch boot stick to find the following message in pacman.log: [2020-08-19T20:42:55+0200] [ALPM] warning: /etc/pam.d/system-login installed as /etc/pam.d/system-login.pacnew As this seemed to be a candidate that may cause login problems, I deleted "system-login" and moved the ".pacnew" into place. After reboot I'm now able to log in again... IMHO something like this should not happen... Maybe it's worth a note on the Arch homepage that it is important to move this pacnew into place before reboot? Manuel
Re: [arch-general] No login after update
On 8/20/20 3:52 PM, Damjan Georgievski via arch-general wrote: > Now I don't understand all the defensiveness - let's all work together > to improve things. This is not a non-issue. That's the Arch I fondly remember. You are on this list either because (1) you want to help, or (2) you need help. Both are best accomplished with courtesy and civility and nothing more. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] No login after update
> I don't see what all the fuss is about > > If you're using Arch, then you should: > > 1. Check Arch news before running update > 2. Update regularly > 3. Watch output from pacman for warnings/advice > 4. Run pacdiff after update and before reboot > > After step 4 there are no longer any pacnew files That would have shown that the new file doesn't have pam_tally2, it wont say you wouldn't be able to login after reboot. actually, even assuming you would know to fix the issue, but you didn't fix the problem immediately and you went to make a coffee - your screen saver was activated, you are locked out. Now I don't understand all the defensiveness - let's all work together to improve things. This is not a non-issue. -- damjan
Re: [arch-general] No login after update
On Thu, 20 Aug 2020 at 07:10, Kusoneko wrote: > > I think he's trying to imply that pacman stores a copy of the archive > containing the previous version somewhere and that pacman should extract > the config files from both and see if something changed before providing a > .pacnew. Only thing is, that would cost much more storage space than if one > lazily ignored and let the pacnew files be wherever they're placed. In > other words, not really a good idea unless you have tons of storage space. > I guess you could theoretically patch pacman to do so for yourself if you > really wanted to, but for most people it wouldn't be worth it. I don't see what all the fuss is about If you're using Arch, then you should: 1. Check Arch news before running update 2. Update regularly 3. Watch output from pacman for warnings/advice 4. Run pacdiff after update and before reboot After step 4 there are no longer any pacnew files
Re: [arch-general] No login after update
On 8/19/20 15:02, Manuel Reimer wrote: > Hello, > > I know that Arch is not for the "average user" and some background > knowledge is expected, but this was the first time I needed a boot stick > since I think at least one year. > > Some minutes ago I did a regular system update and after that decided to > reboot. After reboot I was unable to log into my system. After fiddling > a bit I rebooted to an Arch boot stick to find the following message in > pacman.log: > > [2020-08-19T20:42:55+0200] [ALPM] warning: /etc/pam.d/system-login > installed as > /etc/pam.d/system-login.pacnew > > As this seemed to be a candidate that may cause login problems, I > deleted "system-login" and moved the ".pacnew" into place. > > After reboot I'm now able to log in again... > > IMHO something like this should not happen... > > Maybe it's worth a note on the Arch homepage that it is important to > move this pacnew into place before reboot? > > Manuel I'm just going to reiterate some things, and offer a solution that would have saved you this headache, and then I'm ignoring this thread as it's tiresome. 1.) .pacnew files shouldn't be ignored. They are only created if *you* (or a mispackaged software) have modified files provided by a package from their default state. 2.) True of anything, really, but don't modify PAM files unless you have a significant understanding to a complete grok of what you're doing. 3.) This isn't a news item, as it's isolated to your particular install and customizations. As for the solution, https://aur.archlinux.org/packages/etc-update/ Ta-da. There are other packages that do similar things. You could even have it run automatically after certain packages update with a hook[0]. By running that after your -Sy and before the reboot, you'd see that the line present in your configuration is not part of the default managed by pacman/the package, with the option to: - remove it (effectively reverting to the default file as provided by the package) - merge it with the new one - interactively edit etc. It even cleans up .pacnew files for you after you've made your decisions. You now have no excuse to have .pacnew files all over nor to have changes that are incompatible with new software (provided you read the software's release notes to see if the deprecated, renamed, etc. a configuration in the new version). [0] https://jlk.fjfi.cvut.cz/arch/manpages/man/alpm-hooks.5 -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] No login after update
Le 20/08/2020 à 10:08, Kusoneko a écrit : > On August 19, 2020 8:16:08 PM UTC, Giancarlo Razzolini via arch-general > wrote: >> Em agosto 19, 2020 17:04 Yaro Kasear escreveu: >>> Yes there is. The defaults are literally what's in the config file in >>> the archive and not on the filesystem. How would that not be a way to >>> determine default settings? >>> >>> I'm not suggesting the package manager would have to understand the >>> settings, but it would be able to tell if the contents of that file >> are >>> different from another version. (Which it obviously does already, >>> otherwise it wouldn't know to make a pacnew file.) >>> >>> I can't imagine it'd be that difficult for pacman to compare >> checksums >>> between files in /etc or /boot between versions of a package (If a >>> previous version is available.) and what's on /etc and determine if >> it >>> really needs to bother putting a pacnew file on the filesystem that >>> doesn't need to be there. It's already doing some sort of check >> between >>> what's in the package and what's on the filesystem already. >>> >> How is everything you just said, different than what pacman already >> does? >> How would it determine not to create a .pacnew? If you can answer both >> these >> questions, I'd encourage you to send patches to pacman. Because I >> couldn't >> understand how what you said is any different than the current pacnew >> logic. >> >> Regards, >> Giancarlo Razzolini > I think he's trying to imply that pacman stores a copy of the archive > containing the previous version somewhere and that pacman should extract the > config files from both and see if something changed before providing a > .pacnew. Only thing is, that would cost much more storage space than if one > lazily ignored and let the pacnew files be wherever they're placed. In other > words, not really a good idea unless you have tons of storage space. I guess > you could theoretically patch pacman to do so for yourself if you really > wanted to, but for most people it wouldn't be worth it. Please read the remaining of the thread you’re replying to before posting. ;) This has already been addressed, and pacman actually does this (using hashes as to not waste storage space). Bruno/Archange
Re: [arch-general] No login after update
On August 19, 2020 8:16:08 PM UTC, Giancarlo Razzolini via arch-general wrote: >Em agosto 19, 2020 17:04 Yaro Kasear escreveu: >> >> Yes there is. The defaults are literally what's in the config file in >> the archive and not on the filesystem. How would that not be a way to >> determine default settings? >> >> I'm not suggesting the package manager would have to understand the >> settings, but it would be able to tell if the contents of that file >are >> different from another version. (Which it obviously does already, >> otherwise it wouldn't know to make a pacnew file.) >> >> I can't imagine it'd be that difficult for pacman to compare >checksums >> between files in /etc or /boot between versions of a package (If a >> previous version is available.) and what's on /etc and determine if >it >> really needs to bother putting a pacnew file on the filesystem that >> doesn't need to be there. It's already doing some sort of check >between >> what's in the package and what's on the filesystem already. >> > >How is everything you just said, different than what pacman already >does? >How would it determine not to create a .pacnew? If you can answer both >these >questions, I'd encourage you to send patches to pacman. Because I >couldn't >understand how what you said is any different than the current pacnew >logic. > >Regards, >Giancarlo Razzolini I think he's trying to imply that pacman stores a copy of the archive containing the previous version somewhere and that pacman should extract the config files from both and see if something changed before providing a .pacnew. Only thing is, that would cost much more storage space than if one lazily ignored and let the pacnew files be wherever they're placed. In other words, not really a good idea unless you have tons of storage space. I guess you could theoretically patch pacman to do so for yourself if you really wanted to, but for most people it wouldn't be worth it. signature.asc Description: PGP signature
Re: [arch-general] No login after update
On 8/19/20 3:41 PM, Morten Linderud via arch-general wrote: > https://www.archlinux.org/pacman/pacman.8.html#_handling_config_files_a_id_hcf_a > > Can you please read this section a few times before writing more emails? > I see. I was sure pacman made no comparisons at all to previous config versions, just what is on the filesystem now and what's new. Sorry about that, I was wrong. Yaro signature.asc Description: OpenPGP digital signature
Re: [arch-general] No login after update
https://www.archlinux.org/pacman/pacman.8.html#_handling_config_files_a_id_hcf_a Can you please read this section a few times before writing more emails? -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-general] No login after update
On Wed, Aug 19, 2020 at 3:32 PM Yaro Kasear wrote: > On Wed, Aug 19, 2020 at 3:17 PM Archange wrote: > >> >> Le 20/08/2020 à 00:04, Yaro Kasear a écrit : >> > On 8/19/20 2:56 PM, Yaro Kasear wrote: >> >> On 8/19/20 2:48 PM, Giancarlo Razzolini via arch-general wrote: >> >>> Em agosto 19, 2020 16:37 Yaro Kasear escreveu: >> I've always questioned the wisdom of dropping a .pacnew just when the >> file is different from the default. There's really no reason for it >> considering any changes you made were deliberate and presumably >> thought >> out. The end result is pacman cluttering /etc with a default >> configuration file whose only reason for existing is to, if it's >> used, >> clear settings. Why? >> >> >>> The .pacnew is there to indicate that something new exists, or that >> >>> you changed >> >>> something. Most of the time you can remove .pacnew files, but not >> >>> always. Also, >> >>> it's only "cluttering" /etc (and /boot, btw), if you don't handle >> them. >> >>> >> What pacman SHOULD do is compare /etc files between package versions >> and >> see if there's a change BETWEEN DEFAULTS. *Then* there's an actual >> reason to need a new default config file for the user to examine >> because >> then there's an actual indicator some meaningful change in default >> configuration or how the package handles configs happened. >> >> >>> That's way beyond the scope of a package manager, and also, there's no >> >>> way >> >>> to tell what "DEFAULTS" (why caps?) should be. >> >> Caps for emphasis is all. >> All most pacnew files wind up doing is sitting there for thirty >> seconds >> before being deleted without anyone even opening them because they're >> literally just what the file was before the user ALREADY changed it >> before... because it's utterly useless to get a default config file >> when >> you've intentionally changed it and there's nothing in the new >> version >> of the package that calls for an examination of the defaults. >> >> >>> I don't know why you said that .pacnew sits for thirty seconds before >> >>> being >> >>> deleted. Are you using a hook that does this? Because nothing handles >> >>> them >> >>> automatically, that's the user's job. There are tools to aid in doing >> >>> that, >> >>> but in the end the user should know what to apply, and what to >> discard. >> >> I wasn't being literal about thirty seconds. Exaggerating. >> >>> Regards, >> >>> Giancarlo Razzolini >> >> Yaro >> >> >> >> >> > Oh, also: >> > >> > "That's way beyond the scope of a package manager, and also, there's no >> > way to tell what "DEFAULTS" (why caps?) should be." >> > >> > Yes there is. The defaults are literally what's in the config file in >> > the archive and not on the filesystem. How would that not be a way to >> > determine default settings? >> > >> > I'm not suggesting the package manager would have to understand the >> > settings, but it would be able to tell if the contents of that file are >> > different from another version. (Which it obviously does already, >> > otherwise it wouldn't know to make a pacnew file.) >> > >> > I can't imagine it'd be that difficult for pacman to compare checksums >> > between files in /etc or /boot between versions of a package (If a >> > previous version is available.) and what's on /etc and determine if it >> > really needs to bother putting a pacnew file on the filesystem that >> > doesn't need to be there. It's already doing some sort of check between >> > what's in the package and what's on the filesystem already. >> > >> > Yaro >> >> pacman does this: if the *packaged file* changed between the installed >> version and the new one, and the *installed file* is different from the >> *packaged file*, then drop a .pacnew. >> >> I’m not sure what you want more… >> >> Bruno/Archange >> > > But that is not what I am talking about. > > I'm discussing what is essentially three configuration files here: > > - The config in old-package. > - The config in new-package. > - The config on the filesystem. > > I already know pacman compares new-package and filesystem config. It does > NOT do any check between old-package and new-package. > > What I'm saying is a pacnew seems unnecessary if the file between > old-package and new-package are the same, because it means there's > absolutely nothing of use to the user there, as either the user's made > changes themselves and thus that file from the package is just going to be > settings they don't want, or it's never been changed, in which case > extracting the file's entirely redundant as it's literally still the same > file. Pacman wouldn't do a pacnew in that case as it's implemented so > that's beside the point. > > I'm not talking about the existing new-package to filesystem version > checks, I'm talking about a case where if a package upgrade doesn't bring a > new configuration change, the pacnew's just a waste of time and spa
Re: [arch-general] No login after update
On Wed, Aug 19, 2020 at 3:17 PM Archange wrote: > > Le 20/08/2020 à 00:04, Yaro Kasear a écrit : > > On 8/19/20 2:56 PM, Yaro Kasear wrote: > >> On 8/19/20 2:48 PM, Giancarlo Razzolini via arch-general wrote: > >>> Em agosto 19, 2020 16:37 Yaro Kasear escreveu: > I've always questioned the wisdom of dropping a .pacnew just when the > file is different from the default. There's really no reason for it > considering any changes you made were deliberate and presumably > thought > out. The end result is pacman cluttering /etc with a default > configuration file whose only reason for existing is to, if it's used, > clear settings. Why? > > >>> The .pacnew is there to indicate that something new exists, or that > >>> you changed > >>> something. Most of the time you can remove .pacnew files, but not > >>> always. Also, > >>> it's only "cluttering" /etc (and /boot, btw), if you don't handle them. > >>> > What pacman SHOULD do is compare /etc files between package versions > and > see if there's a change BETWEEN DEFAULTS. *Then* there's an actual > reason to need a new default config file for the user to examine > because > then there's an actual indicator some meaningful change in default > configuration or how the package handles configs happened. > > >>> That's way beyond the scope of a package manager, and also, there's no > >>> way > >>> to tell what "DEFAULTS" (why caps?) should be. > >> Caps for emphasis is all. > All most pacnew files wind up doing is sitting there for thirty > seconds > before being deleted without anyone even opening them because they're > literally just what the file was before the user ALREADY changed it > before... because it's utterly useless to get a default config file > when > you've intentionally changed it and there's nothing in the new version > of the package that calls for an examination of the defaults. > > >>> I don't know why you said that .pacnew sits for thirty seconds before > >>> being > >>> deleted. Are you using a hook that does this? Because nothing handles > >>> them > >>> automatically, that's the user's job. There are tools to aid in doing > >>> that, > >>> but in the end the user should know what to apply, and what to discard. > >> I wasn't being literal about thirty seconds. Exaggerating. > >>> Regards, > >>> Giancarlo Razzolini > >> Yaro > >> > >> > > Oh, also: > > > > "That's way beyond the scope of a package manager, and also, there's no > > way to tell what "DEFAULTS" (why caps?) should be." > > > > Yes there is. The defaults are literally what's in the config file in > > the archive and not on the filesystem. How would that not be a way to > > determine default settings? > > > > I'm not suggesting the package manager would have to understand the > > settings, but it would be able to tell if the contents of that file are > > different from another version. (Which it obviously does already, > > otherwise it wouldn't know to make a pacnew file.) > > > > I can't imagine it'd be that difficult for pacman to compare checksums > > between files in /etc or /boot between versions of a package (If a > > previous version is available.) and what's on /etc and determine if it > > really needs to bother putting a pacnew file on the filesystem that > > doesn't need to be there. It's already doing some sort of check between > > what's in the package and what's on the filesystem already. > > > > Yaro > > pacman does this: if the *packaged file* changed between the installed > version and the new one, and the *installed file* is different from the > *packaged file*, then drop a .pacnew. > > I’m not sure what you want more… > > Bruno/Archange > But that is not what I am talking about. I'm discussing what is essentially three configuration files here: - The config in old-package. - The config in new-package. - The config on the filesystem. I already know pacman compares new-package and filesystem config. It does NOT do any check between old-package and new-package. What I'm saying is a pacnew seems unnecessary if the file between old-package and new-package are the same, because it means there's absolutely nothing of use to the user there, as either the user's made changes themselves and thus that file from the package is just going to be settings they don't want, or it's never been changed, in which case extracting the file's entirely redundant as it's literally still the same file. Pacman wouldn't do a pacnew in that case as it's implemented so that's beside the point. I'm not talking about the existing new-package to filesystem version checks, I'm talking about a case where if a package upgrade doesn't bring a new configuration change, the pacnew's just a waste of time and space (Albeit tiny amounts of space.) for the user. I'm suggesting pacman check not just between installed and new-package versions of the config but, if the old-package is still in the cache, tak
Re: [arch-general] No login after update
Le 20/08/2020 à 00:04, Yaro Kasear a écrit : > On 8/19/20 2:56 PM, Yaro Kasear wrote: >> On 8/19/20 2:48 PM, Giancarlo Razzolini via arch-general wrote: >>> Em agosto 19, 2020 16:37 Yaro Kasear escreveu: I've always questioned the wisdom of dropping a .pacnew just when the file is different from the default. There's really no reason for it considering any changes you made were deliberate and presumably thought out. The end result is pacman cluttering /etc with a default configuration file whose only reason for existing is to, if it's used, clear settings. Why? >>> The .pacnew is there to indicate that something new exists, or that >>> you changed >>> something. Most of the time you can remove .pacnew files, but not >>> always. Also, >>> it's only "cluttering" /etc (and /boot, btw), if you don't handle them. >>> What pacman SHOULD do is compare /etc files between package versions and see if there's a change BETWEEN DEFAULTS. *Then* there's an actual reason to need a new default config file for the user to examine because then there's an actual indicator some meaningful change in default configuration or how the package handles configs happened. >>> That's way beyond the scope of a package manager, and also, there's no >>> way >>> to tell what "DEFAULTS" (why caps?) should be. >> Caps for emphasis is all. All most pacnew files wind up doing is sitting there for thirty seconds before being deleted without anyone even opening them because they're literally just what the file was before the user ALREADY changed it before... because it's utterly useless to get a default config file when you've intentionally changed it and there's nothing in the new version of the package that calls for an examination of the defaults. >>> I don't know why you said that .pacnew sits for thirty seconds before >>> being >>> deleted. Are you using a hook that does this? Because nothing handles >>> them >>> automatically, that's the user's job. There are tools to aid in doing >>> that, >>> but in the end the user should know what to apply, and what to discard. >> I wasn't being literal about thirty seconds. Exaggerating. >>> Regards, >>> Giancarlo Razzolini >> Yaro >> >> > Oh, also: > > "That's way beyond the scope of a package manager, and also, there's no > way to tell what "DEFAULTS" (why caps?) should be." > > Yes there is. The defaults are literally what's in the config file in > the archive and not on the filesystem. How would that not be a way to > determine default settings? > > I'm not suggesting the package manager would have to understand the > settings, but it would be able to tell if the contents of that file are > different from another version. (Which it obviously does already, > otherwise it wouldn't know to make a pacnew file.) > > I can't imagine it'd be that difficult for pacman to compare checksums > between files in /etc or /boot between versions of a package (If a > previous version is available.) and what's on /etc and determine if it > really needs to bother putting a pacnew file on the filesystem that > doesn't need to be there. It's already doing some sort of check between > what's in the package and what's on the filesystem already. > > Yaro pacman does this: if the *packaged file* changed between the installed version and the new one, and the *installed file* is different from the *packaged file*, then drop a .pacnew. I’m not sure what you want more… Bruno/Archange
Re: [arch-general] No login after update
Em agosto 19, 2020 17:04 Yaro Kasear escreveu: Yes there is. The defaults are literally what's in the config file in the archive and not on the filesystem. How would that not be a way to determine default settings? I'm not suggesting the package manager would have to understand the settings, but it would be able to tell if the contents of that file are different from another version. (Which it obviously does already, otherwise it wouldn't know to make a pacnew file.) I can't imagine it'd be that difficult for pacman to compare checksums between files in /etc or /boot between versions of a package (If a previous version is available.) and what's on /etc and determine if it really needs to bother putting a pacnew file on the filesystem that doesn't need to be there. It's already doing some sort of check between what's in the package and what's on the filesystem already. How is everything you just said, different than what pacman already does? How would it determine not to create a .pacnew? If you can answer both these questions, I'd encourage you to send patches to pacman. Because I couldn't understand how what you said is any different than the current pacnew logic. Regards, Giancarlo Razzolini pgp4gjuokAph0.pgp Description: PGP signature
Re: [arch-general] No login after update
On 8/19/20 2:56 PM, Yaro Kasear wrote: > On 8/19/20 2:48 PM, Giancarlo Razzolini via arch-general wrote: >> Em agosto 19, 2020 16:37 Yaro Kasear escreveu: >>> I've always questioned the wisdom of dropping a .pacnew just when the >>> file is different from the default. There's really no reason for it >>> considering any changes you made were deliberate and presumably thought >>> out. The end result is pacman cluttering /etc with a default >>> configuration file whose only reason for existing is to, if it's used, >>> clear settings. Why? >>> >> The .pacnew is there to indicate that something new exists, or that >> you changed >> something. Most of the time you can remove .pacnew files, but not >> always. Also, >> it's only "cluttering" /etc (and /boot, btw), if you don't handle them. >> >>> What pacman SHOULD do is compare /etc files between package versions and >>> see if there's a change BETWEEN DEFAULTS. *Then* there's an actual >>> reason to need a new default config file for the user to examine because >>> then there's an actual indicator some meaningful change in default >>> configuration or how the package handles configs happened. >>> >> That's way beyond the scope of a package manager, and also, there's no >> way >> to tell what "DEFAULTS" (why caps?) should be. > Caps for emphasis is all. >>> All most pacnew files wind up doing is sitting there for thirty seconds >>> before being deleted without anyone even opening them because they're >>> literally just what the file was before the user ALREADY changed it >>> before... because it's utterly useless to get a default config file when >>> you've intentionally changed it and there's nothing in the new version >>> of the package that calls for an examination of the defaults. >>> >> I don't know why you said that .pacnew sits for thirty seconds before >> being >> deleted. Are you using a hook that does this? Because nothing handles >> them >> automatically, that's the user's job. There are tools to aid in doing >> that, >> but in the end the user should know what to apply, and what to discard. > I wasn't being literal about thirty seconds. Exaggerating. >> Regards, >> Giancarlo Razzolini > Yaro > > Oh, also: "That's way beyond the scope of a package manager, and also, there's no way to tell what "DEFAULTS" (why caps?) should be." Yes there is. The defaults are literally what's in the config file in the archive and not on the filesystem. How would that not be a way to determine default settings? I'm not suggesting the package manager would have to understand the settings, but it would be able to tell if the contents of that file are different from another version. (Which it obviously does already, otherwise it wouldn't know to make a pacnew file.) I can't imagine it'd be that difficult for pacman to compare checksums between files in /etc or /boot between versions of a package (If a previous version is available.) and what's on /etc and determine if it really needs to bother putting a pacnew file on the filesystem that doesn't need to be there. It's already doing some sort of check between what's in the package and what's on the filesystem already. Yaro signature.asc Description: OpenPGP digital signature
Re: [arch-general] No login after update
On 8/19/20 2:48 PM, Giancarlo Razzolini via arch-general wrote: > Em agosto 19, 2020 16:37 Yaro Kasear escreveu: >> >> I've always questioned the wisdom of dropping a .pacnew just when the >> file is different from the default. There's really no reason for it >> considering any changes you made were deliberate and presumably thought >> out. The end result is pacman cluttering /etc with a default >> configuration file whose only reason for existing is to, if it's used, >> clear settings. Why? >> > > The .pacnew is there to indicate that something new exists, or that > you changed > something. Most of the time you can remove .pacnew files, but not > always. Also, > it's only "cluttering" /etc (and /boot, btw), if you don't handle them. > >> What pacman SHOULD do is compare /etc files between package versions and >> see if there's a change BETWEEN DEFAULTS. *Then* there's an actual >> reason to need a new default config file for the user to examine because >> then there's an actual indicator some meaningful change in default >> configuration or how the package handles configs happened. >> > > That's way beyond the scope of a package manager, and also, there's no > way > to tell what "DEFAULTS" (why caps?) should be. Caps for emphasis is all. > >> All most pacnew files wind up doing is sitting there for thirty seconds >> before being deleted without anyone even opening them because they're >> literally just what the file was before the user ALREADY changed it >> before... because it's utterly useless to get a default config file when >> you've intentionally changed it and there's nothing in the new version >> of the package that calls for an examination of the defaults. >> > > I don't know why you said that .pacnew sits for thirty seconds before > being > deleted. Are you using a hook that does this? Because nothing handles > them > automatically, that's the user's job. There are tools to aid in doing > that, > but in the end the user should know what to apply, and what to discard. I wasn't being literal about thirty seconds. Exaggerating. > > Regards, > Giancarlo Razzolini Yaro signature.asc Description: OpenPGP digital signature
Re: [arch-general] No login after update
Em agosto 19, 2020 16:37 Yaro Kasear escreveu: I've always questioned the wisdom of dropping a .pacnew just when the file is different from the default. There's really no reason for it considering any changes you made were deliberate and presumably thought out. The end result is pacman cluttering /etc with a default configuration file whose only reason for existing is to, if it's used, clear settings. Why? The .pacnew is there to indicate that something new exists, or that you changed something. Most of the time you can remove .pacnew files, but not always. Also, it's only "cluttering" /etc (and /boot, btw), if you don't handle them. What pacman SHOULD do is compare /etc files between package versions and see if there's a change BETWEEN DEFAULTS. *Then* there's an actual reason to need a new default config file for the user to examine because then there's an actual indicator some meaningful change in default configuration or how the package handles configs happened. That's way beyond the scope of a package manager, and also, there's no way to tell what "DEFAULTS" (why caps?) should be. All most pacnew files wind up doing is sitting there for thirty seconds before being deleted without anyone even opening them because they're literally just what the file was before the user ALREADY changed it before... because it's utterly useless to get a default config file when you've intentionally changed it and there's nothing in the new version of the package that calls for an examination of the defaults. I don't know why you said that .pacnew sits for thirty seconds before being deleted. Are you using a hook that does this? Because nothing handles them automatically, that's the user's job. There are tools to aid in doing that, but in the end the user should know what to apply, and what to discard. Regards, Giancarlo Razzolini pgp_77edb9oPm.pgp Description: PGP signature
Re: [arch-general] No login after update
On 8/19/20 2:13 PM, Giancarlo Razzolini via arch-general wrote: > Em agosto 19, 2020 16:02 Manuel Reimer escreveu: >> Hello, >> >> Some minutes ago I did a regular system update and after that decided >> to reboot. After reboot I was unable to log into my system. After >> fiddling a bit I rebooted to an Arch boot stick to find the following >> message in pacman.log: >> >> [2020-08-19T20:42:55+0200] [ALPM] warning: /etc/pam.d/system-login >> installed as >> /etc/pam.d/system-login.pacnew >> > > The .pacnew should've been handled *before* rebooting. > >> As this seemed to be a candidate that may cause login problems, I >> deleted "system-login" and moved the ".pacnew" into place. >> >> After reboot I'm now able to log in again... >> >> IMHO something like this should not happen... >> >> Maybe it's worth a note on the Arch homepage that it is important to >> move this pacnew into place before reboot? >> > > This only affected you and whomever else changed system-login. It's > not news > material. Also, if you're messing with PAM, you should be responsible > for applying > the new stuff, otherwise it'll break, like it did for you. > > Regards, > Giancarlo Razzolini I've always questioned the wisdom of dropping a .pacnew just when the file is different from the default. There's really no reason for it considering any changes you made were deliberate and presumably thought out. The end result is pacman cluttering /etc with a default configuration file whose only reason for existing is to, if it's used, clear settings. Why? What pacman SHOULD do is compare /etc files between package versions and see if there's a change BETWEEN DEFAULTS. *Then* there's an actual reason to need a new default config file for the user to examine because then there's an actual indicator some meaningful change in default configuration or how the package handles configs happened. All most pacnew files wind up doing is sitting there for thirty seconds before being deleted without anyone even opening them because they're literally just what the file was before the user ALREADY changed it before... because it's utterly useless to get a default config file when you've intentionally changed it and there's nothing in the new version of the package that calls for an examination of the defaults. Yaro signature.asc Description: OpenPGP digital signature
Re: [arch-general] No login after update
Em agosto 19, 2020 16:02 Manuel Reimer escreveu: Hello, Some minutes ago I did a regular system update and after that decided to reboot. After reboot I was unable to log into my system. After fiddling a bit I rebooted to an Arch boot stick to find the following message in pacman.log: [2020-08-19T20:42:55+0200] [ALPM] warning: /etc/pam.d/system-login installed as /etc/pam.d/system-login.pacnew The .pacnew should've been handled *before* rebooting. As this seemed to be a candidate that may cause login problems, I deleted "system-login" and moved the ".pacnew" into place. After reboot I'm now able to log in again... IMHO something like this should not happen... Maybe it's worth a note on the Arch homepage that it is important to move this pacnew into place before reboot? This only affected you and whomever else changed system-login. It's not news material. Also, if you're messing with PAM, you should be responsible for applying the new stuff, otherwise it'll break, like it did for you. Regards, Giancarlo Razzolini pgpmtnk7IM_k3.pgp Description: PGP signature
Re: [arch-general] No login after update
Le 19 août 2020 23:02:12 GMT+04:00, Manuel Reimer a écrit : >Hello, > >I know that Arch is not for the "average user" and some background >knowledge is expected, but this was the first time I needed a boot stick >since I think at least one year. > >Some minutes ago I did a regular system update and after that decided to >reboot. After reboot I was unable to log into my system. After fiddling >a bit I rebooted to an Arch boot stick to find the following message in >pacman.log: > >[2020-08-19T20:42:55+0200] [ALPM] warning: /etc/pam.d/system-login >installed as >/etc/pam.d/system-login.pacnew > >As this seemed to be a candidate that may cause login problems, I >deleted "system-login" and moved the ".pacnew" into place. > >After reboot I'm now able to log in again... > >IMHO something like this should not happen... > >Maybe it's worth a note on the Arch homepage that it is important to >move this pacnew into place before reboot? > >Manuel Well, if you don’t read pacman output, you’re kind of asking for such troubles. ;) Also in this case, this means that you modified system-login at some point, else it would have been silently replaced. So no, it’s not worth a news entry. Regards, Bruno/Archange
Re: [arch-general] No login after update
This can only happen if you or another program modified the original file. Josef Miegl On August 19, 2020 9:02:12 PM GMT+02:00, Manuel Reimer wrote: >Hello, > >I know that Arch is not for the "average user" and some background >knowledge is expected, but this was the first time I needed a boot >stick >since I think at least one year. > >Some minutes ago I did a regular system update and after that decided >to >reboot. After reboot I was unable to log into my system. After fiddling > >a bit I rebooted to an Arch boot stick to find the following message in > >pacman.log: > >[2020-08-19T20:42:55+0200] [ALPM] warning: /etc/pam.d/system-login >installed as >/etc/pam.d/system-login.pacnew > >As this seemed to be a candidate that may cause login problems, I >deleted "system-login" and moved the ".pacnew" into place. > >After reboot I'm now able to log in again... > >IMHO something like this should not happen... > >Maybe it's worth a note on the Arch homepage that it is important to >move this pacnew into place before reboot? > >Manuel
