Re: kernel cmdline - allow duplicate keys



On Fri, Aug 01, 2014 at 08:56:20AM -0400, Colin Walters wrote:
On Thu, Jul 31, 2014, at 01:51 PM, Dusty Mabe wrote:

Basically if I specify --karg-proc-cmdline 

Ah, I see.  The attached patch fixes it for me; what do you think?

Yes. The attached patch does work nicely for the --karg-proc-cmdline case so I think 
in the very least you should commit it. 

I think we still have some issues here to address though as the "merging" code, (on a
subseqent deployment) will end up ripping out the duplicate keys. I applied your patch
and built the ostree rpm and then composed a tree that included that rpm. I then pulled
and deployed that image on a server and rebooted. Now, booted into the ostree image, I
then pulled a new commit and deployed it. This is what I see: 


-bash-4.2# ostree pull dustyserver dusty-atomic/rawhide/x86_64/base/core                                  
21 metadata, 21 content objects fetched; 21128 KiB transferred in 1 seconds
-bash-4.2# ostree admin deploy --os=dusty  dustyserver:dusty-atomic/rawhide/x86_64/base/core
Copying /etc changes: 1 modified, 0 removed, 10 added
Transaction complete; bootconfig swap: yes deployment count change: 0)
Freed objects: 34.3 MB
-bash-4.2# 
-bash-4.2# ostree admin status
  dusty c16603666d9a7bd6126f55a3e1006e66858a4532ababe6c6fe64bad35979e068.0
    origin refspec: dustyserver:dusty-atomic/rawhide/x86_64/base/core
* dusty 795f650529e8e025868a3c2750994e990bbe0d65a858b324fec1cf025f022063.0
    origin refspec: dusty-atomic/rawhide/x86_64/base/core
-bash-4.2#
-bash-4.2# cd /boot/loader/entries/
-bash-4.2# cat ostree-dusty-0.conf | grep -P "^options" | sed 's/\s/\n/g' | grep lvm
rd.lvm.lv=vg_root/lv_swap
-bash-4.2# cat ostree-dusty-1.conf | grep -P "^options" | sed 's/\s/\n/g' | grep lvm
rd.lvm.lv=vg_root/lv_root
rd.lvm.lv=vg_root/lv_swap


Basically I still end up with a machine that doesn't boot. I said in a previous email
that this a tough one to solve (if you want to support merging). When you merge you have 
to make assumptions that could be valid or invalid. So.. Do we think that it is possible
to support merging and solve *all* cases? Or should we just state assumptions up front
and rely on the users to take them into account? 

NOTE: I could have passed in --karg-proc-cmdline and it probably would have worked.

Dusty 


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