Problemns after updating from 6.1.4 to 6.1.5
It seemed like such a simple thing. Just boot up a new 6.1.5 kernel,
extract the new distribution sets, run etcupdate and postinstall, and
should be done, right?
Wrong!
I've got two problems at the moment. First is su(1) doesn't work:
I _know_ I'm using the correct root password, but still I get
su: Sorry: authentication error
And, in /var/log/authlog I get
su: BAD SU paul to root on /dev/pts/1: authentication error
FWIW, when I ran postinstall, it told me to "fix" the old ptyfs
devnodes, so I did. Is this the source of the problem? And if so,
what's needed to get my su back?
My second problem is a bit more concerning. I can no longer send any
mail! Receiving mail is fine, but when sending mail I get the following
in my /var/log/maillog file:
postfix/postdrop[4338]: warning: mail_queue_enter: create file
maildrop/102777.4338: Permission denied
It's not at all clear to me where maildrop directory is. And it is also
not clear to me why this is broken, since I took great pains to avoid
modifying the postfix {master,main}.cf files during etcupdate.
Any clues will be greatly appreciated.
Re: Problemns after updating from 6.1.4 to 6.1.5
On Sat, Oct 18, 2014 at 10:14:34AM +, Paul Goyette wrote:
> It's not at all clear to me where maildrop directory is. And it is also not
> clear to me why this is broken, since I took great pains to avoid modifying
> the postfix {master,main}.cf files during etcupdate.
I hit that last week - I think it is a change postfix...
$ ls -ld /var/spool/postfix/maildrop
drwx-wx--- 2 postfix maildrop 512 Oct 18 10:12 /var/spool/postfix/maildrop
Cheers,
Patrick
Re: Problemns after updating from 6.1.4 to 6.1.5
> It's not at all clear to me where maildrop directory is. And it is
> also not clear to me why this is broken, since I took great pains to
> avoid modifying the postfix {master,main}.cf files during etcupdate.
I hit that last week - I think it is a change postfix...
$ ls -ld /var/spool/postfix/maildrop
drwx-wx--- 2 postfix maildrop 512 Oct 18 10:12 /var/spool/postfix/maildrop
Yep, that's what my machine says, too. (Identical except for the mtime.)
But, since postdrop runs as setgid=maildrop it should be able to write the
files:
$ ls -l `which postdrop`
-r-xr-xr-x 1 root wheel 183109 Sep 30 00:38 /usr/sbin/postdrop
Any clue on how to fix?
Re: Problemns after updating from 6.1.4 to 6.1.5
>> > It's not at all clear to me where maildrop directory is. And it is >
>> > also not clear to me why this is broken, since I took great pains to >
>> > avoid modifying the postfix {master,main}.cf files during etcupdate.
>>
>> I hit that last week - I think it is a change postfix...
>>
>> $ ls -ld /var/spool/postfix/maildrop
>> drwx-wx--- 2 postfix maildrop 512 Oct 18 10:12
>> /var/spool/postfix/maildrop
>
> Yep, that's what my machine says, too. (Identical except for the
> mtime.)
>
> But, since postdrop runs as setgid=maildrop it should be able to write
> the files:
>
> $ ls -l `which postdrop`
> -r-xr-xr-x 1 root wheel 183109 Sep 30 00:38 /usr/sbin/postdrop
>
> Any clue on how to fix?
Yesterday I upgraded a local host (via local src build) to 6.1.5
and have:
# ls -l `which postdrop`
-r-xr-sr-x 1 root maildrop 183109 Oct 17 13:41 /usr/sbin/postdrop
#
Regards,
- Håvard
Re: Problemns after updating from 6.1.4 to 6.1.5
On Sat, 18 Oct 2014 10:14:34 + (UTC) Paul Goyette wrote: > I _know_ I'm using the correct root password, but still I get > > su: Sorry: authentication error > > And, in /var/log/authlog I get > > su: BAD SU paul to root on /dev/pts/1: authentication error > > > FWIW, when I ran postinstall, it told me to "fix" the old ptyfs > devnodes, so I did. Is this the source of the problem? And if so, > what's needed to get my su back? I'm not sure, but seem to recall seeing messages about fixing old ptyfs nodes whenever I update -CURRENT, and haven't had trouble with su. What *has* given me trouble with authentication in the past was inadvertantly messing with PAM. For instance, compiling the system with MKKERBEROS=no without first removing all mention of kerberos from the PAM configuration. Every PAM chain that included kerberos as a possible authentication mechanism started failing because the required module was missing. Maybe check that all the PAM modules mentioned in your configs (not only the ones you actually use) are present and up-to-date? Just a thought. -- IDL
Re: Problemns after updating from 6.1.4 to 6.1.5
On Sat, Oct 18, 2014 at 10:14:34AM +, Paul Goyette wrote: > It seemed like such a simple thing. Just boot up a new 6.1.5 > kernel, extract the new distribution sets, run etcupdate and > postinstall, and should be done, right? You did use tar xzpf for extracting the sets, did you? Joerg
Re: Problemns after updating from 6.1.4 to 6.1.5
Ooopppsss!
Seems like I forgot the -p option when untarring the distribution sets!
Turns out that /usr/bin/su was also missing the Set-UID bit, and fixing
that make su(1) work again, too!
Thanks for all the quick rpelies that led to finding the solution.
On Sat, 18 Oct 2014, Havard Eidnes wrote:
It's not at all clear to me where maildrop directory is. And it is >
also not clear to me why this is broken, since I took great pains to >
avoid modifying the postfix {master,main}.cf files during etcupdate.
I hit that last week - I think it is a change postfix...
$ ls -ld /var/spool/postfix/maildrop
drwx-wx--- 2 postfix maildrop 512 Oct 18 10:12
/var/spool/postfix/maildrop
Yep, that's what my machine says, too. (Identical except for the
mtime.)
But, since postdrop runs as setgid=maildrop it should be able to write
the files:
$ ls -l `which postdrop`
-r-xr-xr-x 1 root wheel 183109 Sep 30 00:38 /usr/sbin/postdrop
Any clue on how to fix?
Yesterday I upgraded a local host (via local src build) to 6.1.5
and have:
# ls -l `which postdrop`
-r-xr-sr-x 1 root maildrop 183109 Oct 17 13:41 /usr/sbin/postdrop
#
Regards,
- Håvard
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-
Re: Problemns after updating from 6.1.4 to 6.1.5
> Ooopppsss! > > > > > Seems like I forgot the -p option when untarring the distribution > sets! Been there, done that, wasn't too pleasant... :) Regards, - Håvard
Re: Problemns after updating from 6.1.4 to 6.1.5
If you haven't tried them yet, I'd recommend using jmmv's sysbuild & sysupgrade
tools (http://blog.netbsd.org/tnf/entry/introducing_sysbuild_and_sysupgrade)
for consistent builds & upgrades without much manual interventions...
/P
On Oct 18, 2014, at 13:47 , Paul Goyette wrote:
> Ooopppsss!
>
>
>
>
> Seems like I forgot the -p option when untarring the distribution sets!
>
> Turns out that /usr/bin/su was also missing the Set-UID bit, and fixing that
> make su(1) work again, too!
>
> Thanks for all the quick rpelies that led to finding the solution.
>
>
>
>
> On Sat, 18 Oct 2014, Havard Eidnes wrote:
>
> It's not at all clear to me where maildrop directory is. And it is >
> also not clear to me why this is broken, since I took great pains to >
> avoid modifying the postfix {master,main}.cf files during etcupdate.
I hit that last week - I think it is a change postfix...
$ ls -ld /var/spool/postfix/maildrop
drwx-wx--- 2 postfix maildrop 512 Oct 18 10:12
/var/spool/postfix/maildrop
>>>
>>> Yep, that's what my machine says, too. (Identical except for the
>>> mtime.)
>>>
>>> But, since postdrop runs as setgid=maildrop it should be able to write
>>> the files:
>>>
>>> $ ls -l `which postdrop`
>>> -r-xr-xr-x 1 root wheel 183109 Sep 30 00:38 /usr/sbin/postdrop
>>>
>>> Any clue on how to fix?
>>
>> Yesterday I upgraded a local host (via local src build) to 6.1.5
>> and have:
>>
>> # ls -l `which postdrop`
>> -r-xr-sr-x 1 root maildrop 183109 Oct 17 13:41 /usr/sbin/postdrop
>> #
>>
>> Regards,
>>
>> - Håvard
>>
>
> -
> | Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
> | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
> | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
> | Kernel Developer | | pgoyette at netbsd.org |
> -
Re: Problemns after updating from 6.1.4 to 6.1.5
Paul Goyette wrote on 10/18/2014 03:14 AM: > run etcupdate > > su: Sorry: authentication error well i know i was asked if i wanted to update /etc/passwd which would have messed up my users and passwords, and there was one other file too that looked like it contained some auth info, which i didn't update. are you sure you didn't update those files during etcupdate?
Re: Problemns after updating from 6.1.4 to 6.1.5
Ah, nevermind, i see you found the problem. sorry didn't notice until later because the thread got broken up somehow
Re: Problemns after updating from 6.1.4 to 6.1.5
I carefully merge my password and groups files... :) As I reported earlier, I forgot the -p option for tar, so it didn't set any [SG]uid permission bits. On Sat, 18 Oct 2014, scar wrote: Paul Goyette wrote on 10/18/2014 03:14 AM: run etcupdate su: Sorry: authentication error well i know i was asked if i wanted to update /etc/passwd which would have messed up my users and passwords, and there was one other file too that looked like it contained some auth info, which i didn't update. are you sure you didn't update those files during etcupdate? - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: Problemns after updating from 6.1.4 to 6.1.5
On Sat, 18 Oct 2014, Fredrik Pettai wrote: If you haven't tried them yet, I'd recommend using jmmv's sysbuild & sysupgrade tools (http://blog.netbsd.org/tnf/entry/introducing_sysbuild_and_sysupgrade) for consistent builds & upgrades without much manual interventions... Looks interesting. Of course, I'll probably have to tweak them to get the kernel installed properly in my DOMU :) * I have to load the kernel from an external partition using grub, and thus have to edit grub's menu.lst config file! * The booted kernel is independent of what is in /netbsd, so I currently have to manually gunzip(1) the kernel on the external partition and put the results in /netbsd - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: Problemns after updating from 6.1.4 to 6.1.5
On Oct 19, 5:32pm, Paul Goyette wrote: } On Sat, 18 Oct 2014, Fredrik Pettai wrote: } } > If you haven't tried them yet, I'd recommend using jmmv's sysbuild & } > sysupgrade tools } > (http://blog.netbsd.org/tnf/entry/introducing_sysbuild_and_sysupgrade) } > for consistent builds & upgrades without much manual interventions... } } Looks interesting. Of course, I'll probably have to tweak them to get } the kernel installed properly in my DOMU :) } } * I have to load the kernel from an external partition using grub, and }thus have to edit grub's menu.lst config file! } } * The booted kernel is independent of what is in /netbsd, so I currently }have to manually gunzip(1) the kernel on the external partition and }put the results in /netbsd Why would you be using grub when you're keeping the kernel outside the NetBSD partition. All you need to do is add: kernel = "" to your domU config. xentools is fully capable of loading a NetBSD kernel, including one that is gzipped. An example from one of my config files is: kernel = "/usr/pkg/etc/xen/kernels/netbsd-7-XEN3_DOMU.gz" This is not something that should be dependent on your dom0 as xentools is supplied by the Xen project. }-- End of excerpt from Paul Goyette
Re: Problemns after updating from 6.1.4 to 6.1.5
On Sun, 19 Oct 2014, John Nemeth wrote: } * I have to load the kernel from an external partition using grub, and }thus have to edit grub's menu.lst config file! } } * The booted kernel is independent of what is in /netbsd, so I currently }have to manually gunzip(1) the kernel on the external partition and }put the results in /netbsd Why would you be using grub when you're keeping the kernel outside the NetBSD partition. All you need to do is add: kernel = "" to your domU config. xentools is fully capable of loading a NetBSD kernel, including one that is gzipped. An example from one of my config files is: kernel = "/usr/pkg/etc/xen/kernels/netbsd-7-XEN3_DOMU.gz" This is not something that should be dependent on your dom0 as xentools is supplied by the Xen project. Most likely, I don't know enough (approx zero) of the XEN environment to get it right. I'm just following the explicit instructions from my DOM0 provider. As a quick summary, I initially boot up a "common" DOMU which runs some variant of Linux. A customer-specific very small ext2fs partition is mounted (based on my login information) on which I put my grub menu.lst file and the kernel(s) I need to boot. This partition is accessible after boot, so once I get things up and running I don't have to touch the Linux world again. (Unless, of course, I manage to completely destroy my NetBSD system, and thus would need to reinstall it from scratch.) - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: Problemns after updating from 6.1.4 to 6.1.5
On Oct 20, 6:38am, Paul Goyette wrote:
} On Sun, 19 Oct 2014, John Nemeth wrote:
}
} > } * I have to load the kernel from an external partition using grub, and
} > }thus have to edit grub's menu.lst config file!
} > }
} > } * The booted kernel is independent of what is in /netbsd, so I currently
} > }have to manually gunzip(1) the kernel on the external partition and
} > }put the results in /netbsd
} >
} > Why would you be using grub when you're keeping the kernel
} > outside the NetBSD partition. All you need to do is add:
} >
} > kernel = ""
} >
} > to your domU config. xentools is fully capable of loading a NetBSD
} > kernel, including one that is gzipped. An example from one of my
} > config files is:
} >
} > kernel = "/usr/pkg/etc/xen/kernels/netbsd-7-XEN3_DOMU.gz"
} >
} > This is not something that should be dependent on your dom0 as
} > xentools is supplied by the Xen project.
}
} Most likely, I don't know enough (approx zero) of the XEN environment to
} get it right. I'm just following the explicit instructions from my DOM0
} provider.
So, you're using a VPS. This can change everything depending
on how they do things. Which raises the question, who is the
provider?
} As a quick summary, I initially boot up a "common" DOMU which runs some
} variant of Linux. A customer-specific very small ext2fs partition is
} mounted (based on my login information) on which I put my grub menu.lst
} file and the kernel(s) I need to boot. This partition is accessible
This tells me that they are most likely using pygrub or pvgrub.
Basically these things dig around in the image for the domU to find
a grub config file, which then tells p[yv]grub what needs to be
extracted (i.e. it will copy the kernel {and initramhd for linux}
out of the image and hand it to Xen). This also tells me that in
your case, the menu.lst thing is necessary.
}-- End of excerpt from Paul Goyette
Re: Problemns after updating from 6.1.4 to 6.1.5
On Sun, 19 Oct 2014, John Nemeth wrote:
On Oct 20, 6:38am, Paul Goyette wrote:
} On Sun, 19 Oct 2014, John Nemeth wrote:
}
} > } * I have to load the kernel from an external partition using grub, and
} > }thus have to edit grub's menu.lst config file!
} > }
} > } * The booted kernel is independent of what is in /netbsd, so I currently
} > }have to manually gunzip(1) the kernel on the external partition and
} > }put the results in /netbsd
} >
} > Why would you be using grub when you're keeping the kernel
} > outside the NetBSD partition. All you need to do is add:
} >
} > kernel = ""
} >
} > to your domU config. xentools is fully capable of loading a NetBSD
} > kernel, including one that is gzipped. An example from one of my
} > config files is:
} >
} > kernel = "/usr/pkg/etc/xen/kernels/netbsd-7-XEN3_DOMU.gz"
} >
} > This is not something that should be dependent on your dom0 as
} > xentools is supplied by the Xen project.
}
} Most likely, I don't know enough (approx zero) of the XEN environment to
} get it right. I'm just following the explicit instructions from my DOM0
} provider.
So, you're using a VPS. This can change everything depending
on how they do things. Which raises the question, who is the
provider?
} As a quick summary, I initially boot up a "common" DOMU which runs some
} variant of Linux. A customer-specific very small ext2fs partition is
} mounted (based on my login information) on which I put my grub menu.lst
} file and the kernel(s) I need to boot. This partition is accessible
This tells me that they are most likely using pygrub or pvgrub.
Basically these things dig around in the image for the domU to find
a grub config file, which then tells p[yv]grub what needs to be
extracted (i.e. it will copy the kernel {and initramhd for linux}
out of the image and hand it to Xen). This also tells me that in
your case, the menu.lst thing is necessary.
A couple of notes on how this relates to XenServer (and perhaps other
xapi-based providers) - more for the record rather than necessarily of
immediate relevance:
- if loading a kernel from the dom0, it has to be in a very specific
location otherwise you get annoyingly vague errors
- pygrub does not need menu.lst if the kernel path is set in the VM
properties:
PV-kernel ( RW):
PV-ramdisk ( RW):
PV-args ( RW):
PV-legacy-args ( RW):
PV-bootloader ( RW): pygrub
PV-bootloader-args ( RW): --kernel=/netbsd
- pygrub does not need a MBR partition table, it will deal with just a
disklabel with root starting at 0. However, if you've had an MBR partition
on there in the past, ensure you wipe sector zero, not just the partition
table otherwise it will spot the 0xaa55 signature and insist on reading
the non-existent MBR leading to a "No partition" bot failure.
--
Stephen
