[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#445148: S390: Build w/ /boot partition succeeds, but re-boot fails in fsck



severity 445148 serious
reassign 445148 debian-installer 20070308
thanks

On Monday 08 October 2007, Frans Pop wrote:
> This does not seem to be an installation problem. Instead it looks like
> either the boot loader or the kernel is not releasing the partition
> holding /boot after the kernel and/or the initrd have been loaded.

It is an installation problem after all.
Basically, on boot the dasds for / (LVM) and /boot are swapped. See [1] for 
a detailed analysis.

The correct repair for the issue is as follows:
- enter the administrator password when requested
- type 'exit' when in the root shell; this will complete the boot process
- edit /etc/fstab and use /dev/disk/by-path device names for _all_
  partitions, for example (check /dev/disk/by-path for correct names):

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc                                  /proc  proc    defaults       0     0
/dev/disk/by-path/ccw-0.0.0123-part1  /      ext3    defaults,[...] 0     1
/dev/disk/by-path/ccw-0.0.0122-part1  /boot  ext3    defaults       0     2
/dev/disk/by-path/ccw-0.0.0122-part2  none   swap    sw             0     0

- reboot

To the D-I team
---------------
This is a fairly difficult issue as there is not really an easy solution or 
an obvious D-I component that is the culprit (to mind come s390-dasd, 
partman-target, udev-udeb, initramfs-tools and zipl-installer). Therefore 
assigning to d-i itself.

This issue should IMO definitely be listed in the errata for Etch.

I also think the issue is broader than just this use case. Basically any 
setup that has / on a different dasd than the first one configured in 
s390-dasd is broken.
AFAICT any setup in which during s390-dasd dasds are configured in a 
different order than their numeric sort order, will *also* be broken as 
their device names after reboot will be different from what they were 
during installation.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=58;bug=445148

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: