[arch-general] Installation: after first reboot ext3 superblock mount time in future
Hello, i've noticed this meanwhile quiet often after many installations. Currently after a test with 2008.03-0.3, but also with older ISOs: After install and first reboot i got such fsck notice during rc: ,---- | /dev/sda3: Superblock last mount time is in the future. FIXED | /dev/sda3 has gone 49710 days without being checked, check forced. `---- Here¹ you could download a screenshot from such a situation where also a reboot is required after fsck. Cause this is the *first* reboot after installation users will get a bad impression about Arch. First i thought this comes from vmware, but i also get it in virtualbox and i've seen this also during real installations. I have a suspicion: During (c)fdisk and formatting the disks current locale and timezone is set to US values (don't know at the moment the initial settings presented in rc.conf). During configuration i set my locale and timezone always to de_DE.utf8 and Europe/Berlin. And when first reboot is made that from umounting / there is a time difference that could cause such and flag it on ext3 partition? Or with the order in rc scripts? Maybe also that the hwclock is changed during/after installation... Have others also seen such? ¹ http://users.archlinux.de/~gerbra/screen.png -- Don't drink and root!
On Sat, Mar 29, 2008 at 02:12:35PM +0100, Gerhard Brauer wrote:
Hello,
i've noticed this meanwhile quiet often after many installations. Currently after a test with 2008.03-0.3, but also with older ISOs:
After install and first reboot i got such fsck notice during rc:
,---- | /dev/sda3: Superblock last mount time is in the future. FIXED | /dev/sda3 has gone 49710 days without being checked, check forced. `----
Here¹ you could download a screenshot from such a situation where also a reboot is required after fsck. Cause this is the *first* reboot after installation users will get a bad impression about Arch.
First i thought this comes from vmware, but i also get it in virtualbox and i've seen this also during real installations.
I have a suspicion: During (c)fdisk and formatting the disks current locale and timezone is set to US values (don't know at the moment the initial settings presented in rc.conf). During configuration i set my locale and timezone always to de_DE.utf8 and Europe/Berlin. And when first reboot is made that from umounting / there is a time difference that could cause such and flag it on ext3 partition? Or with the order in rc scripts?
Maybe also that the hwclock is changed during/after installation...
Have others also seen such?
¹ http://users.archlinux.de/~gerbra/screen.png
-- Don't drink and root!
Yes i used to get that all the time. I think its somehow related to changes in tzdata that happened around a year ago. This only appears if you set the HARDWWARECLOCK to UTC as far as i can tell. Even though i dont have Widnows installed localtime works better for me, no such issues and plus the clock uses the correct time. UTC is 2 hours ahead. Greg
On Sat, Mar 29, 2008 at 03:16:00PM +0200, Grigorios Bouzakis wrote:
This only appears if you set the HARDWWARECLOCK to UTC as far as i can tell.
Most times in virtual machines i leave it to localtime. But the hwclock of a vm comes from the host system (here it's set to UTC).
Even though i dont have Widnows installed localtime works better for me, no such issues and plus the clock uses the correct time. UTC is 2 hours ahead.
Yes, windows have it's own goal with the clock: all mine, don't care about other's ;-) If i remember it, i will try next installations with tzdate set before fdisk. Maybe this could solve it. Perhaps we could set tzdate/TIMEZONE in the installer before (c)fdisk'ing, maybe in km or as a own menu option if this is the reason.
Greg
Regards Gerhard -- Linux ist wenn es trotzdem geht...
Who cares? If it's an issue perhaps you should use a different distribution. -- Callan 'wizzomafizzo' Barrett
Hey, "Callan Barrett" <wizzomafizzo@gmail.com> writes:
Who cares? If it's an issue perhaps you should use a different distribution.
That seems to be quite an uncalled for reply. Let's see... Gerhard Brauer tests the ArchISO ftp install on various machines. He then notices a bug that gives the impression that arch isn't well polished. I completely agree here, but let me quote an unnamed dev: "the impression is bad" - "i want it to be, stay the fuck away from arch" Well. Smooth attitude there. And then of course the reply to shut the fuck up unless you talk in diff -u format. May I say, people that act that way need to get the fuck down from their high horse and don't act ridiculous. There, I said it. First of all, calm down. Then continue to read the thread again and see if your reply holds the test of time, I doubt it will. br, benny P.S. I don't think the "patches welcome" attitude healthy, but who am I?
On Sun, Mar 30, 2008 at 1:13 AM, Benjamin Andresen <bandresen@gmail.com> wrote:
Hey,
"Callan Barrett" <wizzomafizzo@gmail.com> writes:
Who cares? If it's an issue perhaps you should use a different distribution.
That seems to be quite an uncalled for reply.
Let's see... Gerhard Brauer tests the ArchISO ftp install on various machines.
He then notices a bug that gives the impression that arch isn't well polished.
I completely agree here, but let me quote an unnamed dev: "the impression is bad" - "i want it to be, stay the fuck away from arch"
Well. Smooth attitude there. And then of course the reply to shut the fuck up unless you talk in diff -u format.
May I say, people that act that way need to get the fuck down from their high horse and don't act ridiculous. There, I said it.
First of all, calm down. Then continue to read the thread again and see if your reply holds the test of time, I doubt it will.
br, benny
P.S. I don't think the "patches welcome" attitude healthy, but who am I?
This is going to be a pretty epic thread. I even starred it on my gmail. -- Callan 'wizzomafizzo' Barrett
2008/3/29, Callan Barrett <wizzomafizzo@gmail.com>:
On Sun, Mar 30, 2008 at 1:13 AM, Benjamin Andresen <bandresen@gmail.com> wrote:
Hey,
"Callan Barrett" <wizzomafizzo@gmail.com> writes:
Who cares? If it's an issue perhaps you should use a different distribution.
That seems to be quite an uncalled for reply.
Let's see... Gerhard Brauer tests the ArchISO ftp install on various machines.
He then notices a bug that gives the impression that arch isn't well polished.
I completely agree here, but let me quote an unnamed dev: "the impression is bad" - "i want it to be, stay the fuck away from arch"
Well. Smooth attitude there. And then of course the reply to shut the fuck up unless you talk in diff -u format.
May I say, people that act that way need to get the fuck down from their high horse and don't act ridiculous. There, I said it.
First of all, calm down. Then continue to read the thread again and see if your reply holds the test of time, I doubt it will.
br, benny
P.S. I don't think the "patches welcome" attitude healthy, but who am I?
This is going to be a pretty epic thread. I even starred it on my gmail.
Hey! Why do we discuss anything non-technical in this thread? Can't we just stay on topic without yet another round of yet again useless philosophical sh*t? P.S.: this is not addressed to anyone personally. -- Roman Kyrylych (Роман Кирилич)
2008/3/29, Gerhard Brauer <gerhard.brauer@web.de>:
On Sat, Mar 29, 2008 at 03:16:00PM +0200, Grigorios Bouzakis wrote:
This only appears if you set the HARDWWARECLOCK to UTC as far as i can tell.
Most times in virtual machines i leave it to localtime. But the hwclock of a vm comes from the host system (here it's set to UTC).
Even though i dont have Widnows installed localtime works better for me, no such issues and plus the clock uses the correct time. UTC is 2 hours ahead.
Yes, windows have it's own goal with the clock: all mine, don't care about other's ;-)
If i remember it, i will try next installations with tzdate set before fdisk. Maybe this could solve it.
Perhaps we could set tzdate/TIMEZONE in the installer before (c)fdisk'ing, maybe in km or as a own menu option if this is the reason.
Current version of installer does remount of all partitions after timezone is chosen, AFAIR this worked fine for any combination of timezone with localtime/UTC clock mode in BIOS. I think a separate km-like script is needed for this though, for example when install CD is used for rescue purposes when filesystems are mounted in read-write mode. Sadly I haven't provided an implementation of this yet :-( Anyway, I'm very interesting in your bugreport (as I believed it was fixed and haven't got any report for a long time) so *any* information about steps you can get it reproduceable is usedul. -- Roman Kyrylych (Роман Кирилич)
2008/3/29, Grigorios Bouzakis <grbzks@gmail.com>:
On Sat, Mar 29, 2008 at 02:12:35PM +0100, Gerhard Brauer wrote:
Hello,
i've noticed this meanwhile quiet often after many installations. Currently after a test with 2008.03-0.3, but also with older ISOs:
After install and first reboot i got such fsck notice during rc:
,---- | /dev/sda3: Superblock last mount time is in the future. FIXED | /dev/sda3 has gone 49710 days without being checked, check forced. `----
Here¹ you could download a screenshot from such a situation where also a reboot is required after fsck. Cause this is the *first* reboot after installation users will get a bad impression about Arch.
First i thought this comes from vmware, but i also get it in virtualbox and i've seen this also during real installations.
I have a suspicion: During (c)fdisk and formatting the disks current locale and timezone is set to US values (don't know at the moment the initial settings presented in rc.conf). During configuration i set my locale and timezone always to de_DE.utf8 and Europe/Berlin. And when first reboot is made that from umounting / there is a time difference that could cause such and flag it on ext3 partition? Or with the order in rc scripts?
Maybe also that the hwclock is changed during/after installation...
Have others also seen such?
¹ http://users.archlinux.de/~gerbra/screen.png
-- Don't drink and root!
Yes i used to get that all the time. I think its somehow related to changes in tzdata that happened around a year ago. This only appears if you set the HARDWWARECLOCK to UTC as far as i can tell. Even though i dont have Widnows installed localtime works better for me, no such issues and plus the clock uses the correct time. UTC is 2 hours ahead.
Hmmm... I thought this was fixed long ago... I will try to reproduce the issue in virtual machine. It would be nice if you could provide the time set in your BIOS before install, output of `date` before and after running /arch/setup and after the first install. -- Roman Kyrylych (Роман Кирилич)
2008/3/30, Roman Kyrylych <roman.kyrylych@gmail.com>:
2008/3/29, Grigorios Bouzakis <grbzks@gmail.com>:
On Sat, Mar 29, 2008 at 02:12:35PM +0100, Gerhard Brauer wrote:
Hello,
i've noticed this meanwhile quiet often after many installations. Currently after a test with 2008.03-0.3, but also with older ISOs:
After install and first reboot i got such fsck notice during rc:
,---- | /dev/sda3: Superblock last mount time is in the future. FIXED | /dev/sda3 has gone 49710 days without being checked, check forced. `----
Here¹ you could download a screenshot from such a situation where also a reboot is required after fsck. Cause this is the *first* reboot after installation users will get a bad impression about Arch.
First i thought this comes from vmware, but i also get it in virtualbox and i've seen this also during real installations.
I have a suspicion: During (c)fdisk and formatting the disks current locale and timezone is set to US values (don't know at the moment the initial settings presented in rc.conf). During configuration i set my locale and timezone always to de_DE.utf8 and Europe/Berlin. And when first reboot is made that from umounting / there is a time difference that could cause such and flag it on ext3 partition? Or with the order in rc scripts?
Maybe also that the hwclock is changed during/after installation...
Have others also seen such?
¹ http://users.archlinux.de/~gerbra/screen.png
-- Don't drink and root!
Yes i used to get that all the time. I think its somehow related to changes in tzdata that happened around a year ago. This only appears if you set the HARDWWARECLOCK to UTC as far as i can tell. Even though i dont have Widnows installed localtime works better for me, no such issues and plus the clock uses the correct time. UTC is 2 hours ahead.
Hmmm... I thought this was fixed long ago... I will try to reproduce the issue in virtual machine. It would be nice if you could provide the time set in your BIOS before install, output of `date` before and after running /arch/setup and after the first install.
FYI, see http://bugs.archlinux.org/task/5445 -- Roman Kyrylych (Роман Кирилич)
On Sun, Mar 30, 2008 at 12:22:37AM +0200, Roman Kyrylych wrote:
2008/3/30, Roman Kyrylych <roman.kyrylych@gmail.com>:
2008/3/29, Grigorios Bouzakis <grbzks@gmail.com>:
On Sat, Mar 29, 2008 at 02:12:35PM +0100, Gerhard Brauer wrote:
Hello,
i've noticed this meanwhile quiet often after many installations. Currently after a test with 2008.03-0.3, but also with older ISOs:
After install and first reboot i got such fsck notice during rc:
,---- | /dev/sda3: Superblock last mount time is in the future. FIXED | /dev/sda3 has gone 49710 days without being checked, check forced. `----
Here¹ you could download a screenshot from such a situation where also a reboot is required after fsck. Cause this is the *first* reboot after installation users will get a bad impression about Arch.
First i thought this comes from vmware, but i also get it in virtualbox and i've seen this also during real installations.
I have a suspicion: During (c)fdisk and formatting the disks current locale and timezone is set to US values (don't know at the moment the initial settings presented in rc.conf). During configuration i set my locale and timezone always to de_DE.utf8 and Europe/Berlin. And when first reboot is made that from umounting / there is a time difference that could cause such and flag it on ext3 partition? Or with the order in rc scripts?
Maybe also that the hwclock is changed during/after installation...
Have others also seen such?
¹ http://users.archlinux.de/~gerbra/screen.png
-- Don't drink and root!
Yes i used to get that all the time. I think its somehow related to changes in tzdata that happened around a year ago. This only appears if you set the HARDWWARECLOCK to UTC as far as i can tell. Even though i dont have Widnows installed localtime works better for me, no such issues and plus the clock uses the correct time. UTC is 2 hours ahead.
Hmmm... I thought this was fixed long ago... I will try to reproduce the issue in virtual machine. It would be nice if you could provide the time set in your BIOS before install, output of `date` before and after running /arch/setup and after the first install.
FYI, see http://bugs.archlinux.org/task/5445
I dont remember having trouble at the time of the bug you posted. I think this started happening around the time tzdata was splitted from glibc or/and some changes happened with US timezones. I seem to have a memory of those two events combined with time issues in the back of my head but i cant be 100% sure. I am sure about the following. When installing from a 2007-08* or 2007-11 base/core iso , with BIOS time set properly & set HARDWWARECLOCK to UTC i get what gebra posted in the screenshot. If i set it to localtime it works normally. And as i said before Archlinux is the only OS on this PC. The only way of getting correct time with UTC is having the BIOS time set to actual time -2 hours. Setting USEDIRECTISA to yes or no doesnt affect anything of the above. Greg
On Sat, Mar 29, 2008 at 8:12 AM, Gerhard Brauer <gerhard.brauer@web.de> wrote:
Hello,
i've noticed this meanwhile quiet often after many installations. Currently after a test with 2008.03-0.3, but also with older ISOs:
After install and first reboot i got such fsck notice during rc:
,---- | /dev/sda3: Superblock last mount time is in the future. FIXED | /dev/sda3 has gone 49710 days without being checked, check forced. `----
Here¹ you could download a screenshot from such a situation where also a reboot is required after fsck. Cause this is the *first* reboot after installation users will get a bad impression about Arch.
Oh noes! We couldn't ever have a bad impression! We might lose a user! </sarcasm> Feel free to submit a patch against the installer (it is all in GIT on projects.archlinux.org), but justifying this problem by saying it gives a bad impression is not something that is going to make devs jump out and fix it- if anything it might bring out the cynical side as you can see above. -Dan
On Sat, Mar 29, 2008 at 09:59:13AM -0500, Dan McGee wrote:
On Sat, Mar 29, 2008 at 8:12 AM, Gerhard Brauer <gerhard.brauer@web.de> wrote:
Cause this is the *first* reboot after installation users will get a bad impression about Arch.
Oh noes! We couldn't ever have a bad impression! We might lose a user! </sarcasm> Not me ;-) This needs even more sarcasm ;-)
If i was a car seller i have no problem to say: " Hey, the car you have buyed is the best, ever, last car you buyed in your life. Ok, first time a day you must start it twice and ignore this little red lamp... But when it is started, oh man, you would love this care". *I* love Arch.
Feel free to submit a patch against the installer (it is all in GIT on projects.archlinux.org),
No, cause i'm doesn't know the technical background araound this "problem". Therefor i ask. And if i submit patches: you'll don't like them cause you must repair faster than i could patch something ;-)
but justifying this problem by saying it gives a bad impression is not something that is going to make devs jump out and fix it- That wasn't my intention, only my opinion. Extorting is useless ;-)
Maybe a little more technical discussion from those who care?
-Dan
Regards Gerhard -- www.archlinux.de
On Sat, Mar 29, 2008 at 04:53:38PM +0100, Gerhard Brauer wrote:
Maybe a little more technical discussion from those who care?
Ok, i've done another test (at the moment i could reproduce it in virtualbox): I've started the installation on 18:01 localtime (here CET). ,---- | inside the VM: | date | Sat Mar 29 18:01:23 UTC 2008 | hwclock | same time as above date `---- After creating and formatting the disk i have on sda3(=/): ,----[ dumpe2fs -h /dev/sda3 ] | Filesystem created: Sat Mar 29 18:06:04 2008 | Last mount time: Sat Mar 29 18:06:13 2008 | Last write time: Sat Mar 29 18:06:13 2008 | Mount count: 1 | Maximum mount count: 30 | Last checked: Sat Mar 29 18:06:04 2008 | Check interval: 15552000 (6 months) | Next check after: Thu Sep 25 18:06:04 2008 `---- Then i go over configure system, also set the Timezone to Europe/Berlin but leave the HARDWARECLOCK to localtime. Doing this current time in virtual machine is: Sat Mar 29 18:42:23 CET 2008 (only timezone gets changed, not the time itself) And here i think it "happend": ,----[ dumpe2fs -h /dev/sda3 ] | Filesystem created: Sat Mar 29 19:06:04 2008 | Last mount time: Sat Mar 29 19:06:13 2008 | Last write time: Sat Mar 29 19:06:13 2008 | Mount count: 1 | Maximum mount count: 30 | Last checked: Sat Mar 29 19:06:04 2008 | Check interval: 15552000 (6 months) | Next check after: Thu Sep 25 20:06:04 2008 `---- sda3 is still mounted, but the creation time is in the future. The same what fsck found fault with on the next(first) boot. I think the error is to change timezone during install but leave the time itself unchanged. Or something like that, i'm not sure ;-) But i think to ask the user before install: What is your clock set (UTC/localtime) and then *set* the clock (maybe also hwclock) before mkfs could solve this creation times conflicts. Regards Gerhard -- Heute ist das Morgen wovor du gestern Angst hattest...
Hello, i've done a bit more testing. First i think it's not a bug in any package. It's only a mismatch between clock set on install machine and the timezone which is later set during config. 1. I guess there is absolut no problem on machines where the hardware clock is set to UTC by default. 2. If the clock is set to localtime there is a mismatch directly after booting the kernel. The time is read from bios and then the timezone is UTC per default what is a wrong time. Ex. My localtime is 13:46 (= machines hardwareclock) but this time is CEST(UTC+2) So date on the machine itself shows: Sun Mar 30 13:46 UTC 2008 but it must be Sun Mar 30 11:46 UTC 2008 or Sun Mar 30 13:46 CEST 2008 Solutions: a) set the time by hand (KISS, maybe put a hint on installation guide?) date -s "13:46 CEST" result in: Sun Mar 30 11:46 UTC 2008 which is the now correct UTC time. b) put tzdata package on ISO, so the user could use tzselect. Hint could also be given in instalation guide. Or we make it more comfortable (handholding the user) and put this as a menu in installer("Set your timezone"). The $TZ env var could then also used by the installer to initial set TIMEZONE in rc.conf as we do it with KEYMAP. As a side effect we could reduce a lot of postings in forums where users not set this correctly. But that need perhaps discussion, i feel it a little bit to handholding. Personally i will use a) in the future. As a solution which maybe should be discussed i would prefer b), tzdata on ISO and a entry in installer menu. What do you think? Other ideas? Regards Gerhard -- Ist Ihnen mutt zu kompliziert? Ihr Mailprogramm zu "fett"? Sie moegen keine man pages? Versuchen Sie: rm -rf (ReadMail -Realy Fast)
Solutions: a) set the time by hand (KISS, maybe put a hint on installation guide?) date -s "13:46 CEST" result in: Sun Mar 30 11:46 UTC 2008 which is the now correct UTC time. b) put tzdata package on ISO, so the user could use tzselect. Hint could also be given in instalation guide. Or we make it more comfortable (handholding the user) and put this as a menu in installer("Set your timezone"). The $TZ env var could then also used by the installer to initial set TIMEZONE in rc.conf as we do it with KEYMAP. As a side effect we could reduce a lot of postings in forums where users not set this correctly. But that need perhaps discussion, i feel it a little bit to handholding.
On Sunday 30 March 2008 15:20:38 Gerhard Brauer wrote: thanks. i vote for putting a) in the instalation guide so new users dont get scared by this (imo) non issue. Since i expect people to actually read fsck ouput, i guess it's at least fair telling them in the install guide that this is not an actual problem, or can be fixed by setting the time. actually,... wasnt there noted in the guide that you have to link your timezone somewhere? -- best regards/Mit freundlichen Grüßen Arvid Ephraim Picciani
i vote for putting a) in the instalation guide so new users dont get scared by this (imo) non issue. You're right, it's not an real issue. Only a little annoying if you forget to set it correctly. I've last test something with a ~1.9TB
On Sun, Mar 30, 2008 at 01:40:10PM +0200, Arvid Ephraim Picciani wrote: partition and run in this fsck after first boot. CTRL+C was my friend ;-)
wasnt there noted in the guide that you have to link your timezone somewhere? Yes, in the chapter where to set the values in rc.conf. But at this time it's already to late, TZ (or time) must be set before starting the installer (or at top of installer). We *must* have a constant, correct time during install, especially after fdisk/1.mount and remount during configuring.
tzselect has the advantage that user could do it interactiv. With this (another idea) we could handle this like km: put a hint /etc/motd: ,---- | Timezone: | - to set your time(zone) correctly during installlation, type tzselect | on console. `----
best regards/Mit freundlichen Grüßen Arvid Ephraim Picciani
Regards Gerhard -- Dont't drink and root!
2008/3/30, Gerhard Brauer <gerhard.brauer@web.de>:
Hello,
i've done a bit more testing. First i think it's not a bug in any package. It's only a mismatch between clock set on install machine and the timezone which is later set during config.
1. I guess there is absolut no problem on machines where the hardware clock is set to UTC by default.
2. If the clock is set to localtime there is a mismatch directly after booting the kernel. The time is read from bios and then the timezone is UTC per default what is a wrong time. Ex. My localtime is 13:46 (= machines hardwareclock) but this time is CEST(UTC+2) So date on the machine itself shows: Sun Mar 30 13:46 UTC 2008 but it must be Sun Mar 30 11:46 UTC 2008 or Sun Mar 30 13:46 CEST 2008
Solutions: a) set the time by hand (KISS, maybe put a hint on installation guide?) date -s "13:46 CEST" result in: Sun Mar 30 11:46 UTC 2008 which is the now correct UTC time. b) put tzdata package on ISO, so the user could use tzselect. Hint could also be given in instalation guide. Or we make it more comfortable (handholding the user) and put this as a menu in installer("Set your timezone"). The $TZ env var could then also used by the installer to initial set TIMEZONE in rc.conf as we do it with KEYMAP. As a side effect we could reduce a lot of postings in forums where users not set this correctly. But that need perhaps discussion, i feel it a little bit to handholding.
Personally i will use a) in the future. As a solution which maybe should be discussed i would prefer b), tzdata on ISO and a entry in installer menu.
What do you think? Other ideas?
Aha, it seems now I've got it. It looks like the issue silently reappeared after it was fixed - because tzdata was splitted from glibc and then not included on install CD, thus effectively making the fix useless. In my opinion a separate km-like utility is needed instead of hardcoding the fix in installer (if you see the code - you'll understand why it's ugly hack), because timezone selection should be done before any read-write mounting to avoid the issue (e.g. when using install CD to recover the system - when instaler is not run and the hardcoded fix is not working). I blame myself for failing to do this for a looong time. :-( I didn't know (or forgot) about tzselect (*facepalm*) - thanks for pointing me that. -- Roman Kyrylych (Роман Кирилич)
On Sun, Mar 30, 2008 at 05:17:18PM +0300, Roman Kyrylych wrote:
2008/3/30, Gerhard Brauer <gerhard.brauer@web.de>:
Aha, it seems now I've got it.
;-) Yes, english isn't my mother language. I think, someone who reads my mails guess: Oh, a six year old child on list ;-)
I didn't know (or forgot) about tzselect (*facepalm*) - thanks for pointing me that.
Meanwhile (i wrote on other mail) i would prefer to handle it like km. Maybe it could be combined with the km hint in /etc/motd. So you must not "hurt" the installer, but it is on a place where every user should notice it. PS: I've tested always with the last RC-ISO. Don't know if tzselect is available on the archiso that Aaron published last time. But i think cause it's a live cd there are more tools available. Regards Gerhard -- rm -rf bedeutet NICHT: read mail -really fast
On Sun, Mar 30, 2008 at 07:58:21PM +0200, Gerhard Brauer wrote:
tzdata/tzselect on ISOs:
Meanwhile (i wrote on other mail) i would prefer to handle it like km. Maybe it could be combined with the km hint in /etc/motd. So you must not "hurt" the installer, but it is on a place where every user should notice it.
I think i'll make a feature request in next 3-4 days if we got nothing new in this discussion. We should not change something only while I and some others have discussed it. Gerhard -- Wir sind Bundes-Trojaner! Widerstand ist zwecklos! Wir werden Ihre terroristischen Daten den unseren hinzufuegen.
participants (8)
-
Armando M. Baratti
-
Arvid Ephraim Picciani
-
Benjamin Andresen
-
Callan Barrett
-
Dan McGee
-
Gerhard Brauer
-
Grigorios Bouzakis
-
Roman Kyrylych