devil-linux-develop — developer discussions

Re: [Devil-linux-develop] klogd / syslog-ng

[Heiko Z. <he...@zu...>]

Diego Torres wrote:
> On Mon, May 24, 2004 at 09:43:59AM -0400, Heiko Zuerker wrote:
> 
> 
>>does anyone remember why we started using klogd again?
> 
> 
> you said something about logging kernel booting procedure... ¿?
> 

Aaah....
I think it was something about loosing some those messages.

Since it was a much older syslog-ng release, let's give it a try with 
the new one. Reverting back is easy.

Heiko

Re: [Devil-linux-develop] klogd / syslog-ng

[Diego T. <dt...@co...>]

On Mon, May 24, 2004 at 09:43:59AM -0400, Heiko Zuerker wrote:

> does anyone remember why we started using klogd again?

you said something about logging kernel booting procedure... ¿?

-- 
-- gnupg keyfingerprint -- 48AF 5BF9 8F54 2966 64CC  2327 7CD0 DD91 B09D 5799
-- Use of a keyboard or mouse may be linked to serious injuries or disorders.
Diego Torres - dtorres at anthalia dot org - Madrid / España

Re: [Devil-linux-develop] Issues with remote update of DL

[Tim T. <t....@co...>]

Heiko Zuerker wrote:

> Friedrich Lobenstock wrote:
>
>> Tim Tait wrote on 27.05.2004 00:38 MET:
>>
>>> Since the new config has not been saved yet, no permanent harm done. 
>>> Now the user can ssh in and review them. If they are not to their 
>>> exact liking then they can run upgrade-config again with the right 
>>> input, and make a new-etc tree.  Save that as etc.tar.bz2 (do the 
>>> paths need to be munged?) over the old one, and reboot. Voila! Trick 
>>> is to try to garantee the 1st boot has a high likelyhood of success.
>>
>>
>>
>> Hmmmm.....maybe in case of autoupdate we should start a process in 
>> the background that does nothing than the following:
>>    sleep 10min
>>    <restore prev. version of DL and remove disable new one>
>>    reboot -n -f
>>
>> This way you'd at least end up with the not updated system back to 
>> live if everything else fails. Of course we'd then need to add some 
>> kind of warning to the admins login to not forget to kill this 
>> process ;-)
>
>
> This is a very good idea !
>
I agree a fail-safe restore to old version mechanism would be nice... 
but I still say you have to force an auto-update or you run a high risk 
of not being to update remotely in the future, in which case why even 
bother supporting it. When major versions are released, just how far can 
one expect a boot to go on an old config? Did dl 1.0 work with an 
unmodified dl 0.5 config? Will 1.2 work woth an unmodified 1.06 config? 
Will we always require it to going forward?

This fail-safe would also by default restore the old config, because 
nobody would have run a save-config yet.

The watchdog script could wait for an event to terminate - like the 
etc.tar.bz2 file being updated or something.

>
>> Anyway those files that could not be upgrade by an auto-upgrade, eg. 
>> because they where changed manually, need to be updated manually anyway.
>>
>
> True

And they still can be, but only if the user can ssh in at which point he 
can check the upgrade results, which aren't saved yet so not harmful. 
Running the upgrade-config script itself later is harmless because all 
changes are made to a copy, you have to pu it into /etc to apply it.

>
> Heiko

Tim

Re: [Devil-linux-develop] [PATCH] install-on-usb - major enhancements (I think)

[Heiko Z. <he...@zu...>]

Tim Tait wrote:
> 
> Heiko Zuerker wrote:
> 
>> All Done.
>>
>> But there's still a problem:
>> when the script copies the stuff onto the device, cp prints a warning 
>> about omitting the directories grub and lilo.
>> Can you take a look at this?
>>
>> Heiko
>>
>> Tim Tait wrote:
>>
>>> Tim Tait wrote:
>>>
>>>>
>>>> In the process of fixing the broken gub/lilo support, I've made some 
>>>> significant chnages to "install-on-usb", hopefully you will find 
>>>> them as useful as I do. The diff as well as the complete file is 
>>>> attached for easier review. Item (5) means install-on-usb should be 
>>>> included inside the ISO as well, hence the mods to copy-base.
>>>>
>>>> Comments?
>>>>
>>>> Tim
>>>>
>>>> ----------------------------
>>>> Changes:
>>>> 1. Fixed Grub/Lilo stuff to copy the bootcd.iso rather than the 
>>>> whole contents.
>>>>
>>>> 2. Auto-replaced /dev/sda style device names with link contents (who 
>>>> likes having to type that??) to allow to work with devfs.
>>>>
>>>> 3. Added prompts for formerly implict selections embedded in script 
>>>> (such as choice of grub/lilo/syslinux)
>>>>
>>>> 4. Added prompt/support for initrd with ext2 (changes required 
>>>> ramdisk block size)
>>>>
>>>> 5. Added ability to make the bootcd.iso from the actual DL CD itself 
>>>> - solves chicken-and-egg problem, no need to get ISO and Dist 
>>>> archive. In theory allows boot of target machine from CD and 
>>>> self-install to USB/disk. I did not test this yet, but did install 
>>>> CD based image OK. dd copy is done with info based on isosize so 
>>>> does not have problems with CD-Rs and creates binary duplicate of 
>>>> original iso.
>>>>
>>>> 6. Option to copy your own config file to disk, with option to use 
>>>> different partition (recommended).
>>>>
>>>> 7. General code cleanup.
>>>
>>>
>>>
>>>
>>> Oops, one mistake with the sequence of events for the fdisk need to 
>>> get the device before I can call fdisk. Last minute changes always 
>>> get you:) Fixed now.
>>>
>>> Tim
>>
>>
> OK, I just ignore that warning now, not sure if there is a more elegant 
> way to handle it.
> 
> Also, cleaned up code a little more, moved the required disk format type 
> warning to before the fdisk prompt, also fixed error if cfdisk was the 
> selected tool (and made cfdisk the default as it is more user friendly), 
> plus added option to edit the Lilo/Grub conf files before they are saved 
> to device.
> 
> I tested the self-install of booting from cd and installing to usb and 
> it works.
> 

