1 |
On Wed, Aug 21, 2013 at 10:54 AM, thegeezer <thegeezer@×××××××××.net> wrote: |
2 |
> On 08/21/2013 04:10 PM, Neil Bothwick wrote: |
3 |
>> On Wed, 21 Aug 2013 10:40:32 -0400, Tanstaafl wrote: |
4 |
>> |
5 |
>>>>> update LVM2 |
6 |
>>>>> kernel remains the same |
7 |
>>>>> reboot |
8 |
>>>>> initramfs finds all PVS and activates VG |
9 |
>>>>> main system init |
10 |
>>>>> /etc/init.d/lvm2 start |
11 |
>>>>> error can't read from USB PVS |
12 |
>>>>> login to system with missing PVS |
13 |
>>>>> /etc/init.d/lvm2 restart |
14 |
>>>>> all PVS listed |
15 |
>>>>> reboot several times to verify it wasn't just a stuck service, |
16 |
>>>>> exactly the same |
17 |
>>>>> now ok but restarting a boot service manually required (!) |
18 |
>>>> I updated the initramfs and rebooted and all problems went away |
19 |
>> This sounds like a bug in LVM. If it was down to a version clash, why did |
20 |
>> a restart find the PVs? |
21 |
> well you can probably understand my confusion replugging usb devices and |
22 |
> trying to pvscan // vgchange -ay --partial etc |
23 |
> the errors i was getting are below. i genuinely thought with the |
24 |
> missing device it was a hardware failure of the usb disk, and a restart |
25 |
> of lvm was a last gasp chance; when it worked i realised the initram |
26 |
> might need updating. |
27 |
|
28 |
As Neil said, this sounds like a bug in LVM and/or the initramfs you |
29 |
were using (did you use genkernel, dracut, you roll your own?) If a |
30 |
restart worked, the initramfs could do that, right? |
31 |
|
32 |
So, it was not a problem with the initramfs, per se. |
33 |
|
34 |
|
35 |
> Aug 17 17:56:30 [kernel] Buffer I/O error on device dm-26, logical block |
36 |
> 5242864 |
37 |
> - Last output repeated twice - |
38 |
> Aug 17 17:56:30 [kernel] Buffer I/O error on device dm-26, logical block |
39 |
> 5242878 |
40 |
> - Last output repeated twice - |
41 |
> Aug 17 17:56:30 [kernel] Buffer I/O error on device dm-26, logical block 0 |
42 |
> - Last output repeated twice - |
43 |
> Aug 17 17:56:30 [kernel] Buffer I/O error on device dm-26, logical block 1 |
44 |
> Aug 17 17:56:30 [kernel] Buffer I/O error on device dm-26, logical block |
45 |
> 5242879 |
46 |
> - Last output repeated 2 times - |
47 |
> |
48 |
> |
49 |
>> |
50 |
>>> And this is *precisely* what scares me about this. |
51 |
>>> |
52 |
>>> This simply should not be, period. Support for separate /usr without |
53 |
>>> initramfs simply SHOULD NOT be dropped unless/until things like this |
54 |
>>> (updating lvm) can *never* cause a system to fail to boot like this. |
55 |
>> This is irrelevant to separate /usr. an initramfs is required if / is on |
56 |
>> a VM, whether or not /usr is on the same LV. |
57 |
>> |
58 |
>> |
59 |
> |
60 |
> |
61 |
> Perhaps though it highlights a need for a utility to identify if items |
62 |
> on an initramfs have been updated ? |
63 |
> in this case the problem was definitely between the keyboard and the |
64 |
> chair, but it is easily overlooked (yeah just trying to make myself feel |
65 |
> better) |
66 |
|
67 |
I'm under the impression that, with a properly generated initramfs, |
68 |
this kind of things would be avoided when changing minor versions of |
69 |
stuff like LVM or NFS. For major versions, a message from the ebuild |
70 |
shoul be enough, and I'm not even sure about that. |
71 |
|
72 |
We should also expect some responsibility from the user towards her |
73 |
system; if she updates anything related to mounting /usr (and perhaps |
74 |
/), then she should use her common sense and rebuild her initramfs. |
75 |
|
76 |
> either way i'm already using initramfs anyway -- i pesonally roll out |
77 |
> lvm on root on everything i can because of it's flexibility: so the |
78 |
> whole argument of whether or not split /usr is not my argument. i'm |
79 |
> just bringing things to light to make the overall process easier for |
80 |
> everyone by highlighting potential issues folks may have. |
81 |
|
82 |
If we had just one initramfs generator, this could be easily |
83 |
automatized. The problem is that we have genkernel, dracut, busybox |
84 |
with the sep-usr USE flag, and roll-your-own-initramfs (and whichever |
85 |
one I don't know about). The cost of all this choice is that is |
86 |
responsibility of the user to take care of her system. |
87 |
|
88 |
I highly recommend to use dracut; it just works, it can be called at |
89 |
any time, and it takes between 10 to 30 seconds (depends on the speed |
90 |
of the machine) to build an initramfs. If you are really, *really* |
91 |
paranoid, you can make an script for your "emerge -whatever world" |
92 |
command, and add "dracut -f -H" afterwards, and then only upgrade your |
93 |
world with that script. |
94 |
|
95 |
That way, *every* time you upgrade your world, you update your |
96 |
initramfs. It adds 10-30 seconds to your upgrade time, but the |
97 |
initramfs is always in sync. |
98 |
|
99 |
I only update my initramfs after a kernel update, but I follow |
100 |
vanilla-sources, so that is every other week or something like that. I |
101 |
have an script that compiles the new kernel, installs it, generates |
102 |
the initramfs, and updates the GRUB (or GRUB2) config file, so |
103 |
everything is automatized. |
104 |
|
105 |
Regards. |
106 |
-- |
107 |
Canek Peláez Valdés |
108 |
Posgrado en Ciencia e Ingeniería de la Computación |
109 |
Universidad Nacional Autónoma de México |