[EN] No system indipendent AND up-to-date siduction on USB-stick: right or wrong?

[michaa7]

When I dd (or cat) an USB-stick with a siduction.ISO, it is system independed, i.e. I may boot it on every x586 computer and it will select the right drivers.
But I am stuck with the version of the ISO's packages. No way to have them up-to-date (except building an updated ISO).

But I can install (not dd, not cat) to an USB-stick (like to any other hdd/ssd). I may update all packages to the current version, but now my installation depends on the hardware. I perhaps may boot this stick on other computers, but I won't have available all needed drivers. Right? So this stick isn't a good choice for installation on other systems?

Is there a way to have both features, being system indipendent AND being up-to-date on an USB-stick?

[towo]

Installing siduction to usb is system indipendent as long you remove all content in /etc/udev/rules.d on shutdown.

[michaa7]

Installing siduction to usb is system indipendent as long you remove all content in /etc/udev/rules.d on shutdown.

Thanks towo.

Is /etc/udev/rules.d re-created on each boot? Or am I losing functionality?

All drivers are copied to the stick? I mean, I install on a MB with intel chipset and then afterwards when booting on a MB with nvidia or whatever different chipset (after removing /etc/udev/rules.d on shutdown) I have availble the needed drivers? But that is not how an install on hdd works, is it?

I am now more confused than before. But I'll give it a try ...

[towo]

Linux does not know "drivers"!
There are kernelmodules and they are installed.
Udev is choosing the needed modules.

[michaa7]

Thanks again.

Does this mean: each time I want to use the stick on an other computer I remove /etc/udev/rules.d beforehand and it will be newly created while booting??

[towo]

No, you do not remove /etc/udev/rules.d you have to remove /etc/udev/rules.d/foo.rules and yes, they will be recreated on the next boot.
I would automate that removing instead of doing that manual.
Btw, on that stick you need xserver-xorg-input-all and xserver-xorg-video-all installed.

[michaa7]

No, you do not remove /etc/udev/rules.d you have to remove /etc/udev/rules.d/foo.rules

...yes, you are right as you wrote "...all content of ..."

and yes, they will be recreated on the next boot.

Thanks, my confusion starts to change to something a bit brighter.
 

I would automate that removing instead of doing that manual.

This was my first thought after reading your first answer. Unfortunately scripting isn't part of my skills. It would be wounderfull to have something in the shutdown sequence asking whether or not I wanted to purge /etc/udev/rules.d/* .

Btw, on that stick you need xserver-xorg-input-all and xserver-xorg-video-all installed.

thanks for the info, will do.

Whenn it came to the keybordconfig, I choose the "generic 105 key intl keybord", a good choice (I 'll see how it works on my laptop,but maybe this goes away after purging/etc/udev/rules.d/*  )?

[ayla]

A simple script for your problem:

Code: [Select]

#! /bin/bash

read -t 5 -p "Do you want to delete the content of  /etc/udev/rules.d/ " decis # Ask and wait 5 sec for input.  Input needs "Enter" .
if [ $decis == "j" ] #is input = "j"?
then
echo "ok, will do"
rm /etc/udev/rules.d/*.rules #remove all ".rules"; if folder is empty rm tells:  "not found"
else
echo "no, will not do so"
fi
Where to place best for running with root permission during shutdown is another question.

greets
ayla

[michaa7]

...
Where to place best for running with root permission during shutdown is another question.
...

Hi ayla, ich hatte ja gehofft, dass irgendjemand sich die arbeit macht und hier postet, und irgendwie bist du mir dazu eingefallen ;-) . Dass das geklappt hat und das so schnellist natürlich sehr erfreulich.

Hm, vielleicht bekommen wir ja noch kompetenten rat, zunot kann man das ja von user ausführbar (nicht schreibbar) machen und es an ein shutdown alias klemmen oder in killscripten in int 6 unterbringen. Wird sich bestimmt noch klären.

Ein frage die mich noch treibt ist, ob ich, wie es ja für ssd_s empfohlen wird, einige log und caches etc. in tempfs legen sollte?

[ayla]

Hi michaa7,

Thought about the kill scripts also, but thats not as easy with systemd I guess. I dont really know, but when I'm right then sysvinit had a straight order given by the number of the scripts and systemd tries to run them in parallel. For systemd I do not know how to solve this proper.

Logs and cache: you mean tmpfs => RAM? Then you would need to know how much RAM is available on the different machines you are going for.

Besides, I prepare a stick evry now and then like a normal HD on my home computer for using on my friends devices, never had a problem. Never cared for udev.rules eather, but may be a good point in some cases.

ok, problems with firmware for wlan chips or graphik cards whitch would not work with OS-drivers occured of course, but no issues depending on hardware/drivers because I builded it up on another machine.

greets
ayla

[michaa7]

Hm, now I have an up-to-date stick which (after deleting /etc/udev/rules.d/) is system independent, but it doesn't have the installer anymore. The installer needs the ISO, right?

[ayla]

yes, my usecases for this kind of stick are mostly rescue operations, demonstrating or having a secure system at hand with the possibility to store data.

[michaa7]

Hm, too bad.

But I wonder if copying the content of the stick, leaving out /etc/udev/rules.d/* and /home/<user>/* to hdd/ssd isn't pretty much the same then copying an ISO?  What's the difference? Is there a difference? If there isn't, then all that what's left ist installing grub to mbr. Done. I really wonder whether the installer couldn't be extended to do so for the benefit of heaving an always up-to-date stick with install capability?

Anyway, my installation to the stick didn't survive a reboot. I yesterday installed, d-u_ed to the stick, installed some packages including flashplugin-nonfree, watched TV/videostreams the whole evening/night while posting here in the forum. I changed back from systemd to sysvinit-core which might have caused the problems for today's reboot (no X, systemd-service didn't find something like "user@service" or so; the fsck showed errors all over the place, too big blocks. I still haven't tested the stick whether or not he is dead now, I'll see).

So, in theory this works fine, in practice it did, too. Until something went wrong ...