DONE

Heiko

Re: [Devil-linux-develop] [PATCH] install-on-usb - major enhancements (I think)

[Heiko Z. <he...@zu...>]

Tim Tait wrote:
> 
> 
> Tim Tait wrote:
> 
>>
>> Heiko Zuerker wrote:
>>
>>> All Done.
>>>
>>> But there's still a problem:
>>> when the script copies the stuff onto the device, cp prints a warning 
>>> about omitting the directories grub and lilo.
>>> Can you take a look at this?
>>>
>>> Heiko
>>>
>>> Tim Tait wrote:
>>>
>>>> Tim Tait wrote:
>>>>
>>>>>
>>>>> In the process of fixing the broken gub/lilo support, I've made 
>>>>> some significant chnages to "install-on-usb", hopefully you will 
>>>>> find them as useful as I do. The diff as well as the complete file 
>>>>> is attached for easier review. Item (5) means install-on-usb should 
>>>>> be included inside the ISO as well, hence the mods to copy-base.
>>>>>
>>>>> Comments?
>>>>>
>>>>> Tim
>>>>>
>>>>> ----------------------------
>>>>> Changes:
>>>>> 1. Fixed Grub/Lilo stuff to copy the bootcd.iso rather than the 
>>>>> whole contents.
>>>>>
>>>>> 2. Auto-replaced /dev/sda style device names with link contents 
>>>>> (who likes having to type that??) to allow to work with devfs.
>>>>>
>>>>> 3. Added prompts for formerly implict selections embedded in script 
>>>>> (such as choice of grub/lilo/syslinux)
>>>>>
>>>>> 4. Added prompt/support for initrd with ext2 (changes required 
>>>>> ramdisk block size)
>>>>>
>>>>> 5. Added ability to make the bootcd.iso from the actual DL CD 
>>>>> itself - solves chicken-and-egg problem, no need to get ISO and 
>>>>> Dist archive. In theory allows boot of target machine from CD and 
>>>>> self-install to USB/disk. I did not test this yet, but did install 
>>>>> CD based image OK. dd copy is done with info based on isosize so 
>>>>> does not have problems with CD-Rs and creates binary duplicate of 
>>>>> original iso.
>>>>>
>>>>> 6. Option to copy your own config file to disk, with option to use 
>>>>> different partition (recommended).
>>>>>
>>>>> 7. General code cleanup.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Oops, one mistake with the sequence of events for the fdisk need to 
>>>> get the device before I can call fdisk. Last minute changes always 
>>>> get you:) Fixed now.
>>>>
>>>> Tim
>>>
>>>
>>>
>> OK, I just ignore that warning now, not sure if there is a more 
>> elegant way to handle it.
>>
>> Also, cleaned up code a little more, moved the required disk format 
>> type warning to before the fdisk prompt, also fixed error if cfdisk 
>> was the selected tool (and made cfdisk the default as it is more user 
>> friendly), plus added option to edit the Lilo/Grub conf files before 
>> they are saved to device.
>>
>> I tested the self-install of booting from cd and installing to usb and 
>> it works.
>>
>> Tim
> 
> 
> Hey,  I just tried the syslinux boot and it didn't get  anywhere... I 
> usually use grub, can anyone see whats wrong? Should those files in 
> /boot on the CD not get put into the root dir? Did it work before? I 
> don't think I changed anything there...

There seems to be a problem with a syslinux tool. I updated it and 
recompile. I hope I have some time tomorrow to test it.

Heiko

[Devil-linux-develop] [ devil-linux-Feature Requests-961253 ] add sysfsutils & co

[SourceForge.net <no...@so...>]

Feature Requests item #961253, was opened at 2004-05-26 18:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=410646&aid=961253&group_id=34096

Category: Base System
Group: None
Status: Open
Priority: 5
Submitted By: Heiko Zuerker (smiley73)
Assigned to: Nobody/Anonymous (nobody)
Summary: add sysfsutils & co

Initial Comment:
http://linux-diag.sourceforge.net/index.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=410646&aid=961253&group_id=34096

Re: [Devil-linux-develop] Issues with remote update of DL

[Heiko Z. <he...@zu...>]

Friedrich Lobenstock wrote:
> Tim Tait wrote on 27.05.2004 00:38 MET:
>> Since the new config has not been saved yet, no permanent harm done. 
>> Now the user can ssh in and review them. If they are not to their 
>> exact liking then they can run upgrade-config again with the right 
>> input, and make a new-etc tree.  Save that as etc.tar.bz2 (do the 
>> paths need to be munged?) over the old one, and reboot. Voila! Trick 
>> is to try to garantee the 1st boot has a high likelyhood of success.
> 
> 
> Hmmmm.....maybe in case of autoupdate we should start a process in the 
> background that does nothing than the following:
>    sleep 10min
>    <restore prev. version of DL and remove disable new one>
>    reboot -n -f
> 
> This way you'd at least end up with the not updated system back to live 
> if everything else fails. Of course we'd then need to add some kind of 
> warning to the admins login to not forget to kill this process ;-)

