Debian install using LVM

[Viktor Mihajlovski]

Hello,

I've been fighting with a Debian install all day and wonder if anyone else
has run into the same problem. I wanted to use LVM for the root filesystem,
so created a /boot partition and an LVM for the rest. Everything works fine
until it comes to the step where it tries to write out ZIPL. That step fails.
I tried all sorts of combinations, but the only that actually works is
creating 1 partition for / with no LVM at all. Something is not right.
The timestamp on the install files I'm using is April 2, so they are pretty
new. The level of Debian is jessie.

I recommend to try testing aka stretch. There were LVM fixes uploaded
there. As usual do attach /var/log/syslog from the d-i to help
debugging what's going wrong.

That is exactly the point, Debian Jessie's installer only accepts the
root device on a DASD partition. With Stretch, root can be anywhere
including LVM volumes.

https://lists.debian.org/debian-s390/
Regards,
Dimitri.

[...]

[Viktor Mihajlovski]

Hello,

Mark,
I've been using the installer, so I don't get to see the underlying config
files. I'll try it again and see if I can get to /etc/zipl.conf. The
installer doesn't say why it can't write out ZIPL, just that it cannot. I
tried partitioning /boot and formatting it ext2 (which is the way we do
SLES12), then partitioning the rest of the volume as /. It doesn't seem to
like that either.
It is at least comforting to know I'm not the only one who has run into this
issue.

I think we really should do stable release uploads in Debian of the
fixes to have LVM working on jessie for the next point release.
Because clearly there are users after it like yourself =)
Regards,
Dimitri.

The LVM on DASD issue should be resolved by bumping the release level of
zipl-installer to either 0.0.28 or 0.0.32 (preferable) in the next point
release. Since this addresses an installability problem, I would hope
that such an update would be acceptable.

Martha

I've been fighting with a Debian install all day and wonder if anyone else
has run into the same problem. I wanted to use LVM for the root filesystem,
so created a /boot partition and an LVM for the rest. Everything works fine
until it comes to the step where it tries to write out ZIPL. That step
fails.

By "that step" do you mean something the installer is doing that you can't tell
exactly what is happening? Or is it a command you're running yourself?

I tried all sorts of combinations, but the only that actually works is
creating 1 partition for / with no LVM at all. Something is not right.

While I don't personally care for this kind of setup, it should be fairly
straightforward. /boot needs to be mounted at the time zipl is run. It needs
to have a file system of ext*, xfs, reiserfs, etc. on it, not something like
btrfs.
What do the contents of /etc/zipl.conf look like? What are the messages you're
getting back that indicate failure?
Mark Post
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

--
Regards,
Dimitri.
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

[Philipp Kern]

Post by Viktor Mihajlovski
The LVM on DASD issue should be resolved by bumping the release level of
zipl-installer to either 0.0.28 or 0.0.32 (preferable) in the next point
release. Since this addresses an installability problem, I would hope
that such an update would be acceptable.

I'll need to look at the diff, but it'd be helpful to have a
confirmation that this is all that's needed. (E.g. by rebuilding
jessie's d-i with just this one udeb built for jessie.)

Kind regards and thanks
Philipp Kern

[Viktor Mihajlovski]

Post by Philipp Kern

Post by Viktor Mihajlovski
The LVM on DASD issue should be resolved by bumping the release level of
zipl-installer to either 0.0.28 or 0.0.32 (preferable) in the next point
release. Since this addresses an installability problem, I would hope
that such an update would be acceptable.

I'll need to look at the diff, but it'd be helpful to have a
confirmation that this is all that's needed. (E.g. by rebuilding
jessie's d-i with just this one udeb built for jessie.)
Kind regards and thanks
Philipp Kern

True, there could be more than that. I'll take a stab at it and post my
results...

[Viktor Mihajlovski]

Post by Philipp Kern

Post by Viktor Mihajlovski
The LVM on DASD issue should be resolved by bumping the release level of
zipl-installer to either 0.0.28 or 0.0.32 (preferable) in the next point
release. Since this addresses an installability problem, I would hope
that such an update would be acceptable.

I'll need to look at the diff, but it'd be helpful to have a
confirmation that this is all that's needed. (E.g. by rebuilding
jessie's d-i with just this one udeb built for jessie.)
Kind regards and thanks
Philipp Kern

Well, I had encouraging but mixed results: with the
zipl-installer_0.0.32 udeb the boot setup was completed correctly.
However, the system still didn't get up because the DASD(s) holding the
root LV were not set online in the initramfs because the
sysconfig-hardware in Jessie lacks the initramfs hooks (you wrote that
in your blog back in October but I forgot that...).
Enabling the DASD in the emergency shell and activating the volume group
led to successful completion of the system boot.

That means it will be necessary to also update the sysconfig-hardware
package (e.g. to 0.0.10+nmu4)). I lack the skills to tweak my Jessie
mirror to upgrade the package there, so there's a still some residual risk.