[Bug 1810535] Re: go 1.10 fails to symlink misc into GOROOT

2020-01-23 Thread Hamilton Turner
Same issue on 18.04. Resolved with $ cd /usr/lib/go-1.10/ ; sudo ln -s
../../share/go-1.10/misc misc


$ lsb_release -rd
Description:Ubuntu 18.04.3 LTS
Release:18.04

$ apt-cache policy golang-1.10-go
golang-1.10-go:
  Installed: 1.10.4-2ubuntu1~18.04.1
  Candidate: 1.10.4-2ubuntu1~18.04.1
  Version table:
 *** 1.10.4-2ubuntu1~18.04.1 500
500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
100 /var/lib/dpkg/status
 1.10.1-1ubuntu2 500
500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages


** Tags added: bionic

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1810535

Title:
  go 1.10 fails to symlink misc into GOROOT

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/golang-1.10/+bug/1810535/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1331320] Re: Differences between test-kickseed and real execution

2014-06-19 Thread Hamilton Turner
** Branch linked: lp:~hamiltont-x/kickseed/kickseed

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1331320

Title:
  Differences between test-kickseed and real execution

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kickseed/+bug/1331320/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1331814] Re: Warning messages for handlers are never called

2014-06-19 Thread Hamilton Turner
Also, I added a reference file for kickstart that lists all commands
with all command options. By doing

$ ./test-kickseed tests/full-full-06-2014.ks

we can see which kickstart options are not currently supported, as they will 
print out LOG messages. It's 
not exactly test driven dev, but it's something ;-)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1331814

Title:
  Warning messages for handlers are never called

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kickseed/+bug/1331814/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1331814] Re: Warning messages for handlers are never called

2014-06-19 Thread Hamilton Turner
Fixed. Ash/Dash don't support ERR traps, so I instead did this:

set +e
output=$(getopt -o '' -l $options -- $@)
errout=$(getopt -o '' -l $options -- $@ 21 /dev/null)
set -e

if [[ -n $errout ]]; then
warn_getopt $type
warn $type Error: $errout
fi

This results in much better logging during install, without stopping
output to console. For example:

$ cat /var/log/syslog | grep kickseed
 ... snip ... 
Jun 19 01:56:26 kickseed: Failed to parse %pre options
Jun 19 01:56:26 kickseed: %pre Error: getopt: unrecognized option 
'--log=/test.log'

I've also integrated this with test-kickseed, which outputs this:

$ ./test-kickseed custom-test.ks
getopt: unrecognized option '--log=/test.log'
LOG: Failed to parse some %pre options
LOG: %pre Error: getopt: unrecognized option '--log=/test.log'

As you can see, getopt still prints to stderr, but now we have log
messages printed as well.


** Changed in: kickseed (Ubuntu)
   Status: New = Fix Committed

** Changed in: kickseed (Ubuntu)
 Assignee: (unassigned) = Hamilton Turner (hamiltont-x)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1331814

Title:
  Warning messages for handlers are never called

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kickseed/+bug/1331814/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 976632] Re: nfs4 mounts are not mapping userids, uses nobody/nogroup

2014-06-19 Thread Hamilton Turner
Just experienced this issue. Used TJ's fix with success, but I had to
also restart nfs on the server - multiple restarts of idmapd did
nothing. I did not try restarting the client.

FWIW, here's my details. Primary difference is that my server is a
CentOS box.

Client: 
   Linux 3 3.11.0-23-generic #40~precise1-Ubuntu SMP Wed Jun 4 22:06:36 UTC 
2014 x86_64 x86_64 x86_64 GNU/Linux
   nfs-common 1:1.2.5-3ubuntu3.1 
   nfs4-acl-tools: 0.3.3-1
   nfswatch: 4.99.11-1

Server: 
   Linux snip 2.6.32-431.5.1.el6.x86_64 #1 SMP Wed Feb 12 00:41:43 UTC 
2014 x86_64 x86_64 x86_64 GNU/Linux
   nfs-utils-1.2.3-39.el6.x86_64
   nfs-utils-lib-1.1.5-6.el6.x86_64
   nfs4-acl-tools-0.3.3-6.el6.x86_64

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/976632

Title:
  nfs4 mounts are not mapping userids, uses nobody/nogroup

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/976632/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 976632] Re: nfs4 mounts are not mapping userids, uses nobody/nogroup

2014-06-19 Thread Hamilton Turner
Also, my client/server are sharing UIDs, which seems to imply this is
independent of https://bugs.launchpad.net/ubuntu/+source/nfs-
utils/+bug/966734

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/976632

Title:
  nfs4 mounts are not mapping userids, uses nobody/nogroup

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/976632/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1331320] [NEW] Differences between test-kickseed and real execution