This is a very good idea !


> Anyway those files that could not be upgrade by an auto-upgrade, eg. 
> because they where changed manually, need to be updated manually anyway.
> 

True

Heiko

Re: [Devil-linux-develop] Issues with remote update of DL

[Heiko Z. <he...@zu...>]

Tim Tait wrote:
> Friedrich Lobenstock wrote:
> 
>> Tim Tait wrote on 26.05.2004 19:22 MET:
>>
>>>
>>> While making some fixes to mount_cdrom for live update (due to issues 
>>> with read-only mounts of disk device) it occured to me there was 
>>> another issue - after reboot to a new version, pre_init will invoke 
>>> for the upgrade-config script where the user will be required to 
>>> provide input on the console. If the user is in fact at a remote 
>>> location, the box is now hung.
>>
>>
>>
>> It times out in 5 minutes in this case. See around line 87 in 
>> pre_init. In CVS this file is build/scripts/script/pre_init.
>>
>> When I look at this a second time I think we should change the if 
>> condition. In case of a timeout the returned character is the empty 
>> character so the upgrade is done. Then a confirmation asks to use this 
>> config and times out after 5 minutes and then the old configuration is 
>> restored and another confirmation times out in 5 minutes. So we are 
>> finally at 15 minutes till such system boots after remote upgrade 
>> without local input.
>>
>> Therefore I think in case of a timeout in the upgrade confirmation we 
>> should rather not upgrade at all but start the system after a shortend 
>> timeout of lets say 2 minutes.
> 
> 
> But I think within the upgrade-config script itself there are infinte 
> waits for user input.... so that would need to be changed  to allow the 
> option of defaults with timeout so allow an unattended upgrade to 
> happen. And if we fix the default to "no upgrade" then we may not boot 
> at all...
> 
>>
>>> Q: It looks like upgrade-config needs some post-processing to 
>>> actually upgrade the real config?
>>>
>>> A few alternatives occurred to me -
>>>
>>> - Make the choice to run upgrade-config default to "no", and let user 
>>> ssh in later to run it.  Can we setup all interactive logins to check 
>>> for mismatch and prompt/run the upgrade script there? In some 
>>> situation, the boot might not be succesfull unless the config is 
>>> upgraded.
>>
>>
>>
>> If you keep your update within the series, eg. update from 1.x.y to 
>> 1.x.z then the config files should not have changed. You might miss 
>> one or the other update to a start script but a boot should not fail.
>>
>> But this is only true if we can keep to ourselfs and only do bugfixes 
>> to stable releases. With a development version of DL I would not 
>> advice to do remote update - too much can happen here.
>>
>>
>>
>>> - Add another boot-line option like "DL_remote" that would indicate 
>>> never to require console input. This could be used to skip the 
>>> upgrade prompt entirely, or just change the default answer.
>>
>>
>>
>> Why not just create a special file on the configuration media to 
>> signal that we should boot without user interaction after the upgrade?
> 
> 
> Yes that could work also.
> 
>>
>>
>>> - Add and option to upgrade-config that takes default choices if no 
>>> answer in n seconds, and leave the pre_init stuff alone.
>>
>>
>>
>> See above.
>>
>>> pre_init  could detect the new "DL_remote" flag and call 
>>> upgrade-config with the right options.  The user could ssh in to 
>>> accept and save the new config, or reject it and run the upgrade 
>>> script again.
>>
>>
>>
>> Bruce, can one run upgrade-config in the running system or will this 
>> break horribly for sure. One problem would be that we should eg. stop 
>> all running services but not sshd automatically in this case, right?
> 
> 
> Well the upgrade-config script makes it's changes in a parallel 
> directory, so that much is safe. So I was thinking let it auto-upgrade 
> and take the defaults, switch configs, and finish the boot. We should be 
> able to boot far enough to get ssh working at least. Since the new 
> config has not been saved yet, no permanent harm done. Now the user can 
> ssh in and review them. If they are not to their exact liking then they 
> can run upgrade-config again with the right input, and make a new-etc 
> tree.  Save that as etc.tar.bz2 (do the paths need to be munged?) over 
> the old one, and reboot. Voila! Trick is to try to garantee the 1st boot 
> has a high likelyhood of success.

This was my thought too.

Heiko

Re: [Devil-linux-develop] Issues with remote update of DL

[Friedrich L. <fl...@fl...>]

Tim Tait wrote on 27.05.2004 00:38 MET:

> Friedrich Lobenstock wrote:
> 
>> Tim Tait wrote on 26.05.2004 19:22 MET:
>>
>>>
>>> While making some fixes to mount_cdrom for live update (due to issues 
>>> with read-only mounts of disk device) it occured to me there was 
>>> another issue - after reboot to a new version, pre_init will invoke 
>>> for the upgrade-config script where the user will be required to 
>>> provide input on the console. If the user is in fact at a remote 
>>> location, the box is now hung.
>>
>>
>>
>> It times out in 5 minutes in this case. See around line 87 in 
>> pre_init. In CVS this file is build/scripts/script/pre_init.
>>
>> When I look at this a second time I think we should change the if 
>> condition. In case of a timeout the returned character is the empty 
>> character so the upgrade is done. Then a confirmation asks to use this 
>> config and times out after 5 minutes and then the old configuration is 
>> restored and another confirmation times out in 5 minutes. So we are 
>> finally at 15 minutes till such system boots after remote upgrade 
>> without local input.
>>
>> Therefore I think in case of a timeout in the upgrade confirmation we 
>> should rather not upgrade at all but start the system after a shortend 
>> timeout of lets say 2 minutes.
> 
> 
> But I think within the upgrade-config script itself there are infinte 
> waits for user input.... 

