Menu
▾
▴
devil-linux-develop
|
From: <hzu...@ra...> - 2004-03-04 21:31:50
|
On 03/04/2004 03:49:05 PM Roland Pabel wrote: >On Thursday 04 March 2004 20:09, Heiko Zuerker wrote: >> > Hi, >[...] >> > - insserv adds links in boot.d when you specify "B" as runlevel >> > (but /etc/init.d/rc doesn't understand that specifier) >> >> But you could add the functionality, or ? ;-) >> Unfortunately we need to use our system in a way, that insserv will >work >> with it. >well, insserv works, it knows about boot.d. It's the legacy >/etc/init.d/rc >file that doesn't know about it. But that shouldn't be a problem, >because >'rc' is used to switch betweeen runlevels, but the boot.d/ scripts are >not >part of any specific runlevel (and you shouldn't be able to switch to a >runlevel B). >What is that functionality you need there? I probably understood it wrong. My main concern is that insserv is able to order the scripts in boot.d, that's all. >> > I'll try to make some more changes, i.e. choosing runlevel on >startup >> > (for maintenance, unless someone adds XFree ;-)... >> >> That's good! >> I don't know how often I already needed a boot into runlevel 1. But I >> always forgett to add it to the boot menu. >I thought about this at the gym, I think I can easily code that >in /sbin/pre_init, when I can manually change inittab (replacing the >default >runlevel with sed and grep) before starting init. That's under the >assumption, that once init runs, there is no point to doing that >(otherwise, >that could be done in a boot.d/ script before entering the runlevel) Do you need to code anything? Try just to add the "1" to the kernel boot parameters in the boot menu. With a bit luck it's really that easy (should be at least) Heiko |
|
From: <hzu...@ra...> - 2004-03-05 14:54:16
|
On 03/04/2004 01:26:46 PM Roland Pabel wrote:
>Hi,
>this patch sets the new boot flow:
>
>/sbin/pre_init -> exec init
>/etc/init.d/boot
>/etc/init.d/boot.d/S*
>/etc/init.d/boot.local
>init goes into runlevel 3
>
>which is the way most other distros do it (apart from changes in names)
>Notes:
>- /etc/init.d/boot doesn't need to be called manually with the link in
>cfg_runlevel any longer (and doesn't need "start" - it should always
>run),
>because it's done by inittab
>- boot.* can't be handled by insserv, because the author of insserv
>prohibits
>that (probably to enforce to run boot.local as the last script before
>going
>into the runlevel)
>- insserv adds links in boot.d when you specify "B" as runlevel
>(but /etc/init.d/rc doesn't understand that specifier)
>
>I'll try to make some more changes, i.e. choosing runlevel on startup
>(for
>maintenance, unless someone adds XFree ;-)...
>Roland
>PS: build-20040301.tar.bz2 contains empty config/etc/rc{1,3,S}.d
>(not /etc/init.d/) directories, some script gone wild?
The patch is added.
Heiko
|
|
From: Roland P. <pa...@ta...> - 2004-03-04 21:46:18
|
On Thursday 04 March 2004 22:12, hzu...@ra... wrote: > On 03/04/2004 03:49:05 PM Roland Pabel wrote: > >On Thursday 04 March 2004 20:09, Heiko Zuerker wrote: > >> > Hi, > > [...] > > I probably understood it wrong. > My main concern is that insserv is able to order the scripts in boot.d, > that's all. well, insserv is able to do that. But it ordered the 6 scripts in my vmware session to the exact same sequence as they were in my (running) 1.0.4... What is your concern there? I don't see a problem... [...] > >I thought about this at the gym, I think I can easily code that > >in /sbin/pre_init, when I can manually change inittab (replacing the > >default > >runlevel with sed and grep) before starting init. That's under the > >assumption, that once init runs, there is no point to doing that > >(otherwise, > >that could be done in a boot.d/ script before entering the runlevel) > > Do you need to code anything? well, yes... > Try just to add the "1" to the kernel boot parameters in the boot menu. Do you want to duplicate all entries in isolinux.cfg to pass the runlevel to the kernel cmdline? I know that works with lilo, but the really handy part is that you can specify any parameters freely...is that possible with isolinux on CD? > With a bit luck it's really that easy (should be at least) well, an additional static runlevel config in isolinux.cfg is easy, but it's static... Roland -- ICQ UIN 49339118 Linux Counter #88774 GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel <ro...@pa...> |
|
From: Roland P. <pa...@ta...> - 2004-03-04 23:04:23
|
On Thursday 04 March 2004 22:32, Roland Pabel wrote: > On Thursday 04 March 2004 22:12, hzu...@ra... wrote: > > On 03/04/2004 03:49:05 PM Roland Pabel wrote: > > >On Thursday 04 March 2004 20:09, Heiko Zuerker wrote: > > >> > Hi, > > [...] > > > I probably understood it wrong. > > My main concern is that insserv is able to order the scripts in boot.d, > > that's all. > > well, insserv is able to do that. But it ordered the 6 scripts in my vmware > session to the exact same sequence as they were in my (running) 1.0.4... let me clarify this: The 6 scripts are S01checkfs -> ../checkfs S02mountfs -> ../mountfs S03setfileperm -> ../setfileperm S04localnet -> ../localnet S05setclock -> ../setclock S06loadkeys -> ../loadkeys and were linked by insserv in /etc/init.d/rcS.d/ because of their header entry # Default-Start: S They were called from inittab by "/etc/init.d/rc S". All I did was move them over to /etc/init.d/boot.d/, which insserv does conveniently when writing # Default-Start: B instead. They are now called from /etc/init.d/boot at the end (which itself is started by init), so we don't need to create a link for that file in /etc/init.d/rcS.d/ explicitly. (insserv definitely can't mess with/etc/init.d/boot, it got no INIT INFO header...) So whatever concerns you have with insserv and boot.d/ must have been present with rcS.d, too...Or haven't they? The only problem I could think of is: If a user adds a script to this mode, it might be called before mountfs...but that shouldn't happen very often, most people only need 'boot.local' and don't add scripts (especially scripts with proper INIT INFO declarations) Roland -- ICQ UIN 49339118 Linux Counter #88774 GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel <ro...@pa...> |
|
From: Heiko Z. <he...@zu...> - 2004-03-05 01:15:40
|
Roland Pabel wrote: > On Thursday 04 March 2004 22:32, Roland Pabel wrote: > >>On Thursday 04 March 2004 22:12, hzu...@ra... wrote: >> >>>On 03/04/2004 03:49:05 PM Roland Pabel wrote: >>> >>>>On Thursday 04 March 2004 20:09, Heiko Zuerker wrote: >>>> >>>>>>Hi, >> >>[...] >> >> >>>I probably understood it wrong. >>>My main concern is that insserv is able to order the scripts in boot.d, >>>that's all. >> >>well, insserv is able to do that. But it ordered the 6 scripts in my vmware >>session to the exact same sequence as they were in my (running) 1.0.4... > > let me clarify this: The 6 scripts are > S01checkfs -> ../checkfs > S02mountfs -> ../mountfs > S03setfileperm -> ../setfileperm > S04localnet -> ../localnet > S05setclock -> ../setclock > S06loadkeys -> ../loadkeys > and were linked by insserv in /etc/init.d/rcS.d/ because of their header entry > # Default-Start: S > They were called from inittab by "/etc/init.d/rc S". > All I did was move them over to /etc/init.d/boot.d/, which insserv does > conveniently when writing > # Default-Start: B > instead. They are now called from /etc/init.d/boot at the end (which itself is > started by init), so we don't need to create a link for that file > in /etc/init.d/rcS.d/ explicitly. (insserv definitely can't mess > with/etc/init.d/boot, it got no INIT INFO header...) > So whatever concerns you have with insserv and boot.d/ must have been present > with rcS.d, too...Or haven't they? > The only problem I could think of is: If a user adds a script to this mode, it > might be called before mountfs...but that shouldn't happen very often, most > people only need 'boot.local' and don't add scripts (especially scripts with > proper INIT INFO declarations) It should be OK this way. When somebody adds a script to B, then he has to do it via insserv anyway, which then again takes care of the correct order. So everything should be "cool". Heiko |
|
From: Roland P. <pa...@ta...> - 2004-03-04 23:46:49
|
On Thursday 04 March 2004 22:32, Roland Pabel wrote: > On Thursday 04 March 2004 22:12, hzu...@ra... wrote: > > On 03/04/2004 03:49:05 PM Roland Pabel wrote: > > >On Thursday 04 March 2004 20:09, Heiko Zuerker wrote: [...] > Do you want to duplicate all entries in isolinux.cfg to pass the runlevel > to the kernel cmdline? I know that works with lilo, but the really handy > part is that you can specify any parameters freely...is that possible with > isolinux on CD? It just came to me that Knoppix uses this feature heavily and even with Suse you can use the F-Keys at boot to switch resolution and stuff. I'll look into that tomorrow, now I really want to know how that works... Roland -- ICQ UIN 49339118 Linux Counter #88774 GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel <ro...@pa...> |
|
From: Heiko Z. <he...@zu...> - 2004-03-05 01:20:32
|
Roland Pabel wrote:
> On Thursday 04 March 2004 22:32, Roland Pabel wrote:
>
>>On Thursday 04 March 2004 22:12, hzu...@ra... wrote:
>>
>>>On 03/04/2004 03:49:05 PM Roland Pabel wrote:
>>>
>>>>On Thursday 04 March 2004 20:09, Heiko Zuerker wrote:
>
> [...]
>
>>Do you want to duplicate all entries in isolinux.cfg to pass the runlevel
>>to the kernel cmdline? I know that works with lilo, but the really handy
>>part is that you can specify any parameters freely...is that possible with
>>isolinux on CD?
>
> It just came to me that Knoppix uses this feature heavily and even with Suse
> you can use the F-Keys at boot to switch resolution and stuff. I'll look into
> that tomorrow, now I really want to know how that works...
Yes it should be possible. But be carefull with Suse, they use a heavily
patched boot loader....
You could to it the following way:
Add 2 more entries to the boot menu:
1) standard text mode (80x25) which goes only to runlevel 1
this one should be good for most cases where you have to fix something
2) one modular one where you can change the command line
I don't know if that all is really possible, but I'm sure you'll figure
it out. ;-)
Heiko
|
|
From: Roland P. <pa...@ta...> - 2004-03-05 15:54:42
|
On Friday 05 March 2004 02:02, Heiko Zuerker wrote: > Roland Pabel wrote: > > On Thursday 04 March 2004 22:32, Roland Pabel wrote: > >>On Thursday 04 March 2004 22:12, hzu...@ra... wrote: > >>>On 03/04/2004 03:49:05 PM Roland Pabel wrote: > >>>>On Thursday 04 March 2004 20:09, Heiko Zuerker wrote: > > [...] > Yes it should be possible. But be carefull with Suse, they use a heavily > patched boot loader.... I looked at the Suse-9.0 boot config: The code that manages the F-Keys and options is actually part of the boot logo. Their isolinux .cfg is almost identical to ours. > You could to it the following way: > Add 2 more entries to the boot menu: > 1) standard text mode (80x25) which goes only to runlevel 1 > this one should be good for most cases where you have to fix something this one is simple. The only drawback is that you'd need to reboot afterwards if you only want to change the framebuffer mode (Last time I checked, it was not possible to change FB resolution after boot) > 2) one modular one where you can change the command line that one would be the one to desire. Especially for people who need special boot options and want to test several scenarios (think acpi/apm/...) I'll try googling, maybe it's surprisingly easy... Roland -- ICQ UIN 49339118 Linux Counter #88774 GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel <ro...@pa...> |
|
From: Roland P. <pa...@ta...> - 2004-03-05 22:31:39
|
On Friday 05 March 2004 16:39, Roland Pabel wrote: > On Friday 05 March 2004 02:02, Heiko Zuerker wrote: > > Roland Pabel wrote: > > > On Thursday 04 March 2004 22:32, Roland Pabel wrote: > > >>On Thursday 04 March 2004 22:12, hzu...@ra... wrote: > > >>>On 03/04/2004 03:49:05 PM Roland Pabel wrote: > > >>>>On Thursday 04 March 2004 20:09, Heiko Zuerker wrote: > [...] > > > 2) one modular one where you can change the command line That is actually the default...took me hours to realize that isolinux behaves like lilo: Any option you add at the boot selection screen is passed to the kernel, which itself passes anything it doesn't understand to init; or rather to /linuxrc in the initrd. To get this to init, we have to forward those arguments to pre_init and then to init. I made those changes, entered "3 S" and it's 1024x768 and single user mode... I'll make a clean patch and send it later, Roland -- ICQ UIN 49339118 Linux Counter #88774 GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel <ro...@pa...> |
