Bug#535331: ditto

2009-11-07 Thread Josip Rodin
On Fri, Oct 23, 2009 at 11:54:21AM +0200, Josip Rodin wrote:
 I've experienced the same problem. I've got two lenny machines which have
[...]

FWIW Here's the last upgrade output pasted exactly as it just happened:

% sudo apt-get upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be upgraded:
  linux-image-2.6.26-2-686
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 20,2MB of archives.
After this operation, 0B of additional disk space will be used.
Do you want to continue [Y/n]? 
Get:1 http://security.debian.org lenny/updates/main linux-image-2.6.26-2-686 
2.6.26-19lenny2 [20,2MB]
Fetched 20,2MB in 21s (929kB/s)
Preconfiguring packages ...
(Reading database ... 24703 files and directories currently installed.)
Preparing to replace linux-image-2.6.26-2-686 2.6.26-19lenny1 (using 
.../linux-image-2.6.26-2-686_2.6.26-19lenny2_i386.deb) ...
The directory /lib/modules/2.6.26-2-686 still exists. Continuing as directed.
Done.
Unpacking replacement linux-image-2.6.26-2-686 ...
Setting up linux-image-2.6.26-2-686 (2.6.26-19lenny2) ...
Running depmod.
Running mkinitramfs-kpkg.
Not updating initrd symbolic links since we are being updated/reinstalled 
(2.6.26-19lenny1 was configured last, according to dpkg)
Not updating image symbolic links since we are being updated/reinstalled 
(2.6.26-19lenny1 was configured last, according to dpkg)
% 

% sudo perl -pi -e 's,^(my \$loader\s+=\s+),$1lilo,' 
/var/lib/dpkg/info/linux-image-2.6.26-2-686.postinst

% sudo dpkg-reconfigure linux-image-2.6.26-2-686
Running depmod.
Running mkinitramfs-kpkg.
Not updating initrd symbolic links since we are being updated/reinstalled 
(2.6.26-19lenny2 was configured last, according to dpkg)
Not updating image symbolic links since we are being updated/reinstalled 
(2.6.26-19lenny2 was configured last, according to dpkg)
You already have a LILO configuration in /etc/lilo.conf
Running boot loader as requested
Testing lilo.conf ... 
Testing successful.
Installing the partition boot sector... 
Running /sbin/lilo  ... 
Installation successful.
% 

 [...] after upgrading linux-image-2.6.26-2-686, I just get [...]

FWIW it also happens on the amd64 version, exactly the same:

% sudo apt-get upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be upgraded:
  linux-image-2.6.26-2-amd64
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 20,9MB of archives.
After this operation, 4096B of additional disk space will be used.
Do you want to continue [Y/n]? 
Get:1 http://security.debian.org lenny/updates/main linux-image-2.6.26-2-amd64 
2.6.26-19lenny2 [20,9MB]
Fetched 20,9MB in 20s (1013kB/s)   
Preconfiguring packages ...
(Reading database ... 20849 files and directories currently installed.)
Preparing to replace linux-image-2.6.26-2-amd64 2.6.26-19lenny1 (using 
.../linux-image-2.6.26-2-amd64_2.6.26-19lenny2_amd64.deb) ...
The directory /lib/modules/2.6.26-2-amd64 still exists. Continuing as directed.
Done.
Unpacking replacement linux-image-2.6.26-2-amd64 ...
Setting up linux-image-2.6.26-2-amd64 (2.6.26-19lenny2) ...
Running depmod.
Running mkinitramfs-kpkg.
Not updating initrd symbolic links since we are being updated/reinstalled 
(2.6.26-19lenny1 was configured last, according to dpkg)
Not updating image symbolic links since we are being updated/reinstalled 
(2.6.26-19lenny1 was configured last, according to dpkg)
% 

% sudo perl -pi -e 's,^(my \$loader\s+=\s+),$1lilo,' 
/var/lib/dpkg/info/linux-image-2.6.26-2-amd64.postinst

% sudo dpkg-reconfigure linux-image-2.6.26-2-amd64
Running depmod.
Running mkinitramfs-kpkg.
Not updating initrd symbolic links since we are being updated/reinstalled 
(2.6.26-19lenny2 was configured last, according to dpkg)
Not updating image symbolic links since we are being updated/reinstalled 
(2.6.26-19lenny2 was configured last, according to dpkg)
You already have a LILO configuration in /etc/lilo.conf
Running boot loader as requested
Testing lilo.conf ... 
Testing successful.
Installing the partition boot sector... 
Running /sbin/lilo  ... 
Installation successful.
% 

-- 
 2. That which causes joy or happiness.



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#535331: ditto

2009-10-23 Thread Josip Rodin
Hi,

I've experienced the same problem. I've got two lenny machines which have
GPT paritition tables and Linux root on LVM, and they can't use anything but
LILO (there are some novelty hacks for GRUB but I haven't been able to test
them yet because this is in production). I have kernel-img.conf set up
right, but after upgrading linux-image-2.6.26-2-686, I just get the not
updating symbolic links messages and no triggers or boot loaders are run.
If left unattended, this typically renders these two systems unbootable.