Ok, but that would be "fixed" if the first timeout would not start 
upgrade-config at all if a timeout happens.

> so that would need to be changed  to allow the 
> option of defaults with timeout so allow an unattended upgrade to 
> happen. And if we fix the default to "no upgrade" then we may not boot 
> at all...

With the stable series this should be no problem. But you might want to test in 
a testsystem beforehand anyways ;-)


>>> Q: It looks like upgrade-config needs some post-processing to 
>>> actually upgrade the real config?
>>>
>>> A few alternatives occurred to me -
>>>
>>> - Make the choice to run upgrade-config default to "no", and let user 
>>> ssh in later to run it.  Can we setup all interactive logins to check 
>>> for mismatch and prompt/run the upgrade script there? In some 
>>> situation, the boot might not be succesfull unless the config is 
>>> upgraded.
>>
>>
>>
>> If you keep your update within the series, eg. update from 1.x.y to 
>> 1.x.z then the config files should not have changed. You might miss 
>> one or the other update to a start script but a boot should not fail.
>>
>> But this is only true if we can keep to ourselfs and only do bugfixes 
>> to stable releases. With a development version of DL I would not 
>> advice to do remote update - too much can happen here.
>>
>>
>>
>>> - Add another boot-line option like "DL_remote" that would indicate 
>>> never to require console input. This could be used to skip the 
>>> upgrade prompt entirely, or just change the default answer.
>>
>>
>>
>> Why not just create a special file on the configuration media to 
>> signal that we should boot without user interaction after the upgrade?
> 
> 
> Yes that could work also.
> 
>>
>>
>>> - Add and option to upgrade-config that takes default choices if no 
>>> answer in n seconds, and leave the pre_init stuff alone.
>>
>>
>>
>> See above.
>>
>>> pre_init  could detect the new "DL_remote" flag and call 
>>> upgrade-config with the right options.  The user could ssh in to 
>>> accept and save the new config, or reject it and run the upgrade 
>>> script again.
>>
>>
>>
>> Bruce, can one run upgrade-config in the running system or will this 
>> break horribly for sure. One problem would be that we should eg. stop 
>> all running services but not sshd automatically in this case, right?
> 
> 
> Well the upgrade-config script makes it's changes in a parallel 
> directory, so that much is safe. So I was thinking let it auto-upgrade 
> and take the defaults, switch configs, and finish the boot. We should be 
> able to boot far enough to get ssh working at least.

IMO I think this is far more dangerous than booting with the old config.

> Since the new 
> config has not been saved yet, no permanent harm done. Now the user can 
> ssh in and review them. If they are not to their exact liking then they 
> can run upgrade-config again with the right input, and make a new-etc 
> tree.  Save that as etc.tar.bz2 (do the paths need to be munged?) over 
> the old one, and reboot. Voila! Trick is to try to garantee the 1st boot 
> has a high likelyhood of success.

Hmmmm.....maybe in case of autoupdate we should start a process in the 
background that does nothing than the following:
    sleep 10min
    <restore prev. version of DL and remove disable new one>
    reboot -n -f

This way you'd at least end up with the not updated system back to live if 
everything else fails. Of course we'd then need to add some kind of warning to 
the admins login to not forget to kill this process ;-)

Anyway those files that could not be upgrade by an auto-upgrade, eg. because 
they where changed manually, need to be updated manually anyway.

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: [Devil-linux-develop] Issues with remote update of DL

[Tim T. <t....@co...>]

Friedrich Lobenstock wrote:

> Tim Tait wrote on 26.05.2004 19:22 MET:
>
>>
>> While making some fixes to mount_cdrom for live update (due to issues 
>> with read-only mounts of disk device) it occured to me there was 
>> another issue - after reboot to a new version, pre_init will invoke 
>> for the upgrade-config script where the user will be required to 
>> provide input on the console. If the user is in fact at a remote 
>> location, the box is now hung.
>
>
> It times out in 5 minutes in this case. See around line 87 in 
> pre_init. In CVS this file is build/scripts/script/pre_init.
>
> When I look at this a second time I think we should change the if 
> condition. In case of a timeout the returned character is the empty 
> character so the upgrade is done. Then a confirmation asks to use this 
> config and times out after 5 minutes and then the old configuration is 
> restored and another confirmation times out in 5 minutes. So we are 
> finally at 15 minutes till such system boots after remote upgrade 
> without local input.
>
> Therefore I think in case of a timeout in the upgrade confirmation we 
> should rather not upgrade at all but start the system after a shortend 
> timeout of lets say 2 minutes.

But I think within the upgrade-config script itself there are infinte 
waits for user input.... so that would need to be changed  to allow the 
option of defaults with timeout so allow an unattended upgrade to 
happen. And if we fix the default to "no upgrade" then we may not boot 
at all...

>
>> Q: It looks like upgrade-config needs some post-processing to 
>> actually upgrade the real config?
>>
>> A few alternatives occurred to me -
>>
>> - Make the choice to run upgrade-config default to "no", and let user 
>> ssh in later to run it.  Can we setup all interactive logins to check 
>> for mismatch and prompt/run the upgrade script there? In some 
>> situation, the boot might not be succesfull unless the config is 
>> upgraded.
>
>
> If you keep your update within the series, eg. update from 1.x.y to 
> 1.x.z then the config files should not have changed. You might miss 
> one or the other update to a start script but a boot should not fail.
>
> But this is only true if we can keep to ourselfs and only do bugfixes 
> to stable releases. With a development version of DL I would not 
> advice to do remote update - too much can happen here.
>
>
>
>> - Add another boot-line option like "DL_remote" that would indicate 
>> never to require console input. This could be used to skip the 
>> upgrade prompt entirely, or just change the default answer.
>
>
> Why not just create a special file on the configuration media to 
> signal that we should boot without user interaction after the upgrade?

