Bug#845302: systemd: 232-6:Failed to boot, makes kernel panic when starting /sbin/init.

[K.Ohta]

Good morning, Michel, 

> What we don't know is, why /usr was not mounted for you by the
> initramfs. It should do that automatically.

This is caused by design-specification of systemd.
Summing up of below quote written by author of systemd ,
1.This issue is caused by design of systemd, Mainly to reduce security risk.
2. *THIS ISSUE WILL NOT FIX, SHOULD CHANGE PARTITION*.


Quote from:
http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
----
The Status Quo

Due to this, many upstream developers have decided to consider the problem of a 
separate /usr that is not mounted during early boot an outdated question, 
and started to close bugs regarding these issues as WONTFIX. 
We certainly cannot blame them, as the benefit of supporting this is questionable
 and brings a lot of additional work with it.

And let's clarify a few things:
    1.It isn't systemd's fault. systemd works fine with /usr on a separate file 
      system that is not pre-mounted at boot.
      systemd is merely the messenger. Don't shoot the messenger.
    2.There's no news in all of this. The message you saw is just a statement of fact,
      describing the status quo. Things have been this way since a while.
    3.The message is merely a warning. You can choose to ignore it.
    4.Don't blame us, don't abuse us, it's not our fault. We have been working 
      on the Linux userspace since quite some time, and simply have enough of 
      the constant bug reports regarding these issues, since they are actually 
      very hard to track down because the failures are mostly graceful. 
      Hence we placed this warning into the early boot process of every systemd 
      Linux system with a split off and not pre-mounted /usr, so that people 
      understand what is going on.
----
End Quote

I wonder I failed to boot without liblz4 in /lib/${ARCH} , but in your simulation VM,
booting without liblz4 in /lib/${ARCH}.

My idea is, adding new kernel command line parameters; this is bypass to systemd: systemd.{foo}
i.e: {foo} is usr_mount_dev and usr_mount_uuid , arg = device name ore UUID. 
If this parameter entry will be set, mount ${ARG} block-device to /usr directory.
 



On Tue, 22 Nov 2016 18:15:49 +0100
Michael Biebl <biebl at debian.org> wrote:

> Am 22.11.2016 um 18:01 schrieb K.Ohta:
> > Older systemd was built without liblz4, and liblz4 places
> > at /usr/lib/${ARCH} , problems of this my report had not happened.
> > But, now, systemd (maybe later than 232-5) is built with liblz4,
> > problem has happened (due to not placing liblz4 at /lib/${ARCH}).  
> 
> We are very well aware that liblz4 is in /usr and that this is a new
> dependency.
> 
> What we don't know is, why /usr was not mounted for you by the
> initramfs. It should do that automatically.

I'm using initramfs-tools 0.125 to assemble initramfs.

> 
> Can you provide the requested information, about your partitioning
> scheme: LVM, cryptsetup/LUKS, btrfs etc.

Pertitioning of core filesystems are a SSD and HDD.(Will replace HDD to another SSD)
SSD: ADATA 240GiB (/dev/sde)
HDD: Toshiba 3TiB (/dev/sdd)
Partition type of both disks are GPT.

Partition structure:
/      : sdd3, #8300, EXT4, 30GiB
/boot  : sde2, #8300, EXT4, 7.9Gib
/usr   : sde3, #8300, EXT4, 79.2GiB
/home  : sde4, #8300, EXT4, 134.0GiB
/var   : sdd5, #8300, XFS, 76.8GiB

All of partitions are simple partition, using neither LVM,Crypt Filesystem , and RAID.
Regards,

Ohta
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20161123/a4a5785d/attachment-0002.sig>