It really looks like a failure to define the $loader variable in the
predefined variables section. If I just put 'lilo' in there and re-run
dpkg-reconfigure linux-image-2.6.26-2-686, the output changes to:

Running depmod.
Running mkinitramfs-kpkg.
Not updating initrd symbolic links since we are being updated/reinstalled 
(2.6.26-19lenny1 was configured last, according to dpkg)
Not updating image symbolic links since we are being updated/reinstalled 
(2.6.26-19lenny1 was configured last, according to dpkg)
You already have a LILO configuration in /etc/lilo.conf
Running boot loader as requested
Testing lilo.conf ... 
Testing successful.
Installing the partition boot sector... 
Running /sbin/lilo  ... 
Installation successful.

This is what would be expected. The run_lilo() function goes out of its way
to determine whether the existence of /etc/lilo.conf is sufficient reason to
run lilo, so there doesn't appear to be any reason to completely omit it.

-- 
 2. That which causes joy or happiness.



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#535331: ditto

2009-10-23 Thread maximilian attems
On Fri, Oct 23, 2009 at 11:54:21AM +0200, Josip Rodin wrote:
 Hi,
 
 I've experienced the same problem. I've got two lenny machines which have
 GPT paritition tables and Linux root on LVM, and they can't use anything but
 LILO (there are some novelty hacks for GRUB but I haven't been able to test
 them yet because this is in production). I have kernel-img.conf set up
 right, but after upgrading linux-image-2.6.26-2-686, I just get the not
 updating symbolic links messages and no triggers or boot loaders are run.
 If left unattended, this typically renders these two systems unbootable.
 
 It really looks like a failure to define the $loader variable in the
 predefined variables section. If I just put 'lilo' in there and re-run
 dpkg-reconfigure linux-image-2.6.26-2-686, the output changes to:
 
 Running depmod.
 Running mkinitramfs-kpkg.
 Not updating initrd symbolic links since we are being updated/reinstalled 
 (2.6.26-19lenny1 was configured last, according to dpkg)
 Not updating image symbolic links since we are being updated/reinstalled 
 (2.6.26-19lenny1 was configured last, according to dpkg)
 You already have a LILO configuration in /etc/lilo.conf
 Running boot loader as requested
 Testing lilo.conf ... 
 Testing successful.
 Installing the partition boot sector... 
 Running /sbin/lilo  ... 
 Installation successful.
 
 This is what would be expected. The run_lilo() function goes out of its way
 to determine whether the existence of /etc/lilo.conf is sufficient reason to
 run lilo, so there doesn't appear to be any reason to completely omit it.

from the affected box:
cat /etc/kernel-img.conf



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#535331: ditto

2009-10-23 Thread Josip Rodin
On Fri, Oct 23, 2009 at 01:15:52PM +0200, maximilian attems wrote:
 On Fri, Oct 23, 2009 at 11:54:21AM +0200, Josip Rodin wrote:
  Hi,
  
  I've experienced the same problem. I've got two lenny machines which have
  GPT paritition tables and Linux root on LVM, and they can't use anything but
  LILO (there are some novelty hacks for GRUB but I haven't been able to test
  them yet because this is in production). I have kernel-img.conf set up
  right, but after upgrading linux-image-2.6.26-2-686, I just get the not
  updating symbolic links messages and no triggers or boot loaders are run.
  If left unattended, this typically renders these two systems unbootable.
  
  It really looks like a failure to define the $loader variable in the
  predefined variables section. If I just put 'lilo' in there and re-run
  dpkg-reconfigure linux-image-2.6.26-2-686, the output changes to:
  
  Running depmod.
  Running mkinitramfs-kpkg.
  Not updating initrd symbolic links since we are being updated/reinstalled 
  (2.6.26-19lenny1 was configured last, according to dpkg)
  Not updating image symbolic links since we are being updated/reinstalled 
  (2.6.26-19lenny1 was configured last, according to dpkg)
  You already have a LILO configuration in /etc/lilo.conf
  Running boot loader as requested
  Testing lilo.conf ... 
  Testing successful.
  Installing the partition boot sector... 
  Running /sbin/lilo  ... 
  Installation successful.
  
  This is what would be expected. The run_lilo() function goes out of its way
  to determine whether the existence of /etc/lilo.conf is sufficient reason to
  run lilo, so there doesn't appear to be any reason to completely omit it.
 
 from the affected box:
 cat /etc/kernel-img.conf

I fail to see the benefit, but here goes - on both it's identical:

% cat /etc/kernel-img.conf
# Kernel image management overrides
# See kernel-img.conf(5) for details
do_symlinks = yes
relative_links = yes
do_bootloader = yes
do_bootfloppy = no
do_initrd = yes
link_in_boot = yes

-- 
 2. That which causes joy or happiness.



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org