[PKG-Openstack-devel] Bug#784334: Bug#784334: Bug#784334: Inaccessible emergency shell on serial console

[Gaudenz Steinlin]

Hi Thomas

Taking this off the bug report as it's no longer relevant there.

Thomas Goirand <zigo at debian.org> writes:

> Gaudenz,
>
> first thanks a lot. This is very constructive, and I appreciate a lot 
> this kind of contribution, which I'm sure, everyone will enjoy a lot.
>
> About the quiet mode of the kernel, I'm really not sure. I've been 
> thinking about it for a long time, and I still can't make up my mind 
> about if we need the non-quiet output or not. Let me share what I have 
> in mind.
>
> All that kernel log is a lot of text wont be very useful. There's no 
> advantage, in the cloud use case to see it, as we don't expect any 
> kernel failures. More likely, if there's a problem, it will be because 
> of something else (cloud-init, networking, etc.).
>
> Why do you think kernel logs is useful?

I don't care that much about the kernel logs, but quiet suppreses much
more than just the kernel logs. It also makes the systemd output much
more terse. I think it's usefull to see which services were started in
which order.

And I'm not very convinced that we are really not interested in the
kernel logs either. If things go wrong, there may very well be a hint in
there. I don't think they hurt in any way, so I would enable them.

>
> On 05/18/2015 04:39 PM, Gaudenz Steinlin wrote:
>> BTW, why are you using extlinux instead of grub2 which is the standard
>> bootloader in Debian?
>
> The only advantage of Grub is to provide an interactive boot menu, which 
> IMO doesn't fit in the cloud use case. So I found that syslinux is much 
> better because more lightweight. However, I may revisit this so that the 
> image could work better for Xen.

One other advantage of grub is that it's much better integrated into the
Debian system. update-grub is automatically called and makes sure that
it always boots the latest kernel with all security fixes. It also
automatically adds a rescue option.

I agree that both, the kernel logs and the bootloader are more an issue
if you take the Debian image as the base for a volume and customize it
from there. If you just start an instance from it, things probably won't
go wrong and you won't need these debugging options.

>
>> And one more thing. Why is the string "7.0.0-3" hardcoded into the image
>> filename?
>
> This has been fixed in the last version in Sid. The only thing which I 
> didn't do is fix the minor version.
>
>> I would suggest to either just use debian-${RELEASE}-amd64 or
>> read the version number from /etc/debian_version (after debootstrap of
>> course and read from ${MOUNT_DIR}/etc/debian_version, we don't want the
>> version of the build host in the filename).
>
> Sure. But this means renaming the output file after the facts, which we 
> may not want to do. Best would be to find a way to know what the is the 
> current point release number out of a wget / curl command (or something 
> like this...). I'm opened to any suggestion for this.

I don't see why creating the image to a temporary file that get's
renamed at the end is problematic. I'd prefer that to the hardcoded
version number.

But if you find a way to get the version number before starting the
build that's fine too. I just don't know how to do this and don't see
any advantage in doing so.

>
> Also, I'd like to add a --output-file option: it's trivial to implement, 
> and may be useful.

That's a good idea anyway. Agreeed.

Gaudenz