Yes that could work also.

>
>
>> - Add and option to upgrade-config that takes default choices if no 
>> answer in n seconds, and leave the pre_init stuff alone.
>
>
> See above.
>
>> pre_init  could detect the new "DL_remote" flag and call 
>> upgrade-config with the right options.  The user could ssh in to 
>> accept and save the new config, or reject it and run the upgrade 
>> script again.
>
>
> Bruce, can one run upgrade-config in the running system or will this 
> break horribly for sure. One problem would be that we should eg. stop 
> all running services but not sshd automatically in this case, right?

Well the upgrade-config script makes it's changes in a parallel 
directory, so that much is safe. So I was thinking let it auto-upgrade 
and take the defaults, switch configs, and finish the boot. We should be 
able to boot far enough to get ssh working at least. Since the new 
config has not been saved yet, no permanent harm done. Now the user can 
ssh in and review them. If they are not to their exact liking then they 
can run upgrade-config again with the right input, and make a new-etc 
tree.  Save that as etc.tar.bz2 (do the paths need to be munged?) over 
the old one, and reboot. Voila! Trick is to try to garantee the 1st boot 
has a high likelyhood of success.

Tim

Re: [Devil-linux-develop] Issues with remote update of DL

[Friedrich L. <fl...@fl...>]

Tim Tait wrote on 26.05.2004 19:22 MET:
> 
> While making some fixes to mount_cdrom for live update (due to issues 
> with read-only mounts of disk device) it occured to me there was another 
> issue - after reboot to a new version, pre_init will invoke for the 
> upgrade-config script where the user will be required to provide input 
> on the console. If the user is in fact at a remote location, the box is 
> now hung.

It times out in 5 minutes in this case. See around line 87 in pre_init. In CVS 
this file is build/scripts/script/pre_init.

When I look at this a second time I think we should change the if condition. In 
case of a timeout the returned character is the empty character so the upgrade 
is done. Then a confirmation asks to use this config and times out after 5 
minutes and then the old configuration is restored and another confirmation 
times out in 5 minutes. So we are finally at 15 minutes till such system boots 
after remote upgrade without local input.

Therefore I think in case of a timeout in the upgrade confirmation we should 
rather not upgrade at all but start the system after a shortend timeout of lets 
say 2 minutes.

> Q: It looks like upgrade-config needs some post-processing to actually 
> upgrade the real config?
> 
> A few alternatives occurred to me -
> 
> - Make the choice to run upgrade-config default to "no", and let user 
> ssh in later to run it.  Can we setup all interactive logins to check 
> for mismatch and prompt/run the upgrade script there? In some situation, 
> the boot might not be succesfull unless the config is upgraded.

If you keep your update within the series, eg. update from 1.x.y to 1.x.z then 
the config files should not have changed. You might miss one or the other update 
to a start script but a boot should not fail.

But this is only true if we can keep to ourselfs and only do bugfixes to stable 
releases. With a development version of DL I would not advice to do remote 
update - too much can happen here.



> - Add another boot-line option like "DL_remote" that would indicate 
> never to require console input. This could be used to skip the upgrade 
> prompt entirely, or just change the default answer.

Why not just create a special file on the configuration media to signal that we 
should boot without user interaction after the upgrade?


> - Add and option to upgrade-config that takes default choices if no 
> answer in n seconds, and leave the pre_init stuff alone.

See above.

> pre_init  could 
> detect the new "DL_remote" flag and call upgrade-config with the right 
> options.  The user could ssh in to accept and save the new config, or 
> reject it and run the upgrade script again.

Bruce, can one run upgrade-config in the running system or will this break 
horribly for sure. One problem would be that we should eg. stop all running 
services but not sshd automatically in this case, right?

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

[Devil-linux-develop] Issues with remote update of DL

[Tim T. <t....@co...>]

While making some fixes to mount_cdrom for live update (due to issues 
with read-only mounts of disk device) it occured to me there was another 
issue - after reboot to a new version, pre_init will invoke for the 
upgrade-config script where the user will be required to provide input 
on the console. If the user is in fact at a remote location, the box is 
now hung.

Q: It looks like upgrade-config needs some post-processing to actually 
upgrade the real config?

A few alternatives occurred to me -

- Make the choice to run upgrade-config default to "no", and let user 
ssh in later to run it.  Can we setup all interactive logins to check 
for mismatch and prompt/run the upgrade script there? In some situation, 
the boot might not be succesfull unless the config is upgraded.

- Add another boot-line option like "DL_remote" that would indicate 
never to require console input. This could be used to skip the upgrade 
prompt entirely, or just change the default answer.

- Add and option to upgrade-config that takes default choices if no 
answer in n seconds, and leave the pre_init stuff alone. pre_init  could 
detect the new "DL_remote" flag and call upgrade-config with the right 
options.  The user could ssh in to accept and save the new config, or 
reject it and run the upgrade script again.

Comments?

Tim

[Devil-linux-develop] klogd / syslog-ng

[Heiko Z. <he...@zu...>]

Hey,

does anyone remember why we started using klogd again?

