RFC: writing kernel cmdline options to grub.conf for dracut

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

 



Hi,

This morning I've been talking to Harald Hoyer about what sort
of commandline options dracut will be needing to find the /
filesystem beside root=UUID=1234567890 .

In most cases (normal disks, dmraid, mdraid, lvm, dmcrypt)
root=UUID=1234567890 should suffice.

However in certain cases for example dracut will need additional
info to find the disks.

We've come to the following plan for iscsi targets:
1) Extend the dhcp_root dhcp variable iscsi syntax to
   be able include a username password, so:
   iscsi:192.168.50.2::::iqn.2009-06.dracut:target66
   Can become:
   iscsi:user:pass@xxxxxxxxxxxx::::iqn.2009-06.dracut:target66
   Or:
   iscsi:user:pass:reverse_user:reverse_pass@xxxxxxxxxxxx::::iqn.2009-06.dracut:target66

2) Pass root-path=iscsi:... on the kernel cmdline, for each needed iscsi target, so if
   necessary this will be passed multiple times, dracut will be modified to be able
   handle multiple root-path arguments being passed in

3) chmod /proc/cmdline 400, so that it cannot be read by ordinary users, plugging
   the passwork leak problem

Now the remaining question is how to implement the adding of the needed
cmdline options to grub.conf.

For the iscsi case (and atleast fcoe will be similar) I see the following 2 options,
both of which are feasible:
1) Add code to iscsi.py to get the needed cmdline options

2) Add a dracutCmdlineOptions property to all Device classes, which will return
   the needed options (if any) to make the device in question available inside
   dracut.

One of the issues here is that onlining an iscsi target, may get us multiple disks
as the target may have multiple LUN's. If more then one LUN of the same target
is needed we might end up with having the same root-path=iscsi:... option twice on
the cmdline, filtering this will be is easy though so this is not really an issue.

Looking at this from the iscsi pov, doing this from iscsi.py is easier, as
that already has a list of targets instead of a list of disks (so LUN's) as the
rest of the storage code has. Looking at this from the pov of the rest of
the code it might be cleaner in the long run to make this a device property though.

So I'm not sure what to do, advice is / ideas are very welcome ?

Regards,

Hans

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux