Bug#762984: Alert! /dev/vg0/usr does not exist
On Thu, 27 Nov 2014 11:51:48 + Simon McVittie s...@debian.org wrote: On Wed, 01 Oct 2014 at 22:18:53 +0100, Ben Hutchings wrote: I suspect this is essentially the same bug as #616689 and #678696, except that now it may affect mounting /usr as well as /. I think this bug report is actually describing more than one bug in more than one package that have similar symptoms. There might be things that can be fixed in mdadm and lvm2 to fix the initramfs-tools/0.117 regressions without needing to implement a full event-driven setup in initramfs-tools. [...] LVM (Elimar's System 1, Sven, Torsten, IOhannes, Javier) In the LVM case, debian/initramfs-tools/lvm2/scripts/local-top does this: activate_vg $ROOT activate_vg $resume Note the lack of handling for /usr here. Further, activate_vg uses lvm lvchange to activate only the LV necessary for the root filesystem; if /usr is on a separate VG, it's not going to work. This on its own would be enough to make Sven Hartge's system fail: /usr needs a LVM partition activated that / does not. Similarly, I think Elimar's System 1 is going to activate vg0/root but not vg0/usr. [...] The ideal thing in both of these situations would be to use the same logic as *mounting* /usr - mount the rootfs first, then read its fstab to find out where /usr is, avoiding hard-coding that knowledge into the initramfs - but I think that would need a significantly more complicated hook structure. I'm proposing to add another hook for this, which will initially only be implemented by lvm2. So far as I can see, mdadm and lvm2 have to find the required devices in different ways: - mdadm cannot generally tell which RAID arrays are needed, as the root device may be identified by filesystem UUID or LV name but it only works with RAID array UUIDs and the component device names - lvm2 can tell exactly which VG is needed as a root device on an LV is identified by VG and LV name The same goes for mounting /usr. Ben. -- Ben Hutchings The first rule of tautology club is the first rule of tautology club. signature.asc Description: This is a digitally signed message part
Bug#762984: Alert! /dev/vg0/usr does not exist
Control: clone 762984 -2 Control: retitle 762984 cannot mount /usr if it is a separate LVM LV: Alert! /dev/vg0/usr does not exist Control: retitle -2 cannot mount /usr if INITRDSTART in /etc/default/mdadm does not include the necessary device On Thu, 27 Nov 2014 at 21:09:09 +0100, Elimar Riesebieter wrote: * Simon McVittie s...@debian.org [2014-11-27 11:51 +]: I think this bug report is actually describing more than one bug in more than one package that have similar symptoms. ... Elimar Riesebieter's System 2 has a bunch of mdadm (RAID) partitions. Elimar, what is in your /etc/default/mdadm on System 2 (and System 1 for that matter)? I predict that the answer includes something like INITRDSTART=/dev/md6. Right, adding root and usr raid partitions to INITRDSTART like INITRDSTART='/dev/md3 /dev/md5' or just 'all' does the job. I'm splitting off the situation on your System 2 into a separate bug, because as far as I can see, this is the only part of this report that does not involve LVM. Some of the other reports do involve RAID arrays, but none of them seem to require bringing up additional RAID arrays in the initramfs (that were not already needed for the root filesystem), so they could all be fixed with only LVM-related changes. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762984: Alert! /dev/vg0/usr does not exist
On Wed, 01 Oct 2014 at 22:18:53 +0100, Ben Hutchings wrote: I suspect this is essentially the same bug as #616689 and #678696, except that now it may affect mounting /usr as well as /. I think this bug report is actually describing more than one bug in more than one package that have similar symptoms. There might be things that can be fixed in mdadm and lvm2 to fix the initramfs-tools/0.117 regressions without needing to implement a full event-driven setup in initramfs-tools. RAID (Elimar, Sven) Elimar Riesebieter's System 2 has a bunch of mdadm (RAID) partitions. Elimar, what is in your /etc/default/mdadm on System 2 (and System 1 for that matter)? I predict that the answer includes something like INITRDSTART=/dev/md6. The problem here seems to be that mdadm tries to determine a minimal set of multi-disk partitions need to be assembled by the initramfs based on the assumption that the initramfs only needs the root device; but initramfs-tools = 0.117 wants to mount /usr as well, so that assumption is no longer true. So it might be necessary to modify mdadm so that, if /usr is a separate filesystem on (a LVM VG on) a MD array, it will try to prepare that too. LVM (Elimar's System 1, Sven, Torsten, IOhannes, Javier) In the LVM case, debian/initramfs-tools/lvm2/scripts/local-top does this: activate_vg $ROOT activate_vg $resume Note the lack of handling for /usr here. Further, activate_vg uses lvm lvchange to activate only the LV necessary for the root filesystem; if /usr is on a separate VG, it's not going to work. This on its own would be enough to make Sven Hartge's system fail: /usr needs a LVM partition activated that / does not. Similarly, I think Elimar's System 1 is going to activate vg0/root but not vg0/usr. We don't have enough information in this bug report to know what layout Torsten, IOhannes, Javier used on their systems, but we can guess from the fact that vgchange -a y is a successful workaround... I predict that these are LVM over either a single RAID array, or real partitions. The ideal thing in both of these situations would be to use the same logic as *mounting* /usr - mount the rootfs first, then read its fstab to find out where /usr is, avoiding hard-coding that knowledge into the initramfs - but I think that would need a significantly more complicated hook structure. Perhaps modifying mdadm and lvm2 so they will set up enough md/lvm bits for /usr in the initramfs would be sufficient for a 95% solution? S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762984: Alert! /dev/vg0/usr does not exist
* Simon McVittie s...@debian.org [2014-11-27 11:51 +]: On Wed, 01 Oct 2014 at 22:18:53 +0100, Ben Hutchings wrote: I suspect this is essentially the same bug as #616689 and #678696, except that now it may affect mounting /usr as well as /. I think this bug report is actually describing more than one bug in more than one package that have similar symptoms. There might be things that can be fixed in mdadm and lvm2 to fix the initramfs-tools/0.117 regressions without needing to implement a full event-driven setup in initramfs-tools. RAID (Elimar, Sven) Elimar Riesebieter's System 2 has a bunch of mdadm (RAID) partitions. Elimar, what is in your /etc/default/mdadm on System 2 (and System 1 for that matter)? I predict that the answer includes something like INITRDSTART=/dev/md6. Right, adding root and usr raid partitions to INITRDSTART like INITRDSTART='/dev/md3 /dev/md5' or just 'all' does the job. There is no need to involve initramfs to mount /usr before init. [...] LVM (Elimar's System 1, Sven, Torsten, IOhannes, Javier) In the LVM case, debian/initramfs-tools/lvm2/scripts/local-top does this: activate_vg $ROOT activate_vg $resume Note the lack of handling for /usr here. Further, activate_vg uses lvm lvchange to activate only the LV necessary for the root filesystem; if /usr is on a separate VG, it's not going to work. This on its own would be enough to make Sven Hartge's system fail: /usr needs a LVM partition activated that / does not. Similarly, I think Elimar's System 1 is going to activate vg0/root but not vg0/usr. Right! We don't have enough information in this bug report to know what layout Torsten, IOhannes, Javier used on their systems, but we can guess from the fact that vgchange -a y is a successful workaround... I predict that these are LVM over either a single RAID array, or real partitions. The ideal thing in both of these situations would be to use the same logic as *mounting* /usr - mount the rootfs first, then read its fstab to find out where /usr is, avoiding hard-coding that knowledge into the initramfs - but I think that would need a significantly more complicated hook structure. Perhaps modifying mdadm and lvm2 so they will set up enough md/lvm bits for /usr in the initramfs would be sufficient for a 95% solution? What do you propose to adapt it to lvm2? Why should we avoid hardcoding via /etc/initramfs-tools/scripts? Maybe a move from /usr/share/initramfs-tools/scripts/local-top/lvm2 to /lib/initramfs-tools/scripts/local-top/lvm2 should work? Elimar -- Learned men are the cisterns of knowledge, not the fountainheads ;-) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762984: Alert! /dev/vg0/usr does not exist
On 27/11/14 20:09, Elimar Riesebieter wrote: Right, adding root and usr raid partitions to INITRDSTART like INITRDSTART='/dev/md3 /dev/md5' or just 'all' does the job. There is no need to involve initramfs to mount /usr before init. If your init is systemd, initramfs-tools = 0.117 *does* automatically mount /usr before init, to ensure that rootfs - /usr interdependencies can never be a problem (for instance third-party udev rules often need helpers in /usr). That's the feature that I'm trying to get migratable into testing, because when it works, it'll make the boot sequence a lot simpler; but it's also the feature that caused this regression. (It was meant to do the same for non-systemd too, but initscripts doesn't currently support that.) Perhaps modifying mdadm and lvm2 so they will set up enough md/lvm bits for /usr in the initramfs would be sufficient for a 95% solution? What do you propose to adapt it to lvm2? Why should we avoid hardcoding via /etc/initramfs-tools/scripts? Maybe a move from /usr/share/initramfs-tools/scripts/local-top/lvm2 to /lib/initramfs-tools/scripts/local-top/lvm2 should work? No, whether /usr/share/initramfs-tools is on the rootfs is irrelevant: it's only used when update-initramfs is run, on a fully booted system, usually as a result of a dpkg run. What the initramfs does is currently (in pseudocode): * (hook provided by cryptsetup) decrypt encrypted volumes needed for / or swap * (hook provided by mdadm) start RAID arrays needed for / or swap * (hook provided by lvm2) start LVM volumes needed for / or swap * (basic functionality of initramfs-tools) if swap contains a hibernation image, resume from it * (basic functionality of initramfs-tools) mount / * (basic functionality of initramfs-tools) if /usr is a separate filesystem, mount it * (basic functionality of initramfs-tools) run the real init The patch I attached to #767832 changes the cryptsetup step to decrypt encrypted volumes needed for /, /usr or swap so that, when we get to the mount /usr step, it actually works, even if /usr is on an encrypted volume. What I'm saying is that lvm2 and mdadm are going to need changes similar to the one I proposed on #767832, so that mount /usr works if /usr is on a separate LVM or RAID volume. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762984: Alert! /dev/vg0/usr does not exist
* Simon McVittie s...@debian.org [2014-11-27 21:19 +]: On 27/11/14 20:09, Elimar Riesebieter wrote: Right, adding root and usr raid partitions to INITRDSTART like INITRDSTART='/dev/md3 /dev/md5' or just 'all' does the job. There is no need to involve initramfs to mount /usr before init. If your init is systemd, initramfs-tools = 0.117 *does* automatically mount /usr before init, to ensure that rootfs - /usr interdependencies can never be a problem (for instance third-party udev rules often need helpers in /usr). Not always. If the raid partition for /usr isn't initialized it can't be mounted, though. That's the feature that I'm trying to get migratable into testing, because when it works, it'll make the boot sequence a lot simpler; but it's also the feature that caused this regression. We have to catch the case whether /usr is on a seperated raid partition here! (It was meant to do the same for non-systemd too, but initscripts doesn't currently support that.) Doesn't matter Perhaps modifying mdadm and lvm2 so they will set up enough md/lvm bits for /usr in the initramfs would be sufficient for a 95% solution? What do you propose to adapt it to lvm2? Why should we avoid hardcoding via /etc/initramfs-tools/scripts? Maybe a move from /usr/share/initramfs-tools/scripts/local-top/lvm2 to /lib/initramfs-tools/scripts/local-top/lvm2 should work? No, whether /usr/share/initramfs-tools is on the rootfs is irrelevant: it's only used when update-initramfs is run, on a fully booted system, usually as a result of a dpkg run. What the initramfs does is currently (in pseudocode): * (hook provided by cryptsetup) decrypt encrypted volumes needed for / or swap * (hook provided by mdadm) start RAID arrays needed for / or swap Only if initialized by INITRDSTART * (hook provided by lvm2) start LVM volumes needed for / or swap * (basic functionality of initramfs-tools) if swap contains a hibernation image, resume from it * (basic functionality of initramfs-tools) mount / * (basic functionality of initramfs-tools) if /usr is a separate filesystem, mount it Only if initialized by INITRDSTART * (basic functionality of initramfs-tools) run the real init The patch I attached to #767832 changes the cryptsetup step to decrypt encrypted volumes needed for /, /usr or swap so that, when we get to the mount /usr step, it actually works, even if /usr is on an encrypted volume. Will have a further look at it on weekend Elimar -- Numeric stability is probably not all that important when you're guessing;-) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762984: Alert! /dev/vg0/usr does not exist
Hello Simon, (I'm dropping CCs, I'm not sure if all body is ok with maintaining such CC list, sorry if somebody have would like to be in CC) On Thu, Nov 27, 2014 at 12:51 PM, Simon McVittie s...@debian.org wrote: On Wed, 01 Oct 2014 at 22:18:53 +0100, Ben Hutchings wrote: I suspect this is essentially the same bug as #616689 and #678696, except that now it may affect mounting /usr as well as /. I think this bug report is actually describing more than one bug in more than one package that have similar symptoms. There might be things that can be fixed in mdadm and lvm2 to fix the initramfs-tools/0.117 regressions without needing to implement a full event-driven setup in initramfs-tools. RAID (Elimar, Sven) Elimar Riesebieter's System 2 has a bunch of mdadm (RAID) partitions. Elimar, what is in your /etc/default/mdadm on System 2 (and System 1 for that matter)? I predict that the answer includes something like INITRDSTART=/dev/md6. The problem here seems to be that mdadm tries to determine a minimal set of multi-disk partitions need to be assembled by the initramfs based on the assumption that the initramfs only needs the root device; but initramfs-tools = 0.117 wants to mount /usr as well, so that assumption is no longer true. So it might be necessary to modify mdadm so that, if /usr is a separate filesystem on (a LVM VG on) a MD array, it will try to prepare that too. LVM (Elimar's System 1, Sven, Torsten, IOhannes, Javier) In the LVM case, debian/initramfs-tools/lvm2/scripts/local-top does this: activate_vg $ROOT activate_vg $resume Note the lack of handling for /usr here. Further, activate_vg uses lvm lvchange to activate only the LV necessary for the root filesystem; if /usr is on a separate VG, it's not going to work. This on its own would be enough to make Sven Hartge's system fail: /usr needs a LVM partition activated that / does not. Similarly, I think Elimar's System 1 is going to activate vg0/root but not vg0/usr. We don't have enough information in this bug report to know what layout Torsten, IOhannes, Javier used on their systems, but we can guess from the fact that vgchange -a y is a successful workaround... I predict that these are LVM over either a single RAID array, or real partitions. My partition layout is: javi@Doraemon:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:00 238,5G 0 disk ├─sda1 8:10 243M 0 part /boot ├─sda2 8:20 1K 0 part └─sda5 8:50 238,2G 0 part ├─doraemon-root 254:00 13,4G 0 lvm / ├─doraemon-swap 254:10 3,7G 0 lvm [SWAP] ├─doraemon-var 254:20 11,3G 0 lvm /var ├─doraemon-tmp 254:30 4,7G 0 lvm /tmp ├─doraemon-opt 254:40 9,3G 0 lvm /opt └─doraemon-home 254:50 65,2G 0 lvm /home $ sudo lshw -c disk *-disk description: ATA Disk product: C400-MTFDDAK256M physical id: 0.0.0 bus info: scsi@0:0.0.0 logical name: /dev/sda version: 0G09 serial: 12440352D97A size: 238GiB (256GB) capabilities: partitioned partitioned:dos configuration: ansiversion=5 logicalsectorsize=512 sectorsize=512 signature=573692f2 Before this bug, i have too /usr ( doraemon-usr logical volume) splited. I moved /usr into / after Ben suggested at a comment in this bug. The same happened in another computer which had the same partition layout Thank you very much -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