The reason why I ask is because klogd only works when we create /dev/log
as unix-dgram, but it's supposed to be unix-stream under Linux.

If we can't find out why we did this change, I'll disable klogd when
syslog-ng is selected.

-- 
Regards
  Heiko Zuerker
  http://www.devil-linux.org

Re: [Devil-linux-develop] kernel config

[Oliver J. <oli...@mo...>]

> >
> >i will check other distibutions what they do. end of week i'm back @
> >home and will check, if i can provide the patches for 2.6.5
> 
> Cool.
> And actually I would be good if you do it for 2.6.6 ;-)
> 
if pax is available for 2.6... because 2.5 patch didn't work for
for 2.6... and i don't have time to adjust the patch

Re: [Devil-linux-develop] kernel config

[<hzu...@ra...>]

On 05/24/2004 12:46:13 AM Oliver Jehle wrote:
>> It looks like I don't have time soon to update the config for the 2.6
>> series. Can you take another look at it and provide the patches for
>the
>> files in scripts/config/linux-2.6 directory ?
>>
>
>i will check other distibutions what they do. end of week i'm back @
>home and will check, if i can provide the patches for 2.6.5

Cool.
And actually I would be good if you do it for 2.6.6 ;-)

Heiko

Re: [Devil-linux-develop] [PATCH] install-on-usb - major enhancements (I think)

[<hzu...@ra...>]

On 05/24/2004 01:57:41 AM Tim Tait wrote:
>Tim Tait wrote:
>
>>
>> Heiko Zuerker wrote:
>>
>>> All Done.
>>>
>>> But there's still a problem:
>>> when the script copies the stuff onto the device, cp prints a warning
>>> about omitting the directories grub and lilo.
>>> Can you take a look at this?
>>>
>>> Heiko
>>>
>>> Tim Tait wrote:
>>>
>>>> Tim Tait wrote:
>>>>
>>>>>
>>>>> In the process of fixing the broken gub/lilo support, I've made
>>>>> some significant chnages to "install-on-usb", hopefully you will
>>>>> find them as useful as I do. The diff as well as the complete file
>>>>> is attached for easier review. Item (5) means install-on-usb should
>>>>> be included inside the ISO as well, hence the mods to copy-base.
>>>>>
>>>>> Comments?
>>>>>
>>>>> Tim
>>>>>
>>>>> ----------------------------
>>>>> Changes:
>>>>> 1. Fixed Grub/Lilo stuff to copy the bootcd.iso rather than the
>>>>> whole contents.
>>>>>
>>>>> 2. Auto-replaced /dev/sda style device names with link contents
>>>>> (who likes having to type that??) to allow to work with devfs.
>>>>>
>>>>> 3. Added prompts for formerly implict selections embedded in script
>>>>> (such as choice of grub/lilo/syslinux)
>>>>>
>>>>> 4. Added prompt/support for initrd with ext2 (changes required
>>>>> ramdisk block size)
>>>>>
>>>>> 5. Added ability to make the bootcd.iso from the actual DL CD
>>>>> itself - solves chicken-and-egg problem, no need to get ISO and
>>>>> Dist archive. In theory allows boot of target machine from CD and
>>>>> self-install to USB/disk. I did not test this yet, but did install
>>>>> CD based image OK. dd copy is done with info based on isosize so
>>>>> does not have problems with CD-Rs and creates binary duplicate of
>>>>> original iso.
>>>>>
>>>>> 6. Option to copy your own config file to disk, with option to use
>>>>> different partition (recommended).
>>>>>
>>>>> 7. General code cleanup.
>>>>
>>>>
>>>>
>>>>
>>>> Oops, one mistake with the sequence of events for the fdisk need to
>>>> get the device before I can call fdisk. Last minute changes always
>>>> get you:) Fixed now.
>>>>
>>>> Tim
>>>
>>>
>> OK, I just ignore that warning now, not sure if there is a more
>> elegant way to handle it.
>>
>> Also, cleaned up code a little more, moved the required disk format
>> type warning to before the fdisk prompt, also fixed error if cfdisk
>> was the selected tool (and made cfdisk the default as it is more user
>> friendly), plus added option to edit the Lilo/Grub conf files before
>> they are saved to device.
>>
>> I tested the self-install of booting from cd and installing to usb and
>> it works.
>>
>> Tim
>
>Hey,  I just tried the syslinux boot and it didn't get  anywhere... I
>usually use grub, can anyone see whats wrong? Should those files in
>/boot on the CD not get put into the root dir? Did it work before? I
>don't think I changed anything there...

I should be able to take a look at it tomorrow.

Heiko

Re: [Devil-linux-develop] [PATCH] install-on-usb - major enhancements (I think)

[Tim T. <t....@co...>]

Tim Tait wrote:

