edit /etc/fstab if you change the number of root partition

[mimosa]

Maybe there's a better way to go about this, but here's what happened to me:

I was rationalising a hard disk with some unused Salix partitions left over from beta testing. After backing up my data, I deleted the unwanted ones with gparted, and used lilosetup to configure the bootloader appropriately. What had been /dev/sda7 became /dev/sda5.

It booted ok, but /etc/fstab still said to look for / on the old partition, sda7. I found myself in a recuperation mode but, despite being root, I was unable to edit /etc/fstab.

(NB: I'm curious whether there's a way to get round this )

I succesfully edited fstab from Salix Live; but another time, I'd do so before rebooting

As a footnote, I wonder if it would be feasible and worthwhile to extend lilosetup's functionality to check the contents of each Linux's /etc/fstab are sane given the partitioning scheme?

[JRD]

The good answer to this is to use UUID to design your partition, rather than a number.
Without modifying this partition, this UUID will not be modified and fstab could then use it to find your partition, regardless of its numbering.

[mimosa]

Does the Installer support this (using UUID to designate the partitions)? Or I suppose really it's a question of Gparted, rather than the installer itself ...

I'll play with this next time I'm installing Salix. That's not something I do every day, so it's taking me a long time to learn my way around these matters

Also the nature of the situation sometimes makes it hard to record one's actions precisely, for troubleshooting.

It does seem as though UUID is the cleanest option. For less experienced users (we are the ones who are especially grateful for such wonderful ergonomic software as the Installer) would it be possible to make this the default, I wonder ...

[Akuna]

Lilosetup uses it. The live installer could as well...

[mimosa]

So Lilosetup doesn't alter /etc/fstab ... of course it doesn't ... but would it be feasible

i) to check fstab for sanity and issue a warning

ii) more ambitiously, to (interactively) make appropriate changes, perhaps involving UUID?

[Shador]

Does the Installer support this (using UUID to designate the partitions)? Or I suppose really it's a question of Gparted, rather than the installer itself ...

I'll play with this next time I'm installing Salix. That's not something I do every day, so it's taking me a long time to learn my way around these matters

Also the nature of the situation sometimes makes it hard to record one's actions precisely, for troubleshooting.

It does seem as though UUID is the cleanest option. For less experienced users (we are the ones who are especially grateful for such wonderful ergonomic software as the Installer) would it be possible to make this the default, I wonder ...

Not sure. For less experienced users those numbers will be highly confusing, when something breaks anyway. UUID support is not good in Slackware anyway. (or does the initrd support root UUID/LABEL params by now?)
It's an abstraction many users are not happy with or they prefer LABELs. Arch which is also trying to be KISS doesn't enable it either by default and only offers to choose between the 3 alternatives. But they offer you a choice for everything anyway. But as Salix installation is meant to be straightforward, simple and fast, I don't think such a prompt fits there well.

[Akuna]

So Lilosetup doesn't alter /etc/fstab ... of course it doesn't ... but would it be feasible

i) to check fstab for sanity and issue a warning

ii) more ambitiously, to (interactively) make appropriate changes, perhaps involving UUID?

What I meant is that Lilosetup uses the uuid sheme to define partitions in /etc/lilosetup.conf. But it really shouldn't temper with /etc/fstab, which it is out of its scope since it is only meant to be a GUI setup utility for LILO.

And if someone does modify a partitioning scheme and run Lilosetup afterwards, it should catch up the changes and propose a new /etc/lilosetup.conf accordingly. However, 'cascading' modifications that should eventually occur in diverse /etc/fstab of the diverse partitions of a modified system should be done by the modifier himself.

Much simpler, safer that way.

Now the Live installer could eventually use the UUID scheme when it sets up the /etc/fstab file if deemed useful and desirable. As Shador pointed out, there are arguments on either sides. It is probably best that the Live installer follows Salix/Slackware default setup.

[mimosa]

I see what you mean, but I still think there might be a case for issuing a warning.

I also agree with Shador that UUID doesn't look at all human friendly, even if it actually is *more* human-friendly in terms of functionality.

The upshot is that this is a potential stumbling-block for users who may feel uncomfortable performing a task such as editing /etc/fstab. And maybe there's no way round that, and it's not such a bad thing: there has to be some sort of hook to draw you in to the console. However, I can imagine someone like my mother (who used to be a comouter programmer back in the sixties) clamouring to be given back the safety of Windows if faced with such a difficulty. It's an especially disconcerting problem because it affects the ability to boot back in to your system , and you do need a certain amount of sang-froid to fix something like that once it has gone wrong.

Maybe one good way to improve things would be through documentation.

EDIT

Off topic, but rather than clutter up the RC1 thread. In case it is of interest:

The installer from ...testing/ recognised it was not being run from Live and announced it would go into demo mode, which I thought was a very nice touch. I applied some random settings, including a timezone in Africa. But then I found my machine's time settings had been changed! (Fixed using timeconfig.)

[laprjns]

Maybe there's a better way to go about this, but here's what happened to me:
I was rationalising a hard disk with some unused Salix partitions left over from beta testing. After backing up my data, I deleted the unwanted ones with gparted, and used lilosetup to configure the bootloader appropriately. What had been /dev/sda7 became /dev/sda5.

The upshot is that this is a potential stumbling-block for users who may feel uncomfortable performing a task such as editing /etc/fstab. And maybe there's no way round that, and it's not such a bad thing: there has to be some sort of hook to draw you in to the console. However, I can imagine someone like my mother (who used to be a comouter programmer back in the sixties) clamouring to be given back the safety of Windows if faced with such a difficulty. It's an especially disconcerting problem because it affects the ability to boot back in to your system , and you do need a certain amount of sang-froid to fix something like that once it has gone wrong.

I would think that someone comfortable with "rationalizing" a hard disk would be comfortable editing a configuration file.

[mimosa]

@laprjns

You're quite right (though this did trip me up), but I suppose I'm thinking of users who aren't that comfortable, yet still find themselves having to sort out some mess they made while distro-hopping. Because of the way many people start using Linux, they often face complex partitioning scenarios when maybe they're not really ready to. On the other hand, maybe that's the only way to learn!

To put it another way, these ergonomically impressive tools (like Lilosetup or the installer) already go out of their way to make things easier than they need be. I'm just playing with ideas for ways to take that further - up to the devs whether, on balance, that's workable and desirable. My feeling is still that a sanity check on /etc/fstab and a warning if appropriate would be worth considering.