touch-packages team mailing list archive

[Robert Hardy <1460794@xxxxxxxxxxxxxxxxxx>]

On 2015-06-10 08:59, Martin Pitt wrote:
> The "/usr appears to be on its own filesystem ..." is just a warning.
> Booting with separate /usr is supported, as long as it's a local
> partition and not a remote one (the latter could work, but really nobody
> tests this). I just did a 15.04 installation with separate /usr, and it
> works fine.
>
> Could there be something wrong with your /etc/fstab perhaps? Maybe some
> UUID mismatch or so? In the emergency shell, can you please do
>
>    journalctl -b > /root/journal.txt
>    blkid > /root/blkid.txt
>
> and attach /etc/fstab, /root/blkid.txt, and /root/journal.txt here?
> Thanks!
>
> ** Summary changed:
>
> - systemd will not work with a separate /usr partition
> + systemd does not boot with a separate /usr partition
>
> ** Changed in: systemd (Ubuntu)
>         Status: New => Incomplete
>

I've been working with Linux for 20 years, I really doubt there was 
anything wrong with my fstab. The system configuration had been working 
perfectly since it was installed using Ubuntu 10.04 several years ago.

The upgrade from 14.04 to 14.10 worked fine. It was the 14.10 to 15.05 
upgrade that blew up.

It was not just a warning. The system and emergency mode were both 
unusable until I switched back to upstart.

Even after the switch to upstart the 15.04 system would only boot only 
with manual intervention on the console during every boot as /var 
stopped being automatically mounted.

The system sat there with an error not booting until I manually did a 
mount -av from emergency mode and then continued the boot process.  This 
happened on each and every boot.

In my honest opinion to test this properly you would have to test a 
system which had been upgraded from 14.04 with a similar layout with 
separate ext4 partitions. You might get away with starting at 14.10...

This was a total system failure on a production server over ten days 
ago. I couldn't just leave it failed state for two weeks. The journalctl 
and blkid commands would only show the current system state after all 
was rebuilt, where everything is working fine. Do you still want them?

As I indicated previously in my comments I was forced to wipe all my 
partitions from a rescue disk and switch to a boot, root, home partition 
layout abandoning my previous system layout. I then restored from backups.

I was able to restore my old /etc/fstab from a backup. Before the 
upgrade it was as follows:
# /etc/fstab: static file system information.
#
# Use 'blkid -o value -s UUID' to print the universally unique identifier
# for a device; this may be used with UUID= as a more robust way to name
# devices that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type> <options>       <dump>  <pass>
proc            /proc           proc    nodev,noexec,nosuid 0       0
# / was on /dev/sda1 during installation
UUID=676235cd-93b1-426e-8336-fa0078d96145 / ext4    errors=remount-ro 
0       1
/dev/mapper/Guru2VG1-home /home           xfs defaults        0       2
/dev/mapper/Guru2VG1-tmp /tmp            ext4 defaults        0       2
/dev/mapper/Guru2VG1-usr /usr            ext4 defaults        0       2
/dev/mapper/Guru2VG1-var /var            ext4 defaults        0       2
cgroup                   /dev/cgroup     cgroup defaults        0       0
# swap was on /dev/sda2 during installation
UUID=217f140d-f4ad-45a3-9486-9e3af1734f0d none swap    sw              
0       0
UUID=3a482248-399d-4fbd-aa1d-e013343b44e5 /mnt/backups               
xfs    defaults 0       0
UUID=99649f74-7be3-427a-9eef-65a1b2922196 /mnt/tmp               xfs    
defaults 0       0

All a journalctl -b would gather now would be the boot log data 9 days 
after this was all fixed. The log only goes back 3 days. The blkid would 
capture uuids for the new partitions. Do you still want those? Perhaps 
other logs would be more helpful? I do have nightly backups.

Regards,
Robert Hardy

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1460794

Title:
  systemd does not boot with a separate /usr partition

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  I recently upgraded a server from 14.10 to 15.04. The upgrade claim to
  have worked but the system could not boot afterwards.

  Basically when you attempt to reboot you end up at an emergency maintenance prompt early in the boot process.
  After a lot of digging one of the messages in the logs gives:
  systemd[1]: /usr appears to be on its own filesystem and is not already mounted. This is not a supported setup. Some things will probably break (sometimes even silently) in mysterious ways. Consult http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

  Basically systemd cannot deal with /usr being on a separate partition.
  That needs to be fixed or systemd should not be used for upgrades with
  a separate /usr partition.

  This is related to bug 1460790 but asking for systemd to actually be fixed.
  Please see bug 1460790 if you are looking for a work around on this issue.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: systemd 219-7ubuntu5
  ProcVersionSignature: Ubuntu 3.19.0-18.18-generic 3.19.6
  Uname: Linux 3.19.0-18-generic x86_64
  ApportVersion: 2.17.2-0ubuntu1.1
  Architecture: amd64
  Date: Mon Jun  1 15:29:32 2015
  InstallationDate: Installed on 2010-05-23 (1835 days ago)
  InstallationMedia: Ubuntu-Server 10.04 LTS "Lucid Lynx" - Release amd64 (20100427)
  MachineType: Supermicro X8STi
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=<set>
   LANG=en_CA.UTF-8
   SHELL=/bin/tcsh
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-18-generic root=UUID=676235cd-93b1-426e-8336-fa0078d96145 ro quiet acpi=off pci=noacpi
  SourcePackage: systemd
  UpgradeStatus: Upgraded to vivid on 2015-06-01 (0 days ago)
  dmi.bios.date: 09/17/10
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 2.0
  dmi.board.asset.tag: To Be Filled By O.E.M.
  dmi.board.name: X8STi
  dmi.board.vendor: Supermicro
  dmi.board.version: 1234567890
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: Supermicro
  dmi.chassis.version: 1234567890
  dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2.0:bd09/17/10:svnSupermicro:pnX8STi:pvr1234567890:rvnSupermicro:rnX8STi:rvr1234567890:cvnSupermicro:ct3:cvr1234567890:
  dmi.product.name: X8STi
  dmi.product.version: 1234567890
  dmi.sys.vendor: Supermicro

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