>
> Heiko Zuerker wrote:
>
>> All Done.
>>
>> But there's still a problem:
>> when the script copies the stuff onto the device, cp prints a warning 
>> about omitting the directories grub and lilo.
>> Can you take a look at this?
>>
>> Heiko
>>
>> Tim Tait wrote:
>>
>>> Tim Tait wrote:
>>>
>>>>
>>>> In the process of fixing the broken gub/lilo support, I've made 
>>>> some significant chnages to "install-on-usb", hopefully you will 
>>>> find them as useful as I do. The diff as well as the complete file 
>>>> is attached for easier review. Item (5) means install-on-usb should 
>>>> be included inside the ISO as well, hence the mods to copy-base.
>>>>
>>>> Comments?
>>>>
>>>> Tim
>>>>
>>>> ----------------------------
>>>> Changes:
>>>> 1. Fixed Grub/Lilo stuff to copy the bootcd.iso rather than the 
>>>> whole contents.
>>>>
>>>> 2. Auto-replaced /dev/sda style device names with link contents 
>>>> (who likes having to type that??) to allow to work with devfs.
>>>>
>>>> 3. Added prompts for formerly implict selections embedded in script 
>>>> (such as choice of grub/lilo/syslinux)
>>>>
>>>> 4. Added prompt/support for initrd with ext2 (changes required 
>>>> ramdisk block size)
>>>>
>>>> 5. Added ability to make the bootcd.iso from the actual DL CD 
>>>> itself - solves chicken-and-egg problem, no need to get ISO and 
>>>> Dist archive. In theory allows boot of target machine from CD and 
>>>> self-install to USB/disk. I did not test this yet, but did install 
>>>> CD based image OK. dd copy is done with info based on isosize so 
>>>> does not have problems with CD-Rs and creates binary duplicate of 
>>>> original iso.
>>>>
>>>> 6. Option to copy your own config file to disk, with option to use 
>>>> different partition (recommended).
>>>>
>>>> 7. General code cleanup.
>>>
>>>
>>>
>>>
>>> Oops, one mistake with the sequence of events for the fdisk need to 
>>> get the device before I can call fdisk. Last minute changes always 
>>> get you:) Fixed now.
>>>
>>> Tim
>>
>>
> OK, I just ignore that warning now, not sure if there is a more 
> elegant way to handle it.
>
> Also, cleaned up code a little more, moved the required disk format 
> type warning to before the fdisk prompt, also fixed error if cfdisk 
> was the selected tool (and made cfdisk the default as it is more user 
> friendly), plus added option to edit the Lilo/Grub conf files before 
> they are saved to device.
>
> I tested the self-install of booting from cd and installing to usb and 
> it works.
>
> Tim

Hey,  I just tried the syslinux boot and it didn't get  anywhere... I 
usually use grub, can anyone see whats wrong? Should those files in 
/boot on the CD not get put into the root dir? Did it work before? I 
don't think I changed anything there...

Tim

Re: [Devil-linux-develop] [PATCH] install-on-usb - major enhancements (I think)

[Tim T. <t....@co...>]

Heiko Zuerker wrote:

> All Done.
>
> But there's still a problem:
> when the script copies the stuff onto the device, cp prints a warning 
> about omitting the directories grub and lilo.
> Can you take a look at this?
>
> Heiko
>
> Tim Tait wrote:
>
>> Tim Tait wrote:
>>
>>>
>>> In the process of fixing the broken gub/lilo support, I've made some 
>>> significant chnages to "install-on-usb", hopefully you will find 
>>> them as useful as I do. The diff as well as the complete file is 
>>> attached for easier review. Item (5) means install-on-usb should be 
>>> included inside the ISO as well, hence the mods to copy-base.
>>>
>>> Comments?
>>>
>>> Tim
>>>
>>> ----------------------------
>>> Changes:
>>> 1. Fixed Grub/Lilo stuff to copy the bootcd.iso rather than the 
>>> whole contents.
>>>
>>> 2. Auto-replaced /dev/sda style device names with link contents (who 
>>> likes having to type that??) to allow to work with devfs.
>>>
>>> 3. Added prompts for formerly implict selections embedded in script 
>>> (such as choice of grub/lilo/syslinux)
>>>
>>> 4. Added prompt/support for initrd with ext2 (changes required 
>>> ramdisk block size)
>>>
>>> 5. Added ability to make the bootcd.iso from the actual DL CD itself 
>>> - solves chicken-and-egg problem, no need to get ISO and Dist 
>>> archive. In theory allows boot of target machine from CD and 
>>> self-install to USB/disk. I did not test this yet, but did install 
>>> CD based image OK. dd copy is done with info based on isosize so 
>>> does not have problems with CD-Rs and creates binary duplicate of 
>>> original iso.
>>>
>>> 6. Option to copy your own config file to disk, with option to use 
>>> different partition (recommended).
>>>
>>> 7. General code cleanup.
>>
>>
>>
>> Oops, one mistake with the sequence of events for the fdisk need to 
>> get the device before I can call fdisk. Last minute changes always 
>> get you:) Fixed now.
>>
>> Tim
>
OK, I just ignore that warning now, not sure if there is a more elegant 
way to handle it.

Also, cleaned up code a little more, moved the required disk format type 
warning to before the fdisk prompt, also fixed error if cfdisk was the 
selected tool (and made cfdisk the default as it is more user friendly), 
plus added option to edit the Lilo/Grub conf files before they are saved 
to device.

I tested the self-install of booting from cd and installing to usb and 
it works.

Tim

Re: [Devil-linux-develop] kernel config

[Oliver J. <oli...@mo...>]

> It looks like I don't have time soon to update the config for the 2.6 
> series. Can you take another look at it and provide the patches for the 
> files in scripts/config/linux-2.6 directory ?
> 

i will check other distibutions what they do. end of week i'm back @
home and will check, if i can provide the patches for 2.6.5

Oliver

Re: [Devil-linux-develop] [PATCH] save-config - Adds deterministic save location, fixes issues with ISO/config on same device

[Heiko Z. <he...@zu...>]