2014-06-18 Thread Hamilton Turner
Public bug reported:

I've encountered an odd issue, perhaps someone can help me isolate. When
I run test-kickseed on the %pre block below, 'handler/pre.sh' reports a
getopt failure parsing the %pre options **and continues executing**.
(support for --log is the feature I'm currently adding into kickseed,
the issue is that it continues executing)

---
%pre --log=foobar.log
echo should pass
%end


When I attempt an install with this %pre **kickseed halts**. This is
because the call to getopt returns a non-zero exit code and errexit (set
-e) is turned on. Halting seems to be the proper behavior, but test-
kickseed continues executing.

I originally thought it had something to do with my shell or my getopt
implementation, but I wrote a small test.sh file (below) that shows that
set -e works in a manner consistent with what I'm seeing during an
actual install. This test file halts when running bash -e test.sh or
sh -e test.sh, and test-kickseed does not.

--test.sh---
#!/bin/sh -e

bar () {
  set -o | grep errexit
  TEMP=`getopt -o '' -l foo: -- $@`
  echo good stuff
}

bar --foo=bar
bar --log
-
$ ./test.sh
errexit on
good stuff
errexit on
getopt: unrecognized option '--log'
--

So what's happening with test-kickseed? I did add a debug statement in
handlers/pre.sh before the call to getopt, and errexit is definitely
turned on. I added a debug statement after getopt, and the error code is
1. This seems like it should be halting, but for some insane reason it's
not - with set -e I shouldn't even see the output telling me the error
code, the program should terminate automatically.

PS - I have moved all my getopt calls to their own lines, so this is not
an issue with set -e and ||

** Affects: kickseed (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1331320

Title:
  Differences between test-kickseed and real execution

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kickseed/+bug/1331320/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1331320] Re: Differences between test-kickseed and real execution

2014-06-18 Thread Hamilton Turner
I'm not insane, but I am wrong! This is indeed caused by set -e and
||. Specifically, the difference between how test-kickseed and initrd-
kickseed call the kickseed function.

test-kickseed calls:

 RET=0
 (kickseed $1) || RET=$?

This means that kickseed() is called as part of any command executed in
a  or || list, and therefore errexit has no effect anywhere inside of
the kickseed function when it is called from test-kickseed.

This is clearly intentional, but it also caused me substantial confusion
due to different behavior, so I'll put in a tiny commit that causes a
big warning message to be printed when $RET != 0. Currently the exit
code is just being returned to the user, and it would take a
particularly savvy user to check the exit code of test-kickseed every
time and interpret that a non-zero means that the install will behave
differently than the test.


** Changed in: kickseed (Ubuntu)
   Status: New = In Progress

** Changed in: kickseed (Ubuntu)
 Assignee: (unassigned) = Hamilton Turner (hamiltont-x)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1331320

Title:
  Differences between test-kickseed and real execution

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kickseed/+bug/1331320/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1331320] Re: Differences between test-kickseed and real execution

2014-06-18 Thread Hamilton Turner
I believe
http://bazaar.launchpad.net/~hamiltont-x/kickseed/kickseed/revision/298
addresses this well. I decided that using $RET was a poor choice, as it
only checks the return of the kickseed function and can return a 0 value
even if an internal function returns a non-zero value. I have instead
disabled errexit when running test-kickseed and added a trap for
catching ERR signals. This allows us to output a nice warning message
that the installation will not work as expected because there was an ERR
triggered while parsing the kickstart. Note: I used code from
http://stackoverflow.com/q/6928946/119592, so if the licensing isn't ok
then we may need to rewrite the ERR handler from scratch. If this is
necessary someone let me know, it's only a few lines  but the one I used
is fairly comprehensive

** Changed in: kickseed (Ubuntu)
   Status: In Progress = Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1331320

Title:
  Differences between test-kickseed and real execution

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kickseed/+bug/1331320/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1331814] [NEW] Warning messages for handlers are never called

2014-06-18 Thread Hamilton Turner
Public bug reported:

Multiple handlers use the following syntax:

 eval set -- $(getopt -o '' -l interpreter: -- $@) || {
warn_getopt %pre; return; }

As mentioned in /usr/share/doc/util-linux-ng-2.17.2/getopt-parse.bash, this 
will never
call the warning:

# We need TEMP as the `eval set --' would nuke the return value of getopt.
   TEMP=`getopt -o ab:c:: --long a-long,b-long:,c-long:: \
  -n 'example.bash' -- $@`

Here is a simple example to prove this:

#!/bin/sh
trap 'echo ERROR happened' ERR
echo begin
eval set -- $(false)
echo end

