[Bug 1765765] Re: on nfsboot 18.04 bionic, internet addresses arn't resolve properly

2019-02-20 Thread Brian Nelson
@Guillermo
The OS shouldn't be trying to raise the interface as it's already configured 
during the boot process. You can't reconfigure the network interface while 
you're booting from the network :)
You need to modify /etc/network/interfaces on your boot server to set the 
interface to manual. See step 5 under 'creating your NFS installation' on this 
page
https://help.ubuntu.com/community/DisklessUbuntuHowto

Related to this, I also set 'net.ifnames=0' in the kernel boot line so
the network devices are always named ethX rather than hardware-specific
names. That's personal preference though.


@beta-tester
Strange. Without specifying 'ip=dhcp' perhaps it was sometimes getting a bootp 
or rarp response without a DNS server settings? Just a guess. If 'ip=X' isn't 
set, it defaults to any autoconfig protocol. I'd suggest setting the ip option 
specifically to dhcp if that's what you expect it to use.
https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt

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

Title:
  on nfsboot 18.04 bionic, internet addresses arn't resolve properly

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

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

[Bug 1765765] Re: on nfsboot 18.04 bionic, internet addresses arn't resolve properly

2019-02-19 Thread Brian Nelson
Works for me on 18.04.1

Do you have 'ip=dhcp' included in your kernel boot line?

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

Title:
  on nfsboot 18.04 bionic, internet addresses arn't resolve properly

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

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

[Bug 1755863] Re: netbooting the bionic live CD over NFS goes straight to maintenance mode :

2018-10-19 Thread Brian Nelson
So I've found a complete work-around for this. I also found that this
issue is NOT new in 18.04 as it also affects 16.x (and likely 15 and 17
too). However it is DIFFERENT in 18.04. More details below.

TL;DR:
You need to netboot with an initramfs that doesn't have 
'scripts/casper-bottom/25disable_cdrom.mount' in it. This script masks the 
dynamically-generated cdrom.mount systemd unit (where the NFS mount goes). That 
causes all the issues described in this bug.

>From whatever machine where netboot initramfs is created:

# Disable/block the problem script
mkdir -p /etc/initramfs-tools/scripts/casper-bottom
touch /etc/initramfs-tools/scripts/casper-bottom/25disable_cdrom.mount

# rebuild initramfs
update-initramfs -u

# Move/copy the new file to the netboot server


The issue here is that systemd isn't able to update its mount status
properly. In the case of 18.04, all of the 'failed' mounts are actually
successfully mounted. This includes /tmp. BUT systemd doesn't recognize
that fact and marks them all as red/failed.

In 16.04 this issue is a bit different. When booting, all of the same
mounts are again mounted successfully AND systemd shows them all as
green/active. BUT if you try to stop/unmount any of them you will see a
similar situation. The unmount will actually succeed, but systemd will
report an unmount failure and continue to show the unit as green/active.

Per the call trace thh noted in comment #21:
>From what I can tell, mount_load_proc_self_mountinfo iterates through every 
>active mount on the system (some perhaps more than once). When it gets to the 
>nfs-mount on /cdrom, it does fail in unit_set_slice and generate the "Failed 
>to set up mount unit: Device or resource busy" error. For whatever reason, 
>that failure seems to completely bork systemd's ability to update its mount 
>status. Thus mounts get 'stuck' either mounted or not from systemd's 
>perspective.

The failure seems to be caused by the fact that the cdrom.mount unit (NFS 
mount) is masked. Once it's unmasked the failure doesn't occur and all mounts 
work as expected. You can actually observe this from within a 'broken' boot at 
the emergency prompt:
rm /lib/systemd/system/cdrom.mount
systemctl daemon-reload
umount /tmp   (ensure it's gone, there may be multiple mounts)
systemctl reset-failed tmp.mount
systemctl start tmp.mount
..and it will succeed

I did verify this issue by actually booting from a 'real' DVD and the
problem doesn't happen there. It's something specific to having the
image mounted over NFS and masking it's unit.

For reference, the disable_cdrom.mount script was the solution for this bug
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1436715

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

Title:
  netbooting the bionic live CD over NFS goes straight to maintenance
  mode :

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

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

[Bug 1755863] Re: netbooting the bionic live CD over NFS goes straight to maintenance mode :

2018-10-17 Thread Brian Nelson
Eric,

The 'recommendation' for masking dev-hugepages you site from that wiki
page is clearly just an example of how you could disable one of the
various mounts described there. I don't think it's a recommendation to
fix anything in particular.

FWIW: Masking dev-hugepages doesn't seem to help much for me. Masking
tmp seems to let the system boot up, but still the other mount services
fail and systemd status is red 'degraded.'

I've ended up masking all affected mounts (per comment 12 and 14) with
the addition of masking run-rpc_pipefs.mount too. This lets the systemd
boot up to green 'running' state.

I'm still having problems logging into Gnome with a user with NFS home.
I'm not sure if that's related to this issue or something else though.
Still looking at that.


I think you're on the right track in comment 27. I get the feeling that 
somewhere along the line a result  of 'this is already mounted' changed from a 
success to a failure in systemd, possibly due to the change in mount.c you 
pasted.

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

Title:
  netbooting the bionic live CD over NFS goes straight to maintenance
  mode :

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

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

[Bug 71322] Re: reproducible seg fault in 'aspell' when using 'eo_XX.UTF-8' locale

2011-07-29 Thread Brian Nelson
This is fixed in Debian's aspell packages version 0.60.6-6 and later.

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

Title:
  reproducible seg fault in 'aspell' when using 'eo_XX.UTF-8' locale

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

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


[Bug 188077] Re: ispell compatibility scripts in nonsensical place

2011-07-29 Thread Brian Nelson
They're now located in /usr/lib/aspell in the, errm, libaspell15 (in
Debian anyway), which I guess is slightly better.

They can't be installed in /usr/bin using the alternatives system since
they aren't fully functional drop-in replacements for the real
spell/ispell programs.  I'm not sure if they're even worth packaging at
all.

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

Title:
  ispell compatibility scripts in nonsensical place

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

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


[Bug 756494] Re: run-with-aspell does not work

2011-07-29 Thread Brian Nelson
This is fixed in Debian aspell packages version 0.60.6-5 and later.

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

Title:
  run-with-aspell does not work

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

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


[Bug 603427] Re: Empathy's spell-checker fails to recognize words with inflectional morphemes

2011-07-29 Thread Brian Nelson
This is not an aspell bug that I've seen, at least in the Debian aspell
packages.

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

Title:
  Empathy's spell-checker fails to recognize words with inflectional
  morphemes

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

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