Tim Tait wrote:
> 
> This patch includes the following:
> 
> 1. Adds new command switches, and this help output:
> 
>    save-config [-hqs] [-d DEVICE] [-f FILE]
>      Saves the Devil-Linux configuration (/etc and /root trees) to a 
> bzip2 compressed tar file.
>      By default, the file loaded during boot will updated.
>        -d <devicename>  Device to use for configuration file.
>      -f <filename>    Name of configuration file (default is 
> "etc.tar.bz2").
>      -h               This help text
>      -q               Quiet operation, no status ouput.
>      -s               Force search of all devices for configuration file.
>  
> 2. Deterministic save location -  By default, the /shm/DL_CONFIG_SOURCE 
> file exists (created by linuxrc during boot), the device listed inside 
> is used rather than a search list. Thus the addition of new hot-plug 
> devices after bootup won't cause your config save to go astray as the 
> search list changes. The "-d" option can be used to force a device, or 
> "-s" can be used to force a search.
> 
> 3. Fix errors caused when the config and bootcd.iso file live on the 
> same device. This requires always mounting the device in the same mode 
> as was used to mount the device when looking for the bootcd.iso (ie ro), 
> then remounting to rw as required, doing the writes, remounting to ro, 
> then umounting. This also means the device is only opened rw for the 
> mininial time required, so less chance of corruption if the user swaps 
> the floppy at the wrong moment. (Note: Small fixes to linuxrc and 
> mount_cdrom are also needed due to this. Coming up next:)
> 
> 4. In the event that the chosen device has no config file on it, simply 
> inform the user and create a new one. This means that a fresh floppy can 
> be popped in to capture a changed config without having to copy a dummy 
> config to it first. Makes sense to me anyway.
> 
> 5. Pass the "post-save-config" script info that it might need about the 
> file just saved.

DONE

Heiko

Re: [Devil-linux-develop] kernel config

[Heiko Z. <he...@zu...>]

Oliver Jehle wrote:
> again me... with the problem, that the prepare step with kernel 2.6
> alwas waits because the oldconfig hangs...  if you not patch the kernel
> config in the config dir... 
> 
> isn't it better, to provide a default config and then show the 
> make oldconfig dialog ?? 

That was the way it worked in the past, but it just let to a tendency to 
miss new configuration parameters.

And since we introduced the redirection of the output to the logfiles, 
this won't work anymore anyway.

It looks like I don't have time soon to update the config for the 2.6 
series. Can you take another look at it and provide the patches for the 
files in scripts/config/linux-2.6 directory ?

cu
Heiko

Re: [Devil-linux-develop] [PATCH] save-config - Adds deterministic save location, fixes issues with ISO/config on same device

[Tim T. <t....@co...>]

Peter Frischknecht wrote:

>I just wanted to throw in my 2cents and praise you for this patch.
>
>I had actually modified the save-config script so that the etc.tar.bz2
>remained in the ramdrive.  I was uploading it to a remote server.
>Your script is elegant and functional.  Congrats!
>  
>
Glad you liked it:) Of course it helps to have such good material to 
start with. One more enhancement I was thinking of is allowing a path to 
be specified instead of a device, to allow it to be saved to an already 
mounted device and skip the mount steps.

Tim

Re: [Devil-linux-develop] [PATCH] save-config - Adds deterministic save location, fixes issues with ISO/config on same device

[Peter F. <pe...@em...>]

I just wanted to throw in my 2cents and praise you for this patch.

I had actually modified the save-config script so that the etc.tar.bz2
remained in the ramdrive.  I was uploading it to a remote server.
Your script is elegant and functional.  Congrats!

-- 
Peter Frischknecht <pe...@em...>
Empowering Solutions, Inc.

[Devil-linux-develop] kernel config

[Oliver J. <oli...@mo...>]

again me... with the problem, that the prepare step with kernel 2.6
alwas waits because the oldconfig hangs...  if you not patch the kernel
config in the config dir... 

isn't it better, to provide a default config and then show the 
make oldconfig dialog ?? 

oliver...

[Devil-linux-develop] [PATCH] save-config - Adds deterministic save location, fixes issues with ISO/config on same device

[Tim T. <t....@co...>]

This patch includes the following:

1. Adds new command switches, and this help output:

    save-config [-hqs] [-d DEVICE] [-f FILE]
      Saves the Devil-Linux configuration (/etc and /root trees) to a 
bzip2 compressed tar file.
      By default, the file loaded during boot will updated.
   
      -d <devicename>  Device to use for configuration file.
      -f <filename>    Name of configuration file (default is 
"etc.tar.bz2").
      -h               This help text
      -q               Quiet operation, no status ouput.
      -s               Force search of all devices for configuration file.
  
2. Deterministic save location -  By default, the /shm/DL_CONFIG_SOURCE 
file exists (created by linuxrc during boot), the device listed inside 
is used rather than a search list. Thus the addition of new hot-plug 
devices after bootup won't cause your config save to go astray as the 
search list changes. The "-d" option can be used to force a device, or 
"-s" can be used to force a search.

3. Fix errors caused when the config and bootcd.iso file live on the 
same device. This requires always mounting the device in the same mode 
as was used to mount the device when looking for the bootcd.iso (ie ro), 
then remounting to rw as required, doing the writes, remounting to ro, 
then umounting. This also means the device is only opened rw for the 
mininial time required, so less chance of corruption if the user swaps 
the floppy at the wrong moment. (Note: Small fixes to linuxrc and 
mount_cdrom are also needed due to this. Coming up next:)

4. In the event that the chosen device has no config file on it, simply 
inform the user and create a new one. This means that a fresh floppy can 
be popped in to capture a changed config without having to copy a dummy 
config to it first. Makes sense to me anyway.

5. Pass the "post-save-config" script info that it might need about the 
file just saved.

Tim