Because of this, almost every bug report mentions something along the
lines of getopt printed an error. This is getout outputting to stderr,
but the non-zero exit code is being swallowed and errexit is not
happening.

This coding was probably designed intentionally to disable automatic
exit whenever getopt found an unexpected argument, due to the fact that
this (currently) happens on almost every kickstart file as our syntax
support is quite limited.

However, it also hides the warning from the user, which I believe is the
real bug. Moreover, the only error is printed briefly to a terminal and
then never seen again, which makes it tough for people to put in bug
reports.

Perhaps a better solution would be to use set +x and set -e to
temporarily disable errexit, and use a trap on ERR to ensure that these
errors are caught and printed to both syslog and the current TTY.

** Affects: kickseed (Ubuntu)
 Importance: Undecided
 Status: New

** Description changed:

  Multiple handlers use the following syntax:
  
- eval set -- $(getopt -o '' -l interpreter: -- $@) || {
+  eval set -- $(getopt -o '' -l interpreter: -- $@) || {
  warn_getopt %pre; return; }
  
- As mentioned in /usr/share/doc/util-linux-ng-2.17.2/getopt-parse.bash, this 
will never 
- call the warning: 
+ As mentioned in /usr/share/doc/util-linux-ng-2.17.2/getopt-parse.bash, this 
will never
+ call the warning:
  
- # We need TEMP as the `eval set --' would nuke the return value of getopt.
-TEMP=`getopt -o ab:c:: --long a-long,b-long:,c-long:: \
-   -n 'example.bash' -- $@`
+ # We need TEMP as the `eval set --' would nuke the return value of getopt.
+    TEMP=`getopt -o ab:c:: --long a-long,b-long:,c-long:: \
+   -n 'example.bash' -- $@`
  
  Here is a simple example to prove this:
  
- #!/bin/sh
- trap 'echo ERROR happened' ERR
- echo begin
- eval set -- $(false)
- echo end
+ #!/bin/sh
+ trap 'echo ERROR happened' ERR
+ echo begin
+ eval set -- $(false)
+ echo end
  
  Because of this, almost every bug report mentions something along the
  lines of getopt printed an error. This is getout outputting to stderr,
- but the exit code is being swallowed and errexit is not happening.
+ but the non-zero exit code is being swallowed and errexit is not
+ happening.
  
  This coding was probably designed intentionally to disable automatic
  exit whenever getopt found an unexpected argument, due to the fact that
  this (currently) happens on almost every kickstart file as our syntax
  support is quite limited.
  
  However, it also hides the warning from the user, which I believe is the
  real bug. Moreover, the only error is printed briefly to a terminal and
  then never seen again, which makes it tough for people to put in bug
  reports.
  
  Perhaps a better solution would be to use set +x and set -e to
  temporarily disable errexit, and use a trap on ERR to ensure that these
  errors are caught and printed to both syslog and the current TTY.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1331814

Title:
  Warning messages for handlers are never called

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kickseed/+bug/1331814/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 776701] Re: firewall command not implemented

2014-06-18 Thread Hamilton Turner
** Changed in: kickseed (Ubuntu)
   Status: Triaged = Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/776701

Title:
  firewall command not implemented

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kickseed/+bug/776701/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1330799] [NEW] No --log option with %post sections

2014-06-16 Thread Hamilton Turner
Public bug reported:

The %post section in RHEL has a --log option that kickseed does not
support. Oddly enough, there should be a generic warning printed about
this - kickseed/handlers/post.sh should pick up that --log is
unrecognized and call warn_getopt %post.

I don't see that warning being printed - perhaps it's not showing up in
/var/log/installer/syslog for some reason?

Just for future testing, here are some cases that don't work:

%post --nochroot --log=/target/test1.log
echo 'Hello, World'
%end

%post --nochroot --log=/test2.log
echo 'Hello, World'
%end

%post --log=/target/test3.log
echo 'Hello, World'
%end

%post --log=/test4.log
echo 'Hello, World'
%end

%post
exec  /dev/tty3  /dev/tty3
chvt 3
echo
echo 
echo # Running Post Configuration   #
echo 
(
echo 'Hello, World!'
) 21 | /usr/bin/tee /var/log/test5.log
chvt 1
%end

Also, the following does not work. I suspect I'm making some mistake
here, as this should work just fine with the current kickseed codebase
if I understand correctly. However this switching TTY stuff is new to
me, so perhaps I'm mistaking something

%post --nochroot
exec  /dev/tty3  /dev/tty3
chvt 3
echo
echo 
echo # Running Post Configuration   #
echo 
(
echo 'Hello, World!'
) 21 | /usr/bin/tee /target/test6.log
chvt 1
%end

** Affects: kickseed (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1330799

Title:
  No --log option with %post sections

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kickseed/+bug/1330799/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs